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

# Requirements and dependencies

> What you need to provide to run a Cyberun deployment — external dependencies, supported OS / runtime versions, expected scale ranges.

A Cyberun deployment runs Cyberun's binaries against a set of
external dependencies you provide (database, object store, cache,
message bus, optional SMTP). This page lists what the deployment
needs to function.

Concrete production-sizing numbers — cores, RAM, IOPS, throughput
per gateway, agents-per-cluster — are in development as part of
the public deployment guide. Reach out at
[sales@cyberun.cloud](mailto:sales@cyberun.cloud) for the current
reference numbers for your expected scale.

## Control-plane dependencies

The cloud-side components (API server, agent gateway, OIDC issuer,
license validator) require:

| Dependency      | Role                                                           | Interface to provide          |
| --------------- | -------------------------------------------------------------- | ----------------------------- |
| Relational DB   | Persistent state (users, teams, credentials, workflows, tasks) | Any standard SQL database     |
| Object store    | Workflow inputs, task artifacts, model uploads                 | Any S3-compatible API         |
| In-memory store | Tokens, session state, gateway connection table                | Any in-memory key/value store |
| Message bus     | Task lifecycle events, gateway-to-server fan-out               | Any event / message bus       |
| SMTP            | Account verification, password reset, invitations (optional)   | Any SMTP-compatible relay     |

The control plane talks to these standard interfaces, so
substitution is straightforward — production deployments pick
compatible managed services or self-host equivalents. Concrete
vendor compatibility notes are in development.

## Agent-host requirements

A machine running a Cyberun agent needs:

* **CPU/RAM**: enough headroom for the chosen runtime (ComfyUI or
  Nerfstudio) plus a small, fixed overhead for the agent process
  itself.
* **GPU**: sized to the runtimes you'll run. The agent runs on
  every supported OS; each runtime sets its own GPU and OS
  requirements (see [Platform → Agents](/platform/agents)). A
  current NVIDIA + CUDA host covers every runtime.
* **Disk**: storage for the team's model cache and node packages
  on first run; the size depends on the workflows. Plan 100 GB+
  for active workloads.
* **Network**: outbound HTTPS to the gateway URL. No inbound
  exposure required. Egress to the object store endpoint for
  artifact uploads.
* **OS**: Linux (amd64 or arm64), macOS, or Windows. Per-platform
  install scripts are at
  [Platform → Agents](/platform/agents).

A formal compatibility matrix (CUDA versions × runtime versions ×
OS) is in development.

## Network topology

| Direction                                    | Purpose                                      |
| -------------------------------------------- | -------------------------------------------- |
| Browser → API (HTTPS)                        | Dashboard, REST runtime calls.               |
| AI client → MCP endpoint (HTTPS, Streamable) | External AI clients driving the platform.    |
| Agent host → gateway (HTTPS, upgrade to WSS) | Outbound only. No inbound port on the agent. |
| Server / gateway → object store              | Artifact upload and signed-URL minting.      |
| Server → SMTP (optional)                     | Verification, invitations, password resets.  |

The platform deliberately keeps agents on outbound-only paths so
they install cleanly behind corporate firewalls and NAT. Inbound
exposure is limited to the control plane (API, gateway, OIDC
issuer).

## Identity

Cyberun ships a self-hosted OIDC issuer that signs the tokens used
across the platform. External integrations:

* **Upstream OAuth sign-in** (Google today; more providers in
  development) for end-user sign-in — gated by the `oauth` feature.
* **OIDC issuer** that external apps can federate against — gated
  by `oidc_provider`.

For an enterprise IdP that doesn't speak OIDC, front Cyberun with
an OIDC broker; native upstream integrations are in development.

See [Identity](/platform/identity) for the full picture.

## Scale guidance

Early reference shape for a small-to-medium deployment:

* **One** API server, one gateway, one license server. All
  stateless at the process level (state lives in the dependencies
  above).
* **Three or more** agent hosts to absorb common workflow demand
  without queueing.
* **Database + object store** sized for the team's task volume.

Multi-site deployments add more clusters joined into one trust
mesh — see [Deployment patterns](/platform/deployment-patterns).

Production sizing for higher tiers (hundreds of users, thousands
of tasks per day, etc.) and an explicit horizontal-scale guide are
in development. Until that lands, partner deployments are
hand-sized in consultation with Cyberun;
[reach out](mailto:sales@cyberun.cloud) with your scale targets and
we'll share current reference numbers.

## See also

* [Architecture](/platform/architecture) — what each component is
  and what it talks to.
* [Deployment patterns](/platform/deployment-patterns) — the
  topology shapes.
* [Agents](/platform/agents) — the agent install flow per OS.
* [Feature catalog](/platform/feature-catalog) — what's optional
  vs always-on inside the platform binaries.