Self-Hosted LiveKit vs LiveKit Cloud: Cost and Scale Trade-offs

Key Takeaways

• Self-hosted LiveKit removes the two limits that break voice AI platforms at scale: concurrent agent session caps and per-minute egress billing — replacing them with compute cost you control
• LiveKit Cloud is the right default until either the concurrent-agent ceiling is in sight or the monthly bill makes dedicated compute competitive — for voice AI, that crossover typically arrives between 50K–100K call-minutes/month
• Self-hosting requires operating three ECS services: LiveKit server (WebRTC SFU), Python agent workers, and LiveKit Egress — plus Redis for state and autoscaling policies for each tier
• Prodinit migrated Cuebo from LiveKit Cloud to a fully self-hosted ECS stack in 12 weeks — 10x peak-load capacity, 5 AI pipeline variants, zero concurrent-session limits

The decision between self-hosted LiveKit vs LiveKit Cloud comes to a head at a predictable moment: you check the concurrent-agent count, see it approaching the tier ceiling, and realize that adding more calls means either upgrading to a tier that prices you out of unit economics or migrating off the managed service entirely. LiveKit Cloud is an excellent starting point. It is not a permanent solution for every scale.

This post gives you the full trade-off picture — the specific limits that drive teams to self-host, what the migration costs to build and operate, and the numbers that tell you which side of the line you're on.

Self-hosted LiveKit vs LiveKit Cloud comes down to one question: is the concurrent-agent ceiling or per-minute egress billing the binding constraint on your growth, or are those limits far enough away that the engineering overhead of self-hosting is not yet worth paying? Once you hit the ceiling, self-hosting is not optional — it is the only path to unbounded scale.

What LiveKit Cloud Actually Limits

LiveKit Cloud provides managed WebRTC infrastructure: the SFU, signaling server, TURN relay, and — on paid tiers — hosted agent execution. For voice AI specifically, the hard limit is the number of concurrent AI agent sessions your tier allows. Every active call occupies one agent slot. A platform handling 200 simultaneous calls needs 200 agent slots.

LiveKit Cloud tiers impose a ceiling on those slots. When a platform's peak call volume approaches that ceiling, one of three things happens: calls queue and callers experience delays, the platform's error rate spikes as agent dispatch fails, or the team upgrades to a higher tier at a significantly higher monthly base cost. None of these are ideal when call volume is a function of user growth, not a decision you control.

Beyond the agent ceiling, egress billing compounds at scale. LiveKit Cloud charges for video and audio egress — the bandwidth consumed as media streams out of the SFU to participants. For a pure voice AI use case running audio-only sessions, egress cost per call is modest. But at 90K+ calls per month averaging even 8 minutes each, the line item is no longer trivial, and it scales directly with volume. Compute, by contrast, scales with concurrent sessions, not total volume — and can be right-sized.

The third limit is less obvious: customization. LiveKit Cloud's hosted agent execution runs in the provider's infrastructure. Deploying 5 different AI pipeline variants — each using different combinations of STT, LLM, and TTS providers — requires your agent workers to be under your control, on infrastructure you can configure per pipeline. That is not possible when the execution environment is managed.

Self-Hosted LiveKit vs LiveKit Cloud: Full Comparison

This table maps every dimension that matters for a production voice AI platform deciding between the two options. The right answer is different for a platform at 5K calls/month than one at 100K.

The hybrid option — self-hosted agent workers pointed at LiveKit Cloud's SFU — exists and removes the agent-slot ceiling while keeping managed SFU infrastructure. It is a useful intermediate step before going fully self-hosted, but it retains egress billing and some SFU customization limits.

The Cost Crossover: When Self-Hosting Gets Cheaper

The cost crossover is not a fixed number — it depends on your average call duration, concurrent session peaks, and what ECS compute your stack requires. But the shape of the math is consistent: LiveKit Cloud costs scale linearly with call volume; self-hosted compute costs scale with concurrent sessions.

For a voice AI platform with 8-minute average calls:

• 10K calls/month — roughly 1,400 concurrent-hour demand. LiveKit Cloud egress cost is manageable; engineering overhead of self-hosting is not worth it.
• 50K calls/month — roughly 6,700 concurrent-hour demand. LiveKit Cloud egress line item is material. Begin evaluating whether a fixed ECS stack (3–4 task definitions, always-on) would cost less.
• 100K calls/month — 13,000+ concurrent-hour demand. At this volume, a well-sized ECS stack (LiveKit server + agent workers + egress, with autoscaling) typically costs less per month than LiveKit Cloud usage-based billing, often by a meaningful margin.
• Beyond 100K calls/month — self-hosting is almost always cheaper in pure infrastructure cost. The question becomes whether the engineering overhead has been amortized by the team.

