Requirements and dependencies

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.

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

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

​

Network topology

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 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. 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 with your scale targets and we’ll share current reference numbers.

​

See also

• Architecture — what each component is and what it talks to.
• Deployment patterns — the topology shapes.
• Agents — the agent install flow per OS.
• Feature catalog — what’s optional vs always-on inside the platform binaries.