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

# Self-host

> Where to start when a Cyberun deployment lives in your environment — what is public today, what is partner-led, and what to bring to the first conversation.

Self-hosted Cyberun deployments — sovereign on-prem, partner VPC,
air-gapped lab — run in production today. The control-plane
deployment runbook is partner-led for the moment; the agent-side
install is fully public. This page is the bridge: what an
evaluator or operator can read on their own, what's published,
what's coming, and what to bring to a conversation with Cyberun
when ready.

## Public on this site today

Self-host evaluation reads everything in the Platform tab. Most
load-bearing pages for evaluation are public:

* [Architecture](/platform/architecture) — components, surfaces,
  who talks to whom.
* [Requirements](/platform/requirements) — external dependencies
  (database, object store, cache, message bus), agent-host
  expectations, network topology.
* [Deployment patterns](/platform/deployment-patterns) — the four
  topology shapes, with criteria for picking.
* [Identity](/platform/identity) — credential families, the
  built-in OIDC issuer, external IdP options.
* [License administration](/platform/license) — what the license
  carries, expiry behavior, renewal mechanics, air-gapped
  outline.
* [Feature catalog](/platform/feature-catalog) — every
  deployment-toggleable capability with its license key and
  enterprise-template default.
* [Agents](/platform/agents) — install reference (per-OS
  installer, all flags, service locations, log paths).
* [Connections and tunnels](/platform/gateway-and-tunnels) —
  how agents reach the gateway and how the gateway proxies
  per-agent services.
* [Observability](/platform/observability) — logging surfaces,
  OpenTelemetry traces.
* [Upgrades](/platform/upgrades) — release streams, version
  policy, license interaction across majors.
* [API reference](/api-reference/introduction) — the HTTP
  surface every client talks to.

An evaluator can build a complete mental model from the pages
above without a sales call.

## In development

Some operator content is being prepared for public release. Until
each page lands, the content is partner-led — share your
deployment intent and we'll respond with the current reference:

* **Step-by-step control-plane install.** Helm chart, container
  manifests, recommended secrets posture, first-deploy
  verification. Today: deployment-specific runbook from Cyberun.
* **Production sizing reference.** Concrete numbers per scale
  band (small / medium / large / multi-site).
* **Air-gapped install + license refresh artifact.** The exact
  artifact format and custody process.
* **Backup and DR runbook.** What state to capture, restore
  procedures, multi-region replication patterns.
* **External IdP integration recipes.** For an enterprise IdP that
  doesn't speak OIDC — interim guidance is to front Cyberun with an
  OIDC broker.
* **Audit-log shipping spec.** A dedicated audit sink (separate
  retention, tamper-evident) for compliance-driven deployments.

These pages will arrive on this site as the partner runbooks
stabilise into generalisable shapes.

## Bring this to the first conversation

To make the first conversation with Cyberun productive, gather the
following before the call. Most are decision inputs the sizing and
license shape depend on — having them ready turns a discovery call
into an actual scoping call.

### Operational shape

* The pattern you're targeting (sovereign on-prem, hyperscaler,
  mixed, air-gapped — see
  [Deployment patterns](/platform/deployment-patterns)).
* Where Cyberun will run (Kubernetes flavour and version, bare
  metal, single VM, etc.).
* Whether the deployment will be multi-site from day one or grow
  into multi-site later.

### Scale targets

* Expected number of users, teams, concurrent active agents.
* Workflow mix (ComfyUI dominant, Nerfstudio dominant, both).
* Peak concurrent tasks (rough).
* Storage volume expected per team per month (rough).

### Dependencies you'll provide

* Relational database (standard SQL).
* Object store (S3-compatible API).
* In-memory key/value store.
* Event / message bus.
* SMTP relay (optional — only needed for sign-up / invitations / password reset).
* TLS termination (ingress controller, load balancer, …).

### Identity strategy

* Your current IdP (Okta, Entra, Auth0, Keycloak, custom OIDC,
  custom SAML, AD/LDAP, none yet).
* Whether end-users sign in through Cyberun's built-in OIDC
  issuer or federate through your IdP.
* Whether external apps will OIDC into Cyberun (using Cyberun as
  an IdP for other tools).

### Compliance posture

* Data-residency constraints (single region, single country,
  multi-region with replication).
* Audit / retention requirements (general retention window, any
  per-record requirements).
* Network constraints (air-gapped, restricted egress, allowed
  CIDR for the agent gateway, proxy requirements).

## Reach out

Once you have the above (or even a subset), reach out at
[sales@cyberun.cloud](mailto:sales@cyberun.cloud). Include the operational
shape, scale band, and pattern target — that's enough for the
right people on Cyberun's side to come into the conversation with
relevant material.

## See also

* [Deployment patterns](/platform/deployment-patterns) — the
  shape you're picking.
* [Requirements](/platform/requirements) — the public dependency
  list.
* [Feature catalog](/platform/feature-catalog) — what the license
  can entitle, with defaults.