The overhead that matters: a self-hosted LiveKit stack requires someone to operate it — server version updates, ECS task definition changes, autoscaling policy tuning, and on-call coverage when a session-state issue or SFU misconfiguration causes problems. Budget 20–30% of one engineer's time for the first 3–6 months after migration, settling to 10–15% thereafter.

What Self-Hosting LiveKit Actually Requires You to Operate

Self-hosting the full LiveKit stack means running three separate ECS services (or Kubernetes deployments) plus their dependencies. Each is independently scalable and independently deployable, which is the point — but each is also a service you need to operate.

LiveKit server is the WebRTC SFU: the Go binary that handles room creation, signaling, media routing, and participant management. It is the entry point for all calls. Configuration is a YAML file (ports, Redis connection, JWT key, TURN settings). Scaling is horizontal — add ECS tasks behind a network load balancer as concurrent sessions increase. LiveKit server has no shared state per-room beyond what it caches in Redis, which makes horizontal scaling clean.

Python agent workers are your AI pipeline. Each ECS task runs a LiveKit agent worker process that connects to the server, waits for room dispatch, and runs the STT → LLM → TTS pipeline when a participant joins. You deploy one task definition per pipeline variant and scale each independently. Agent workers scale on CPU and memory, which track concurrent active sessions. Prodinit built Cuebo's agent workers with a factory pattern — the same worker binary reads a simulation_service field from dispatch metadata and instantiates the matching pipeline class (Deepgram, Azure OpenAI, ElevenLabs, Claude Sonnet, Sarvam, Gemini Live across 5 variants). This is what makes multiple pipeline variants operationally manageable.

LiveKit Egress is the recording service. It joins rooms as a participant, mixes audio (and video if needed), and writes to S3. It runs as a third ECS service with its own scaling policy — scale on room count, not CPU. Egress is stateful (it holds an active recording job per room), so scaling down requires draining active recordings gracefully.

Redis holds session state — room metadata, participant tokens, and the agent dispatch queue. A single Redis instance on ElastiCache is sufficient for most voice AI platforms. Make it HA (Multi-AZ) and you remove it as a single point of failure.

Autoscaling is the operational detail teams underestimate most. Each of the three ECS services should scale on a different metric: the server on active WebSocket connections, agent workers on SQS queue depth or CPU, egress on active room count. LiveKit Cloud handles this invisibly. Self-hosted, you configure it explicitly — CloudWatch metrics, target tracking policies, and scheduled scaling for known peak windows.

The full architecture Prodinit built for Cuebo — three ECS services, multi-metric autoscaling, Redis on ElastiCache, the agent factory pattern, plus CI/CD — is covered in detail in the Cuebo self-hosted LiveKit case study. For the agent worker code patterns (factory dispatch, pipeline variants, post-call processing), the self-hosted LiveKit production guide covers the implementation specifics.

The Migration Path

Teams that migrate from LiveKit Cloud to self-hosted do not hard-cut on day one. The lowest-risk path runs both in parallel:

1. Build self-hosted stack — server, a single-variant agent worker, egress, Redis on ECS. This takes 4–6 weeks depending on your existing AWS infrastructure maturity.

2. Parallel run — route 5–10% of new rooms to the self-hosted stack. Verify latency, egress quality, and agent dispatch reliability against LiveKit Cloud as the baseline.

3. Progressive rollout — increase self-hosted routing (20% → 50% → 80%) over 2–4 weeks, watching per-session metrics at each stage. Keep LiveKit Cloud active as a fallback routing option.

4. Full cutover + multi-pipeline deployment — once the single-variant self-hosted stack is stable at full volume, deploy the remaining pipeline variants as separate ECS worker task definitions. Route by simulation_service field from the application layer.

5. Scale down LiveKit Cloud — downgrade or cancel the hosted agent tier. You can retain LiveKit Cloud TURN-only for fallback NAT traversal if your network topology benefits from it.

Cuebo's migration across this path completed in 12 weeks from decision to full production. The parallel-run phase surfaced one misconfiguration in the agent dispatch queue that would have caused silent failures at scale — caught at 5% traffic before it ever reached production volume.