OpenVidu: self-hosted video and audio built on LiveKit and mediasoup

What OpenVidu is for, and who ends up using it

OpenVidu is a platform for building real-time video conferencing applications. That is the README's own framing, and it is deliberately narrower than "a video conferencing product". The project targets developers who are embedding live audio and video into an existing application rather than administrators looking for a finished meeting tool.

The README names the intended deployment model directly: self-hosted on your own infrastructure (AWS, GCP, Azure, Oracle, DigitalOcean, on-premises) or as a managed service. That split matters when you are choosing. A team with data residency constraints or an existing cloud account gets a self-hosted path. A team that wants someone else to run the media servers gets a managed one.

The topics list on the repository adds the application areas the project is aimed at: e-learning, meet, chat, product, room, ai-agents. The README backs the AI part with a concrete claim: recording, RTMP/streaming egress, AI agents for transcription and translation, and virtual backgrounds are listed as advanced media features. For a team already running a learning platform or an internal meeting product, that is the relevant surface area.

One thing the README does not do is describe a user-facing product. OpenVidu Meet is a separate repository, described as a fully-featured video conferencing app that ships on top of this platform, ready to use or embed. If you want an app rather than a platform, that is where you start.

The LiveKit and mediasoup foundation, and why it changes your client code

The architectural claim in the README is short and specific: OpenVidu is built on top of LiveKit and mediasoup, and it is API-compatible with LiveKit, so you can use any LiveKit client or server SDK unchanged.

That sentence has more consequences than it first appears. If the compatibility claim holds for the SDKs you use, then your integration work is LiveKit integration work. You are not learning an OpenVidu-specific signalling protocol or an OpenVidu-specific room model on the client side. The value the project adds sits underneath: deployment, media features, and the reference application.

mediasoup appearing alongside LiveKit is the part the README leaves unexplained. Both are media server projects, and the README does not say which one handles which path, whether they coexist in one deployment, or how a request is routed between them. If you are evaluating OpenVidu for a production system, that is the first thing to resolve against the documentation, because it determines your capacity planning and your failure domains.

The repository layout reinforces that this is a platform rather than a library. The top level holds openvidu-deployment/, openvidu-livekit, openvidu-components-angular/, and a set of test directories (openvidu-test-browsers/, openvidu-test-e2e/, openvidu-test-integration/). There is no single application entry point at the root. The primary language is TypeScript, which is consistent with a browser-facing SDK and Angular components, but the media servers themselves are separate projects that OpenVidu builds on.

Installing OpenVidu locally and joining a first room

The README does not carry install instructions in the repository itself. It points elsewhere, and the pointer is explicit: "Try it locally" links to the openvidu-local-deployment repository, and the documentation link goes to openvidu.io/latest/docs. That is where installation steps live. Treat anything below as the shape of the workflow rather than a substitute for those pages.

The client-side package is published to npm as openvidu-browser, which the README's badge links to. If your application is a browser app and you are following the LiveKit-compatible path, the practical first step is to add the SDK your build already uses:

npm install openvidu-browser

After that, the README's compatibility statement is what governs your code: the LiveKit client SDK can be used unchanged. The tutorials repository linked from the README (openvidu-tutorials) is where the project puts working examples, and it is the right place to copy a first connection flow from rather than guessing at one.

For a local trial, clone the local deployment repository rather than this one:

git clone https://github.com/OpenVidu/openvidu-local-deployment
cd openvidu-local-deployment

What you should see after following that repository's own instructions is a running local instance you can point a client at. The README here does not state ports, environment variables or container names, so do not fill those in from memory. If you want a finished application to test against instead of writing a client, the README names OpenVidu Meet as the reference app, and it can be used as-is or embedded.

Where OpenVidu is the wrong choice

The clearest limitation is documentation depth in this repository. The README is a landing page: a definition, a feature list, a set of links. It does not document rollback, upgrade ordering, capacity limits, or how the two media servers divide work. If your evaluation requires reading the source to answer basic operational questions, budget for that.

