Skip to content
Back to

Hardware requirements

Size the cluster so the platform services and every workspace can schedule. The figures below are Kubernetes memory requests, which the scheduler reserves, and limits, which cap the container. Live usage sits between the two. Your nodes also need headroom for the operating system and Kubernetes system pods.

Sizing profiles

Section titled “Sizing profiles”
Profile RAM vCPU When you use it
Laptop evaluation About 8 Gi for the OrbStack VM (recommended) on a 16 Gi machine 4 or more One workspace on OrbStack Kubernetes with every heavy shared service consumed from a URL or turned off.
Light local 16 Gi practical floor, 32 Gi comfortable 4 or more A workstation that also installs some shared services locally.
One workspace, full stack 16 Gi 4 A single production workspace with the platform services installed alongside it.
Two workspaces, full stack 32 Gi 8 Two live workspaces sharing one node.

Add another workspace only when there is unused capacity after the platform namespace and the existing workspaces. Each workspace is a complete stack with its own backend, databases, secret store, and identity plane.

On a laptop, the Kubernetes node is the OrbStack virtual machine, so its memory setting is the ceiling for everything below. Give it about 8 Gi for a single evaluation workspace with the shared services consumed remotely, and more if you install any of them locally.

Disk: allow around 100 GB per node for the container runtime, images, and persistent claims, then size for the claims listed below plus growth. On AWS, workspace volumes are network-attached block storage, so disk grows independently of the node.

Platform namespace

Section titled “Platform namespace”

Shared across every workspace in the cluster. Each service is declared in fontana.yaml as installed, consumed from a URL, or off. Health probes are always installed. Enable exactly one embedding server: TEI or Infinity.

Workload Request Limit fontana.yaml
Health probes 128 Mi 256 Mi Always deployed
Docling 2 Gi 8 Gi platform.docling
TEI (embeddings) 2 Gi 12 Gi platform.tei; mutually exclusive with Infinity. Limit is 4 CPU for model warmup
Infinity (embeddings) 512 Mi 2 Gi platform.infinity, with TEI off
Kokoro TTS 1 Gi 6 Gi platform.tts
OpenSandbox server 4 Gi per replica 8 Gi per replica platform.opensandbox. Chart default is 2 replicas (8 Gi requested). Lab installs may use 1
OpenSandbox controller 64 Mi 128 Mi Same OpenSandbox declaration
OpenSandbox MCP 64 Mi 256 Mi Same OpenSandbox declaration
OpenSandbox proxy 32 Mi 128 Mi Same OpenSandbox declaration
OpenSandbox auth 32 Mi 128 Mi Same OpenSandbox declaration
Inbound SMTP 128 Mi 512 Mi Deployed when your platform team enables inbound agent and workflow mail
Outbound SMTP 128 Mi 512 Mi Deployed with inbound mail for agent delivery

Approximate platform requests, pods only:

  • Everything installed, with TEI and OpenSandbox at 2 replicas: about 13 Gi reserved
  • Infinity instead of TEI, OpenSandbox at 2 replicas: about 11.5 Gi
  • Health probes and Infinity only, the rest consumed remotely or off: about 640 Mi

Consuming a platform service from a url costs nothing in your cluster, which is how a small install runs the full feature set on modest hardware.

Workspace namespace

Section titled “Workspace namespace”

Each workspace in fontana.yaml gets this stack. Telemetry forwarding runs when platform.observability names a collection endpoint or is installed locally.

Workload Request Limit Notes
Backend 2 Gi 8 Gi Largest always-on workspace process (functions, vector search)
Workflow engine 1 Gi 4 Gi Includes the connector runner in the same pod
Knowledge Graph engine 512 Mi 2 Gi Graph retrieval and ingest
Graph database 512 Mi 4 Gi Derived graph and vectors
Database (backend) 512 Mi 2 Gi
Zitadel 512 Mi 2 Gi Identity
Zitadel Postgres 256 Mi 1 Gi Isolated from the backend database
Telemetry collector 128 Mi 512 Mi Only when platform observability is configured
Observability service 256 Mi 512 Mi Always on; forwards telemetry when configured
ImmuDB (WORM audit) 256 Mi 1 Gi Stays when workspace telemetry forwarding is off
Vault 128 Mi 256 Mi
Fontana Collab 256 Mi 512 Mi
Chat channels 256 Mi 512 Mi Slack and Teams bridge
Backend dashboard 256 Mi 512 Mi
Health probes 128 Mi 256 Mi

Approximate workspace requests, pods only:

  • Full stack with telemetry forwarding: about 7.1 Gi reserved
  • Without telemetry forwarding: about 7 Gi reserved

Limits are higher so the backend and the graph database can burst. In staging and production, stateless workloads run two or more replicas so upgrades and node maintenance never leave a service with none. Multiply those workloads’ requests accordingly when sizing.

Trimming a small install

Section titled “Trimming a small install”
Declaration What you skip Request you free
platform.docling: { url: … } or { disabled: true } Local Docling 2 Gi / 8 Gi
platform.tts: { url: … } or { disabled: true } Local Kokoro TTS 1 Gi / 6 Gi
platform.opensandbox: { url: … } or { disabled: true } Local sandbox control layer 4 Gi per server replica plus small edge pods
platform.tei: { disabled: true } with Infinity installed TEI 2 Gi / 12 Gi; Infinity adds 512 Mi / 2 Gi instead
platform.observability: { url: … } The telemetry collector in each workspace 128 Mi / 512 Mi per workspace

A service declared disabled: true is not installed and not consumed, and the feature that depends on it fails clearly at the point of use rather than degrading quietly. After apply, fontana status reports what is running and which declared origins answered. See Fontana CLI.

Persistent volume claims (disk)

Section titled “Persistent volume claims (disk)”

These claims sit on cluster storage. They are not extra RAM.

Claim Typical size
Workflow file store 20 Gi
Graph database 20 Gi
Backend data 10 Gi
Backend Postgres 10 Gi
ImmuDB WORM 10 Gi (default)
TEI model cache 10 Gi
Infinity model cache 5 Gi
Zitadel Postgres 2 Gi
Vault 1 Gi
Health probes 1 Gi
Section titled “Related documentation”