How We Cut Agora and ZegoCloud Bills to Zero With Self-Hosted LiveKit

Every live streaming and voice chat app we have worked on hits the same wall. The product works, rooms start filling, hosts start streaming for six hours a day instead of twenty minutes — and the streaming invoice stops looking like a line item and starts looking like the business model. The month your app finally takes off is the month the bill stops making sense.

That is not a bug in how Agora or ZegoCloud price their platforms. It is exactly what per-minute billing is designed to do: costs scale in lockstep with usage, forever, with no ceiling. It is a completely reasonable deal when you are starting out and a genuinely painful one when you are not. This article explains what you are actually paying for, how self-hosted LiveKit removes that line from the invoice, and — the part most articles on this topic skip — what it replaces it with.

What you are actually paying Agora and ZegoCloud for

Real-time SDK vendors bill on participant-minutes, not on streams. This distinction is the single most misunderstood thing about streaming costs, and it is where budgets go wrong. You are not billed for the one host who is broadcasting. You are billed for every person receiving that broadcast, for every minute they are in the room.

So a room with one host and fifty viewers running for one hour is not sixty billable minutes. It is fifty-one participants times sixty minutes, which is 3,060 participant-minutes — from a single room, in a single hour. Video is billed at a higher rate than audio, and higher resolutions cost more again, so an HD video room can be an order of magnitude more expensive per hour than an audio room with the same headcount.

On top of the minutes, the platforms you are comparing usually meter recording and transcoding, cloud recording storage, in some cases TURN relay traffic for users behind restrictive networks, and any extra services such as content moderation or transcription. None of those are unreasonable charges. They are just charges that grow every single month that your app succeeds.

• Billing is per participant-minute, so a full room costs more than an empty one at exactly the moment it is earning most
• Video costs more than audio; higher resolution costs more than lower
• Recording, transcoding and storage are metered separately
• Free monthly allowances are generous at prototype scale and irrelevant at real scale
• You have no control over the unit price — it is whatever the rate card says next year

What LiveKit is, and why it changes the equation

LiveKit is an open source WebRTC stack released under the Apache 2.0 licence. At its core is an SFU — a Selective Forwarding Unit — which is the server that receives media from whoever is publishing and forwards it to everyone subscribed, without re-encoding it. That is the same architectural job Agora and ZegoCloud are doing inside their clouds. The difference is that with LiveKit you can run it yourself, on your own servers, under a licence that does not charge you per minute.

It is worth being precise here, because the naming confuses people. LiveKit Cloud is a hosted, paid product, and it is a good one. LiveKit the open source server is the thing you can deploy on your own infrastructure at no licence cost. When this article says self-hosted LiveKit, it means the second one. You get the same client SDKs either way — Flutter, React, iOS, Android, web — which is what makes moving between them practical rather than theoretical.

• Apache 2.0 licensed — no per-minute fee, no per-seat fee, no revenue share
• Mature SDKs for Flutter, React, JavaScript, iOS, Android, Go and Python
• Simultaneous broadcast and adaptive layers, so weak connections drop quality instead of dropping out
• Server-side recording and streaming out to RTMP through its egress service
• Token-based authentication your own backend issues and controls
• Runs on any cloud, any bare-metal provider, or a mix of both

What "free" honestly means here

Here is the part that most comparison posts leave out, and the part we tell every client before they commit. Self-hosting LiveKit takes your per-minute streaming bill to zero. It does not take your streaming costs to zero. The software licence is free. The servers that run it are not, and neither is the bandwidth they push.

What actually changes is the shape of the cost. Per-minute billing is variable and unbounded: it rises with every successful month and you have no lever on the unit price. Self-hosted infrastructure is largely fixed and steppable: a server handles a certain concurrent load, and when you outgrow it you add another. Between those steps, extra usage costs you nothing. That is the real win, and it is a bigger one than a percentage discount, because it decouples your infrastructure cost from your growth.

You are not eliminating the cost of streaming. You are converting an unbounded variable cost into a fixed cost you control, on hardware you can shop around for.

The dominant cost after the switch is egress bandwidth — the media flowing out of your servers to viewers. This is where provider choice matters enormously, far more than CPU. Some clouds charge steep per-gigabyte egress rates that can erode the savings; others bundle generous transfer allowances into the instance price. Picking the wrong host can turn a large saving into a modest one, which is why we model bandwidth before choosing where anything runs.

The cost comparison, in shape rather than in numbers

We are deliberately not publishing a table of per-minute rates. Rate cards change, they vary by region and by negotiated contract, and a blog post quoting last year's prices is worse than no post at all. Check the current pricing pages for your own numbers. What does not change is the structure of the two models, and the structure is what should drive the decision.

Read the second row again, because it is the whole argument. Under per-minute billing, ten times the users means roughly ten times the invoice. Under self-hosting, ten times the users means a handful more servers — and each one of those servers absorbs a large block of concurrent traffic before you need the next. The gap between those two curves is small at prototype scale and enormous at the scale everyone is actually aiming for.

How we architect a self-hosted LiveKit deployment

This is the general shape of what we build. Every deployment differs in the specifics — region mix, concurrency targets, recording requirements, what the existing backend already does — but the components below are the ones that always need to exist, and the ones people most often discover late.

The media layer