The second limitation is the compatibility promise itself. "API-compatible with LiveKit" is a strong statement, and it is also a statement about APIs, not about behaviour under load, feature parity for every advanced media feature, or operational tooling. The README lists recording, RTMP/streaming egress, AI agents and virtual backgrounds as OpenVidu features. It does not say which of those come from LiveKit, which from mediasoup, and which are OpenVidu's own. If one of those features is the reason you are evaluating the project, verify it specifically.

Third, this is not a tool for someone who wants to install a meeting server and hand out a URL. The README points to OpenVidu Meet for that, in a separate repository. Choosing this repository means choosing to build and operate.

Finally, the release cadence visible in the release list (v3.6.1 in April 2026, v3.7.0 in May 2026, v3.8.0 in July 2026) suggests regular releases, but the README does not describe a support window or a long-term-support line. If you need a version you can stay on for years, that is a question for the documentation, not the README.

LiveKit on its own, and what OpenVidu adds on top

The honest alternative to OpenVidu is LiveKit itself. OpenVidu's own README states the relationship: OpenVidu is built on top of LiveKit, and LiveKit client and server SDKs work unchanged. If your application only needs the SDK surface and you are comfortable deploying LiveKit directly, the layer OpenVidu adds is the thing you would be removing.

What that layer contains, per the README, is self-hosting across a list of named clouds and on-premises, a managed-service option, the advanced media features (recording, RTMP/streaming egress, AI agents, virtual backgrounds), an Angular component library in this repository, and the OpenVidu Meet reference app. That is a deployment and product layer, not a different protocol.

The trade-off is straightforward. Going direct to LiveKit means one fewer project in your dependency chain and one fewer compatibility claim to validate. Going through OpenVidu means you inherit its deployment work and its media feature set, and you accept that when LiveKit changes, OpenVidu has to track it. Which side of that you prefer depends on whether the deployment and feature layer is work you want to do yourself.

If what you actually want is a ready-made conferencing application rather than a platform to build on, the README points to OpenVidu Meet, and the repository topics also list meet and chat. That is a different decision from choosing a media platform, and it should be made first.

Maintenance, releases and what the Apache-2.0 licence covers

The repository is not archived, and the last push was on 2026-09-16, one day before the date used for this assessment. The release list shows v3.8.0 on 2026-07-09, v3.7.0 on 2026-05-05 and v3.6.1 on 2026-04-01. On the evidence available, the project is being pushed to and released on a roughly two-month cadence.

The licence is Apache-2.0, and the repository carries both LICENSE and NOTICE files at the top level. Apache-2.0 is a permissive licence, which generally means you can use, modify and distribute the code, including commercially, subject to its conditions. This is not legal advice, and two things are worth checking with someone qualified: the NOTICE file's contents, because Apache-2.0 carries attribution obligations that the NOTICE file often makes concrete, and the relationship between the Apache-2.0 code and the managed service the README mentions. The README does not state the terms of the managed service, and a licence on a repository does not automatically describe a hosted offering.

The README also records public funding: OpenVidu "has been supported under project CPP2021-008720 NewGenVidu", funded by MCIN/AEI/10.13039/501100011033 and the European Union-NextGenerationEU/PRTR. That is a fact about the project's history, not a statement about its roadmap.

Upgrade cost is the part the README does not answer. There is no upgrade guide in the README, no statement about breaking changes between v3.6, v3.7 and v3.8, and no support policy. Before pinning a version, read the documentation for the release you intend to run.

Editorial conclusion

Adopt OpenVidu if you need to run real-time video on your own infrastructure and you already know LiveKit, since the README states the platform is API-compatible with LiveKit and any LiveKit client or server SDK works unchanged. Do not adopt it if you want a single install command from this repository: the README points to openvidu-local-deployment for local trials and to openvidu.io/latest/docs for the rest, and neither the deployment topology nor the upgrade path is described here. Before committing, verify the supported deployment targets against your own infrastructure, confirm which release you are pinning (v3.8.0 is dated 2026-07-09), and check the licence terms for the managed-service option separately from the Apache-2.0 code.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. OpenVidu/openvidu on GitHub
3. Project website
4. README
5. Releases