Scope: everything the platform needs to run. GPU capacity for model
serving and fine-tuning is excluded — that capacity is provisioned
separately by the serving control plane and sized to the model portfolio,
not to the platform. The serving control plane itself is included (its
footprint is negligible: a fraction of a CPU core).
Sizing profiles at a glance
Node roles
The platform schedules onto a small set of node roles. Sizes are given as generic vCPU / memory classes — any cloud instance family or on-premises hardware meeting the class works.
Sandbox nodes are deliberately over-provisioned relative to steady-state:
the platform holds a capacity reservation on them (roughly 7–28 vCPU
depending on scale) so user workloads start instantly instead of waiting
for node provisioning.
Compute demand
Steady-state scheduled requests, from rendered deployment manifests:- Single-replica profile: ~18–23 vCPU / ~50–60 GiB of requests for the platform itself, plus the sandbox capacity reservation (7–28 vCPU / 28–56 GiB). Node headroom above requests is what absorbs bursts.
- Multi-replica profile: public-facing services run 2–5 replicas (identity resolution highest, then gateways and workers), lifting requests to ~40 vCPU / ~120 GiB. Horizontal autoscaling can roughly double that at peak; size node capacity for the autoscaler’s maximum, not its minimum.
- Every node additionally carries a small observability agent (~0.1 vCPU / 200 MiB per node).
Storage
All block volumes should be SSD-class. Databases and the telemetry store
are the latency-sensitive consumers.
Platform prerequisites
- Kubernetes 1.30+ with a CSI block-storage driver and (optionally) a shared-filesystem driver.
- Load balancing: L4 load balancers with static addresses for the API edge and, if voice is enabled, for media signaling and TURN (TLS on a non-privileged port).
- Egress: NAT with a stable address for outbound traffic.
- TLS: a wildcard certificate for the platform domain.
- DNS: ability to point platform hostnames at the load balancers.
- Container registry: a registry reachable from the cluster. Air-gapped deployments pre-mirror all images to a local registry and use provider object storage in place of in-cluster S3.
- Secrets: platform secrets are encrypted at rest and decrypted at deploy time by the operator — the cluster itself needs no access to the key-management service.
- Ports: all services listen on ports ≥ 1025; node-to-node traffic on privileged ports can remain blocked.
What the minimum trades away
The minimum footprint runs every capability, but with single points of failure that the scaled profile removes:- Most services run one replica — a pod or node failure interrupts that capability until rescheduling completes.
- One telemetry-store node — observability is unavailable if it fails (the platform itself keeps running).
- One media node and one sandbox node — voice sessions or code execution pause on node loss.
- A single egress path and single load-balancer addresses.
- Most databases run one instance; the scaled profile adds replicas for the critical stores and continuous backups to object storage.