We made LiveKit so every developer in the world could have access to a modern, end-to-end WebRTC stack for free. The growth of the project and community around it has been as stunning as the things we’ve seen developers build with LiveKit. We believe real-time, multiplayer applications that help us feel close together despite being miles apart is the future of computing. A future where your geography–where you live–will no longer influence your opportunity or access. A future with less pollution, crazy housing markets, and more egalitarian job wages.

We want to work on the infrastructure to make this all possible, for many years to come.

It’s partly with this intention that we’ve spent the last year building LiveKit Cloud (the other part is making LiveKit easier to use, deploy and scale for developers). Since our initial open-source release in July 2021, many companies have asked us for a commercial, managed cloud offering. Seeing this as a clear path towards sustainability for the LiveKit project and team, we began to envision how a commercial product would work, which features it would have, and how much we’d charge.

One thing we’d seen (and experienced) with other open source projects is that they intentionally held back key features from the free version. We definitely didn’t want to do that. LiveKit should work exactly the same whether you’re hosting or we are. You should be able to switch seamlessly between Cloud and LiveKit Open Source or even split traffic between the two!

The other thing that really bugged us was how commercial audio/video companies (i.e. “CPaaS” providers) charged for their services. Everyone metered usage by something called the “participant-minute”. It’s a pricing model that doesn’t make sense for a few reasons.

One is, it’s inflexible: only applications which also charge their users by time spent (like education or healthcare) can easily predict their margins.

Second, charging by the minute means CPaaS providers must either a) amortize the cost of people sending more data (i.e. the provider’s underlying cost) by setting a higher unit price for everyone, or b) have multiple price structures broken out by usage behavior or capabilities (e.g. audio-only, video, and data channels). All the providers do both.

Lastly, this model is just not very forward-looking. Cameras and microphones are digital eyes and ears. They’re already the highest-fidelity form of presence we share today over things like Zoom calls, and eventually, we’ll have cameras in front of our eyes paired with AirPods in our ears. Audio and video will be everywhere, some flavor of it offered by every application. When a technology or product is commoditized, value-based pricing models like the participant-minute, won’t fool customers.

We chose to take a different approach: a cost-based pricing model.

LiveKit’s infrastructure runs across a blend of cloud providers, but they all charge us for resources in the same way – bandwidth, compute, and storage. What if we did that too? Specifically, for bandwidth, we’d charge by the gigabyte (GB) when a client transmits data to a LiveKit SFU (upstream) or when data is transmitted from a SFU to a receiving client (downstream). If you transcode in the process, that’s a compute task, so we’d meter by the minute transcoded (in practice, calculating consumed CPU cycles was too involved). We don’t store anything (yet), so nothing to do there.

When we shared our pricing model and retail prices with beta customers, there was a mixture of elation, surprise, and skepticism. Most were happy to not be paying by the participant-minute, while some couldn’t believe how much cheaper it was to alternatives or how efficiently we could operate our infrastructure. It was never our goal to compete with CPaaS providers on price—we’d surely lose a race to the bottom—but it turns out for many use-cases, a cost-based model is significantly cheaper.

A few folks cautioned us against doing this and advised it’s better to have an “apples-to-oranges” model, where a customer can’t ascertain our margin or interrogate the value we’re providing on top of the core infrastructure.

My response was: developers—myself, our team, the people we’re building LiveKit for—are constantly deploying and running infrastructure to support their applications. When integrating a cloud service, they always do a buy-vs-build calculation, weighing the tradeoffs between cost and vendor lock-in against time-to-market and devops. This is a reason why LiveKit is open source: one isn’t locked in. If a developer wants control over their real-time infrastructure or believes they can operate it for cheaper, they’re free to do so — they don’t even need to change a single line of code!

“But, you’ll make more money!” they said.

LiveKit will be a successful, sustainable business without needing to extract every last dollar the market will bear. This is all in service of our work having a positive impact anyway. There’s a company integrating LiveKit with emergency dispatch centers, another using it on drones to detect drowning swimmers and potential shark attacks on Australian beaches, and a third to help those hard of hearing remotely sign with service providers like bank tellers and healthcare workers. None of these developers (for different reasons) are using LiveKit Cloud and we don’t make a dime off them. They’re also some of our favorite, most energizing use-cases and the reason we continue pouring ourselves into this product.

Whether you become a customer of LiveKit Cloud or self-host, we’d love to hear about what you’re building and how we can support you. Come say hello in our community!