Everything you probably want to ask
before putting Orcastra in front of your clusters.

Orcastra is an open-source control plane, or cloud management platform, for managing many LXD, Incus and MicroCloud clusters from one place.

Instead of opening a separate dashboard, CLI or endpoint for every cluster, you get one dashboard and one API for all of them.

No. Orcastra does not replace LXD, Incus or MicroCloud.

Your infrastructure keeps running on its own platform. Orcastra sits above it as a management layer.

Turn Orcastra off and your instances, networks, storage and clusters carry on exactly as before.

You absolutely can. Orcastra is built so that you keep the native CLI available at all times.

It earns its place once the number of clusters, nodes, projects, users and customers grows and you need:

The CLI does not go anywhere. Orcastra just makes the operational overhead much smaller.

Typically teams whose infrastructure has grown past a single server. For example:

If you run a single-node homelab, Orcastra still works. You may simply not need everything it offers yet.

Orcastra currently focuses on LXD, Incus and MicroCloud.

A single Orcastra deployment can manage several clusters running different platforms.

Yes. That is one of the main reasons Orcastra exists.

Register as many clusters as you like and see them as one infrastructure estate. They can sit in:

No. One site can run LXD, another Incus, another MicroCloud.

Orcastra gives you the same operating experience across all of them.

Yes. LXD and Incus support system containers and KVM virtual machines, and Orcastra manages both from the same interface.

When you create an instance you simply choose:

Orcastra stores what the control plane needs to run, but the cluster remains the real source of truth for your infrastructure.

It does not convert LXD, Incus or MicroCloud into a proprietary format. The principle is simple:

Your cluster stays your cluster.

Self-hosted. You install Orcastra on your own infrastructure.

There is no requirement to connect to a hosted Orcastra service.

With Docker. The control-plane stack consists of several services:

Secrets and sensitive credentials can be held in HashiCorp Vault.

No. Orcastra talks to your clusters through the platform API.

For console and terminal it uses the channel the cluster already provides, without depending on SSH inside the guest.

What matters is that the Orcastra control plane can reach the cluster API.

The network design is yours. A cluster does not have to be exposed to the internet just so Orcastra can manage it.

Yes, and you set the whole configuration on one page, including:

Orcastra deliberately avoids the long wizard that only reveals an important setting several steps in.

Yes. Once a node is selected, Orcastra reads the resources actually available on it.

So the network, storage pool and GPU device options match what that node can genuinely provide.

Yes. The browser receives progress from the cluster event stream over a WebSocket.

You watch provisioning happen instead of refreshing the page repeatedly.

Yes. The Orcastra terminal does not depend on an SSH daemon inside the instance.

It stays reachable even when:

Yes. Open the graphical console straight from the browser.

For a virtual machine you can also:

Yes. Terminals and consoles appear as floating sessions over the dashboard.

Open a terminal on server A, a console on server B, and move around the rest of the dashboard without losing either session.

Yes. Files go in through the terminal session, with no need to open SSH or run an extra service inside the guest.

Yes. It shows and manages resources such as:

IPAM also shows which instance, MAC address and project each address belongs to.

Yes. It works with the storage pools and volumes available on the cluster, so you can:

Yes. Images and ISOs upload to the cluster.

Large uploads are resumable, so a dropped connection does not send you back to the beginning.

Yes. Organizations, projects, policies and cluster binding are all designed for multi-tenant environments.

A service provider can run Orcastra as the control plane behind the infrastructure they sell.

Resource limits are applied through projects, for example:

A project also acts as an isolation boundary for resources such as networks, images, profiles and storage.

Yes. Each organization can carry its own branding:

A service provider does not have to show the same generic interface to every customer.

Orcastra can use an external identity provider over OAuth2 and OIDC.

The roles and groups from that provider then decide what someone can reach inside Orcastra.

Yes. Access is granted per resource. A given user might only be allowed to:

And the scope can be narrowed to a cluster, a project or a single instance.

Not necessarily. Orcastra has break-glass access for the cases where an admin genuinely needs to enter a tenant environment.

That access:

So emergency access does not mean an admin holds permanent access to everything.

Sensitive credentials can be held in HashiCorp Vault.

Private keys do not have to sit as plain files on the dashboard filesystem.

Yes. Orcastra records activity so you know:

For environments that need accountability, this is considerably more useful than reading somebody’s shell history.

Orcastra is designed API-first. What the console can do is exposed over the API as well, so it can be driven by:

Yes. A key can carry:

And it can be revoked at any time.

Yes. Capabilities are granted individually:

Not every integration needs admin rights.

No. Orcastra is not an AI model and runs no LLM in the control plane.

Orcastra publishes an MCP server so the AI assistant or agent your team already uses can read your infrastructure through Orcastra.

An agent might ask:

Access still follows the capabilities and scope you defined.

By default, no. Capabilities are granted one at a time.

An agent can start with read-only access, and you decide whether it ever needs more.

AI does not get the keys to the kingdom automatically.

Yes, for infrastructure telemetry such as:

The data is read from the clusters Orcastra manages.

Yes. Orcastra lists each certificate with its:

A certificate approaching expiry raises a warning before it becomes an outage that was entirely preventable.

Orcastra does not quietly replace credentials behind your back.

Renewal stays a visible action an operator controls.

Yes. Orcastra is released under GPLv3 and the repository is public.

No. Community users and customers with an enterprise support agreement run the same Orcastra.

There is no:

You pay for support, not extra software. An enterprise agreement provides:

The software itself is identical.

Then use it for free. Download it, install it, run it in production, even use it to serve your own customers.

There is no trial that suddenly expires.

If you need help, the community is on Discourse and issues can be reported on GitHub.

Orcastra enterprise support is distributed by PT Sivali Catur Lestari — Sivali Cloud Technology.

For a quotation, scoping or the agreement terms: ORCA Cloud Services →