> ## Documentation Index > Fetch the complete documentation index at: https://docs.mka1.com/llms.txt > Use this file to discover all available pages before exploring further. # Cluster minimum requirements > Node, compute, storage, and platform requirements to run MKA1 — from a minimum viable footprint to a highly available deployment. MKA1 deploys onto a standard Kubernetes cluster (managed cloud Kubernetes or an on-premises / air-gapped distribution). This page describes what that cluster needs: the minimum viable footprint, and what the deployment looks like when scaled out with multiple replicas for production-grade availability. **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 | | Minimum viable | Scaled / highly available | | ---------------- | ------------------------------------------ | --------------------------------------------------------------------------------- | | Worker nodes | **6–8 nodes** | **10+ nodes** with autoscaling headroom | | Total compute | **\~60 vCPU / \~200 GiB RAM** | **\~80–100 vCPU / \~300 GiB RAM** steady-state, with burst headroom to roughly 2× | | Service replicas | 1 per service (2 for the identity path) | 2–5 per public-facing service, autoscaled | | Block storage | **\~400–650 GiB SSD** | **\~650–900 GiB SSD** (longer observability retention, larger analytics) | | Object storage | S3-compatible endpoint, \~500 GiB to start | Same, sized to file/artifact volume | | Availability | Single instance of most components | Multi-replica services, multi-zone nodes, database replicas for critical stores | ## 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. | Role | Class | Minimum count | Purpose | | ------------------------- | ---------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | General purpose | 8 vCPU / 32 GiB | 3–4 (scaled: 6+) | All platform and product services, databases, workflow engine | | Observability / analytics | 8 vCPU / 32 GiB (16 GiB acceptable at minimum) | 1 | Dedicated to the columnar telemetry store (ClickHouse); isolated so heavy queries never starve the platform | | Media | 4 vCPU / 8 GiB | 1 | Voice/WebRTC media server; benefits from a public network path for TURN | | Sandbox execution | 16–32 vCPU / 32–64 GiB | 1–2 | Runs untrusted code in isolated environments; requires either **nested virtualization** (Firecracker microVM backend) or a **container runtime** backend on dedicated, tainted nodes | | Control plane | managed, or 3 masters | — | Managed Kubernetes control planes count as zero nodes; self-managed clusters need the usual 3 | 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 | Category | Minimum | Scaled | Notes | | ---------------------------- | ----------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Relational databases | \~165 GiB | \~185+ GiB | One PostgreSQL cluster with a database per service; the busiest two (LLM state, workflow engine) run 2 instances each in the scaled profile | | Telemetry store | 150 GiB | 200+ GiB | ClickHouse volume; grows with trace/log retention policy | | Product analytics (optional) | — | \~300 GiB | Analytics stack (columnar store, queue, object volume) if deployed | | Caches / brokers | \~40 GiB | \~40 GiB | Redis-compatible caches, pub/sub broker, webhook store | | Object storage | \~500 GiB S3-compatible | grows with usage | Files, artifacts, sandbox images, database backups. In-cluster S3 (SeaweedFS) or a provider object store both work | | Shared filesystem (optional) | — | provisioned-throughput NFS-class | Used for shared search indexes at scale; single-replica deployments can run without it | 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. Scaling out is incremental: add general-purpose nodes, raise replica counts on the public-facing services, add database instances for the critical stores, and enable autoscaling — no re-architecture is involved.