> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cyberun.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployment patterns

> The shapes a Cyberun deployment takes — sovereign on-prem, hyperscaler, mixed control-plane, single-site managed — with the criteria to pick between them.

The platform supports several topologies, all running the same
binaries against the same external dependencies. What changes is
where the control plane runs and where the agents run. Pick by
your constraints — data residency, hardware ownership, cloud-cost
posture, support model.

## Pattern at a glance

```mermaid theme={null}
flowchart LR
    subgraph SaaS["Single-site managed"]
        S_CP[Cyberun control plane]
        S_Ag[Cyberun-run agents]
    end
    subgraph Mixed["Mixed control plane / customer agents"]
        M_CP[Cyberun control plane]
        M_Ag[Customer-run agents on customer GPUs]
    end
    subgraph OnPrem["Sovereign on-prem"]
        O_CP[Customer control plane in customer DC]
        O_Ag[Customer-run agents]
    end
    subgraph Hyper["Hyperscaler escape"]
        H_CP1[Control plane in cloud A]
        H_CP2[Control plane in cloud B]
        H_Ag[Agents anywhere]
    end
```

## Single-site managed

**Shape:** Cyberun runs the control plane on Cyberun's
infrastructure. Customers sign up at `app.cyberun.cloud`.

**Pick this when:** evaluation, small teams, no hardware-ownership
or data-residency constraint, low operational overhead is the top
priority.

**Trade-offs:** zero deployment effort, but task data and team
state live on Cyberun's infrastructure. No self-host autonomy.

## Mixed control plane / customer agents

**Shape:** Cyberun runs the control plane (managed). The customer
runs Cyberun agents on the customer's own GPU machines. Tasks
dispatch to customer-controlled hardware; task state and
artifacts flow through Cyberun's storage.

**Pick this when:** the customer owns or rents GPU capacity and
wants to use it through Cyberun's dashboard / MCP without
deploying the control plane themselves. Common shape for studios
and labs.

**Trade-offs:** no deployment burden for the customer. Agent hosts
are managed by the customer; the rest is managed by Cyberun.
Artifacts pass through Cyberun's object storage en route to the
customer's storage.

## Sovereign on-prem

**Shape:** the customer deploys the full Cyberun control plane
(API server, agent gateway, license service, OIDC issuer) in
their own environment. Agents run on the customer's hardware.
Cyberun touches no production data.

**Pick this when:** data must not leave premises, the customer
already runs Kubernetes-grade infrastructure, hardware investment
beats per-use cloud cost over the deployment lifetime, or
regulatory posture forbids hosted SaaS.

**Trade-offs:** full operational autonomy — you own backups,
upgrades, identity wiring, observability. Public deployment
runbooks for self-service install are in development; today
this pattern is partner-led
([reach out](mailto:sales@cyberun.cloud)).

## Hyperscaler escape

**Shape:** the customer deploys Cyberun across multiple cloud
providers (or multiple regions of one provider) joined into a
trust mesh. Identity, scheduling, and storage span the sites.

**Pick this when:** breaking out of single-provider risk is a
business requirement, regulatory zones are mandated (data has to
stay in region X but compute can be anywhere), or cross-cloud
redundancy is part of the SLO target.

**Trade-offs:** highest operational complexity. Site federation
mechanics (single OIDC issuer with replicated keys vs distinct
issuers in a trust circle; cross-site artifact replication; DR
strategy) are deployment-time decisions. Multi-site federation
runbooks are in development; today partner-led.

## Picking between them

| Need                                           | Recommended pattern                                                             |
| ---------------------------------------------- | ------------------------------------------------------------------------------- |
| Try Cyberun with no deploy effort              | Single-site managed                                                             |
| Bring your own GPUs but skip control-plane ops | Mixed control plane / customer agents                                           |
| Data must not leave your environment           | Sovereign on-prem                                                               |
| Multi-cloud / cross-region from day one        | Hyperscaler escape                                                              |
| Air-gapped                                     | Sovereign on-prem (with air-gapped runbook — in development; partner-led today) |

Sizing reference numbers for each pattern (cores, RAM, storage,
expected agents per gateway) are in development as part of the
public deployment guide. Until that lands, partner deployments are
hand-sized in consultation with Cyberun — share your scale
targets and we'll respond with current reference numbers.

## See also

* [Architecture](/platform/architecture) — the components every
  pattern deploys.
* [Requirements](/platform/requirements) — external dependencies
  every pattern needs you to provide.
* [Self-host](/platform/self-host) — what to bring to the
  conversation when starting an on-prem deployment.
* [Upgrades](/platform/upgrades) — how the major-version boundary
  governs upgrade coordination across sites in the hyperscaler
  and on-prem patterns.