• LiveKit SFU nodes sized for concurrent publishers and subscribers rather than registered users
• A shared coordination layer so multiple nodes behave as one cluster and a room is not trapped on a single box
• TURN relay for participants on mobile networks and corporate firewalls that block direct connections — a genuine minority, but one that will otherwise simply never connect
• Regional deployments placed where your audience actually is, because latency is geography and no amount of tuning beats physics
• Adaptive quality layers so a viewer on a weak connection degrades gracefully instead of freezing

The control layer

• Access tokens minted by your own backend, scoped per room and per participant, short-lived by default
• Room lifecycle driven by your application logic — who may publish, who may subscribe, who can be removed
• Server webhooks feeding participant join and leave events back into your own analytics, billing and moderation
• Moderation hooks that can mute, remove or ban in real time, which is a store-review requirement and not an optional extra
• Recording and RTMP egress running as its own service, because transcoding competes for exactly the CPU your media path needs

The operations layer

• Metrics on concurrent participants, packet loss, jitter and CPU per node, with alerting before users notice
• Autoscaling policies tied to real concurrency, with enough headroom that a viral room does not land on a saturated node
• Health checks and drain-before-terminate so scaling down never cuts a live room mid-stream
• A rollback path for server upgrades, tested before you need it rather than during an incident
• Load testing with simulated participants at several times expected peak, because peak is the only number that matters

Migrating an existing app off Agora or ZegoCloud

Migrating a live app is not a weekend job, but it is a well-understood one, and it does not require a big-bang cutover. The media layer is more separable from the rest of a streaming app than most teams assume — the gifting, the coin ledger, the host hierarchy, the moderation tooling and the panels all sit above it and mostly do not care which SFU is underneath.

1. 1Measure first. Pull your real participant-minutes, average room size, peak concurrency and region split from the current provider. Without those numbers a migration is guesswork and the business case is fiction.
2. 2Abstract the media layer behind an interface in the app, so the rest of the codebase stops calling the vendor SDK directly.
3. 3Stand up a LiveKit cluster in staging and port the room experience — join, publish, subscribe, mute, leave, reconnect — against the new interface.
4. 4Run both stacks side by side behind a server-side flag, so any single room can be pointed at either provider and switched back instantly.
5. 5Roll out by percentage, watching join success rate, time to first frame, packet loss and crash rate rather than only watching the bill.
6. 6Move recording and RTMP egress across once live rooms are stable, since these are the least time-critical pieces.
7. 7Keep the old provider enabled but idle for a billing cycle. It costs little and it is the cheapest insurance you will ever buy.

The part that takes longest is rarely the streaming code. It is the long tail of reconnect behaviour, background audio on both platforms, the devices that behave strangely, and the network conditions your real users have rather than the ones your office has. Budget for that tail honestly and the migration is calm; ignore it and your first rollout will be loud.

When self-hosting is the wrong answer

We build both. We are not going to pretend self-hosting always wins, because it does not, and the cases where it loses are easy to spot in advance.

• You are pre-launch and still proving the idea. Use a managed SDK, stay inside the free tier, and spend your money on finding out whether anyone wants the product.
• Your usage is genuinely low and flat. If the monthly minutes bill is small, the engineering time to self-host will cost more than it saves for years.
• Nobody will own operations. Self-hosting without monitoring and someone on call is not a saving; it is deferred downtime.
• You need dozens of regions immediately. A global edge network is real engineering and real money, and buying it is the sane choice until your traffic justifies building it.
• Your traffic is extremely spiky and rare. Paying only for the minutes you use genuinely suits a product that is idle most of the month.

The honest rule of thumb: when your monthly streaming invoice comfortably exceeds what the equivalent self-hosted infrastructure plus its share of maintenance would cost, and that gap is widening every month, migrating pays for itself quickly. Below that line, stay managed and get on with building the product.

What to measure before and after

Cost is the reason for the migration, but cost is not the metric that tells you whether it worked. A cheaper stack that connects less reliably is not cheaper — it is a churn problem with a smaller invoice attached. Track quality alongside spend, from before the first room moves.

• Join success rate — the percentage of attempts that actually reach a connected room
• Time to first frame, and time to first audio, measured at the 95th percentile rather than the average
• Packet loss and jitter, broken down by region and by network type
• Reconnect rate and how long recovery takes when a network flips between wifi and mobile data
• Concurrent participants per node, so you know your real capacity rather than your assumed one
• Total infrastructure spend per thousand participant-minutes, which is the only number directly comparable to the old invoice

The bottom line

Agora and ZegoCloud are good platforms and they are the right choice for plenty of products, especially early ones. But their pricing model means your infrastructure cost is permanently tied to your success, and for a gifting-driven live streaming or voice chat app — where the busiest rooms are both the most profitable and the most expensive — that coupling gets uncomfortable fast.

Self-hosted LiveKit breaks the coupling. The per-minute line disappears, the licence costs nothing, and what remains is infrastructure you can size, shop around for and optimise. It is not free in the literal sense, and anyone telling you otherwise is selling something. What it is, is predictable — and predictable is what lets you price coin packs, plan host payouts and forecast margins without a variable you do not control sitting in the middle of the spreadsheet.

We have built voice and video on Agora, on LiveKit Cloud and on self-hosted LiveKit, and we have migrated live apps between them without taking rooms offline. If you are staring at a streaming invoice that is growing faster than your revenue, send us your participant-minutes, average room size and peak concurrency and we will tell you honestly whether migrating is worth it for you — including when the answer is no.