Deployment patterns

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.

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

​

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).

​

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

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 — the components every pattern deploys.
• Requirements — external dependencies every pattern needs you to provide.
• Self-host — what to bring to the conversation when starting an on-prem deployment.
• Upgrades — how the major-version boundary governs upgrade coordination across sites in the hyperscaler and on-prem patterns.