Liveblocks: hosted realtime collaboration for React apps, under Apache-2.0 and AGPL-3.0
Realtime infrastructure for multiplayer apps and agents
At a glance
- What is it?
- Liveblocks is a TypeScript monorepo of client SDKs and hosted infrastructure for presence, shared state, comments and notifications. It is a managed service with an open source client surface, and the licence split inside the repository is the first thing a team should read.
- Who is it for?
- Adopt Liveblocks if you are building a React product where presence, shared state, comments and notifications need to ship without a backend team, and you accept that the coordination layer runs on Liveblocks' servers. Do not adopt it if you need to run the realtime backend yourself, if your client stack is outside the supported list, or if AGPL-3.0-or-later components cannot pass your legal review.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Liveblocks actually sells, and what the repository contains
The README opens with a one-line positioning statement: Liveblocks "gives you the building blocks and infrastructure to enable people and AI to work together inside your app." That sentence names both halves of the product. The building blocks are the npm packages in this repository. The infrastructure is not in the repository at all. It runs on Liveblocks' servers, and the signup link in the README is the entry point to it. Anyone evaluating this repository should hold that distinction firmly, because the licence file reflects it. Most of the repository is Apache-2.0, and some components are AGPL-3.0-or-later. The README does not enumerate which packages fall on which side, so that is a question for the LICENSE file and for your own dependency audit, not for the marketing page. The audience is narrower than the tagline suggests. The SDK list is dominated by React and by editor bindings: react, react-ui, react-flow, react-tiptap, react-blocknote, react-lexical, plus codemirror, prosemirror, redux, zustand and yjs. There is a Node SDK, a Python SDK and a REST API for server-side work, and an emails package. If your frontend is not React or one of those editor frameworks, you are working against the grain of the toolkit.
Three products, one connection: how Sync, Comments and Notifications relate
The README groups the offering into three products. Sync adds realtime collaboration to a product experience. Comments adds contextual comments inside the product. Notifications keeps users coming back. They are presented as usable individually or together, which is the useful part of the design: you can adopt Comments without adopting Sync. Underneath, they share the same client. The client package is @liveblocks/client, and every framework package is a layer over it. The React package exposes hooks, the UI package supplies components, and the editor packages translate between Liveblocks' shared state and the editor's own document model. The @liveblocks/yjs package is the bridge to Yjs, the CRDT library named in the repository topics alongside yjs-provider and crdt. That bridge matters because it tells you Liveblocks is not asking you to abandon the CRDT ecosystem. If you already have a Yjs document, the Yjs provider is the integration point. The topics list also includes presence, websockets and commenting-system, which describes the transport and the two feature areas the company expects to be searched for. The data flow implied by the package layout is conventional for hosted collaboration: the browser client opens a connection, shared state and presence travel over it, and server-side code reaches the same rooms through @liveblocks/node or the REST API. The README does not document the wire protocol or the storage model, and nothing in the supplied material describes conflict resolution behaviour, so treat the CRDT guarantee as something to confirm in the docs before you depend on it.
Installing the packages and the config keys you can actually see
The README gives package names and documentation links, not installation commands. The package list is the reliable starting point: @liveblocks/client, @liveblocks/react, @liveblocks/react-ui, and the editor or state-management binding that matches your stack, whether that is @liveblocks/react-tiptap, @liveblocks/react-lexical, @liveblocks/react-blocknote, @liveblocks/codemirror, @liveblocks/prosemirror, @liveblocks/redux, @liveblocks/zustand or @liveblocks/yjs. Server-side work goes through @liveblocks/node, with @liveblocks/node-prosemirror and @liveblocks/node-lexical for document conversion outside the browser, and @liveblocks/emails for notification email. There is also @liveblocks/chat-sdk-adapter. Because no install command appears in the README, the honest statement is that you should read the getting-started tutorial at liveblocks.io/docs/tutorial/react/getting-started, which is the page the README points to for that purpose. The same applies to config keys: the README does not print an API key name, a room identifier format or a provider prop list. What it does confirm is that a hosted account is required, since the only setup instruction in the document is the signup link. That means the first configuration step is outside your repository: create a project, obtain credentials, and then wire the client. The repository itself ships docs, guides, tutorial and examples directories, and those are where the concrete snippets live. Anyone writing an integration plan from the README alone will be guessing at the details.
The hosted-service trade-off, and when it is the wrong tool
The clearest limitation is structural rather than technical. The coordination layer is a service you do not run. Your users' presence data, shared documents and comment threads pass through Liveblocks' infrastructure, and the README's only onboarding step is signing up for it. For a team with a data residency requirement, an air-gapped deployment, or a policy that collaboration content must stay inside their own VPC, that alone ends the evaluation, and no amount of SDK quality changes it. A second limitation is the framework surface. The package list is a map of what is supported, and it is React-centric. A Vue, Svelte or plain-DOM application would be relying on @liveblocks/client directly while the documented path, the tutorial, and the UI components all assume React. That is not impossible, but you would be writing the integration the toolkit was not built to give you. A third point is the licence split. The README states that some components are AGPL-3.0-or-later without saying which. AGPL-3.0 carries network-use obligations that many companies treat as a blocker for anything shipped to users. Until you have checked the LICENSE file against your actual dependency tree, you do not know whether your build pulls in an AGPL package. That is a verification task, not a reason to reject the project outright, but it is the first thing to resolve. Finally, the README describes three products and a long SDK list, and it does not describe limits, quotas, or what happens when a room reaches capacity. Those numbers live in the pricing and docs pages, and you should read them before designing around the free tier.
Yjs plus your own sync server, as the self-hosted alternative
The obvious alternative for a team that wants the same feature set without a vendor is to build on Yjs directly and run a sync server yourself. The difference in approach is not subtle. With Liveblocks you install @liveblocks/yjs as a provider and the transport, persistence and room management are somebody else's operational problem. With a self-hosted Yjs deployment you own the WebSocket server, the persistence layer, the authentication handshake and the scaling story, and you get to keep every byte on your own infrastructure. The cost moves from a subscription line to engineering time and on-call. Comments and notifications are the part where the comparison stops being close. Yjs gives you a shared document; it does not give you a comment thread anchored to a position in that document, a notification feed, or prebuilt React components that render them. The @liveblocks/react-ui and @liveblocks/emails packages exist to cover exactly that gap, and a self-hosted route means writing those yourself or assembling them from other libraries. The honest framing is that these are different purchases. One buys infrastructure and prebuilt UI; the other buys control and pays for it in scope. If your requirement is a single collaborative editor and nothing else, self-hosted Yjs is a defensible choice. If your requirement is a product with comments, mentions, notification emails and presence across several views, the amount of undifferentiated work on the self-hosted path is large enough that the comparison is no longer about ideology.
Maintenance cost, release cadence and the licence question
The release history shows three versions in the weeks before this review: v3.24.1 on 2026-08-19, v3.24.0 on 2026-08-17, and v3.23.1 on 2026-08-04. That is a fast cadence, roughly a minor or patch release every week or two, and it has a direct cost. A toolkit that ships that often will occasionally require you to move, and the packages are versioned together, so upgrading @liveblocks/react without upgrading @liveblocks/client is not a supported posture. Budget for reading the changelog at liveblocks.io/changelog on a regular schedule rather than treating the SDK as a set-and-forget dependency. The repository is not archived and the default branch is main. On licensing, the README is explicit that most of the repository is Apache-2.0 and that some components are AGPL-3.0-or-later, with the LICENSE file as the authority. Apache-2.0 is permissive and generally straightforward for commercial use. AGPL-3.0-or-later is a copyleft licence with a network-use clause, and its obligations depend on how the covered component is used and distributed. This article cannot tell you whether your specific usage triggers those obligations, and it should not try. The practical step is to identify which of the packages you install are AGPL, and to put that list in front of whoever handles licensing at your company before the first commit, not after the product ships.
Who should adopt it, and what to check before the first commit
Liveblocks fits teams building a React product who need presence, shared state, comments and notifications and do not want to staff a realtime backend. The strongest signal in the repository is the breadth of editor bindings: Tiptap, BlockNote, Lexical, CodeMirror, ProseMirror and Yjs are all covered, so if your product is built around one of those editors, the integration work is largely done for you. It also fits teams already using Yjs who want a hosted provider rather than an operations burden. It does not fit teams that must self-host the coordination layer, teams outside the React and listed-editor ecosystem, or teams whose legal review rejects AGPL-3.0-or-later dependencies and cannot isolate them. Before you write code, do three concrete things. Read the LICENSE file and map it against your actual dependency tree, because the README does not tell you which packages are AGPL. Open liveblocks.io/docs/tutorial/react/getting-started, since that is the only setup path the README offers and it is where the real commands and config keys live. And check the pricing and limits pages for the concurrent-room and storage numbers, because none of them appear in the repository. If those three checks pass, the SDK surface is broad enough that the remaining work is your product, not the plumbing.
Editorial conclusion
Adopt Liveblocks if you are building a React product where presence, shared state, comments and notifications need to ship without a backend team, and you accept that the coordination layer runs on Liveblocks' servers. Do not adopt it if you need to run the realtime backend yourself, if your client stack is outside the supported list, or if AGPL-3.0-or-later components cannot pass your legal review. Verify three things before writing code: which packages your dependency graph pulls in, the exact licence of each, and whether the free tier's limits match your expected concurrent-room count.
Community notes