Requirements

Speaknode is a composable platform. Each service runs in its own container, so you can scale components independently. Before deploying, size your infrastructure according to expected concurrent sessions — everything else (backbone services) stays roughly constant.

Software dependencies

• Docker 24+ and Docker Compose v2.24+
• 64-bit Linux host (Ubuntu 22.04 LTS or equivalent). macOS works for local dev.
• Outbound internet access (registry, LLM/STT/TTS providers, STUN/TURN)
• Ports accessible from your users' browsers: frontend, backend API, Keycloak, LiveKit WebRTC (TCP 7881, UDP 50000–60000).

Per-service resource baselines

The table below shows combined CPU / RAM / Disk requirements for each service at typical concurrent session loads. Values are empirical baselines from production.

⚠ All figures on this page are preliminary estimates. Real-world load can vary significantly with traffic patterns, model choice, session length and audio characteristics — use them as a starting point and validate against your own metrics before sizing production hardware.

How to read this:

• Session-bound services (livekit-server, python-worker, egress, websocket-media-bridge) scale linearly with the number of active calls. They are what you need to plan for.
• Backbone services (Postgres, Kafka, Keycloak, Redis, MinIO, etc.) have a largely fixed footprint — you can host them once and reuse across tenants.
• Disk mostly grows in Postgres (transcripts, invoices), Kafka (event retention) and MinIO (call recordings). Plan storage with retention in mind.

Resource calculator

Use the calculator to estimate the total footprint of the application stack at your expected peak concurrency:

Notes

• Numbers are for the application layer only. CPU/RAM/disk for LLM, STT and TTS providers (or self-hosted models) are billed separately by those vendors and are not included here — for self-hosted GPU planning see the calculator below.
• Add a safety margin of 20–30% on top of the calculator output for headroom, spikes and OS overhead.
• For high-availability production deployments you should double the backbone figures (Postgres replica, Kafka with replication factor ≥ 2, etc.).

GPU sizing for self-hosted models

If you run STT / TTS / LLM on your own hardware instead of cloud providers, size GPU VRAM separately. The matrix below shows current OSS picks (June 2026); the calculator below it lets you pick one model per role and see total VRAM under a target concurrent-session load. Pick "Custom" in any dropdown to enter your own model and the totals recalculate live.

How the GPU calculator works

• Model weights — held in VRAM once, regardless of session count. Quantization to INT8 halves the weight cost, INT4 (AWQ / GPTQ) quarters it.
• KV cache — the LLM stores per-token attention state for every active session. Bytes per token = 4 × layers × kv_heads × head_dim (KV cache stays in FP16 even when weights are quantized — vLLM / TGI / SGLang default).
• Session buffers — STT and TTS keep per-stream activation buffers; the size depends on the model architecture (autoregressive TTS like XTTS/Fish costs the most per session, encoder-only Whisper costs the least).
• GPU recommendation — the smallest GPU in our catalogue that fits the total VRAM with a 10% headroom margin. If nothing fits, drop precision, cut context, or split the model across GPUs with tensor parallelism.

Minimum machine sizing (at a glance)

Sized against the calculator above with backbone services enabled and the recommended 20–30% headroom included. CPU / RAM stays application-only — GPUs for self-hosted models are budgeted separately above.

For everything above 50 concurrent sessions we recommend splitting livekit-server + python-worker onto their own hosts, so that media and agent CPU load doesn't starve the backbone. Above 250 sessions the egress recording pods and the turn-detector benefit from dedicated nodes too.