Liveblocks: Infrastructure for Multiplayer Apps and AI Agents

What Liveblocks Solves and Who It Is For

Liveblocks addresses the engineering cost of building realtime collaboration into a web app. The synchronisation layer for features like shared cursors, collaborative text editing, threaded comments, and in-app notifications involves websocket management, conflict resolution, and state persistence. Liveblocks packages that infrastructure as a hosted service with SDKs that plug into existing React or Node codebases.

The intended users are product engineering teams at companies building tools where multiple people work in the same document or application simultaneously. The README describes it as giving developers the building blocks and infrastructure to enable people and AI to work together inside your app. The AI framing refers to scenarios where AI agents participate in shared documents alongside human users, not to any model inference capability in the library itself.

Liveblocks is not a self-hosted open-source database. The packages in this repository are the client libraries; the synchronisation server is operated by Liveblocks. That distinction matters for any evaluation of where data lives.

Three Products: Sync, Comments, and Notifications

The repository organises around three discrete products that can be used independently or together.

Sync adds realtime collaboration to any product experience. Comments allows contextual comment threads inside the app, directly tied to specific elements or positions. Notifications keeps users informed about activity and directs them back to the relevant location.

Each product is surfaced through a set of pre-built hooks, components, and APIs. The design intent is to avoid re-implementing the protocol layer: a team building a collaborative whiteboard uses Sync, integrates the Liveblocks client, and receives presence events and conflict-free state updates without managing websocket reconnection or operational transforms.

The repository itself is a monorepo managed with pnpm and Turborepo. The packages directory contains over fifteen published packages, each targeting a specific integration point. The engineering overhead for the consumer is the integration work, not the protocol.

SDK Coverage: React, Yjs, CodeMirror, and Beyond

The published packages cover a range of integration surfaces:

- @liveblocks/client is the core package for any environment - @liveblocks/react provides React hooks - @liveblocks/react-ui adds pre-built React components for comments and notifications - @liveblocks/react-tiptap, @liveblocks/react-blocknote, and @liveblocks/react-lexical add collaborative editing inside those specific rich text editors - @liveblocks/codemirror and @liveblocks/prosemirror cover those editor frameworks - @liveblocks/yjs bridges to Yjs, the CRDT library used by many editor toolkits - @liveblocks/node handles server-side access patterns - @liveblocks/node-lexical and @liveblocks/node-prosemirror add server-side rendering support for those editors - @liveblocks/redux and @liveblocks/zustand integrate with those state managers - @liveblocks/emails sends notifications via email - @liveblocks/chat-sdk-adapter bridges to chat SDK environments - A Python SDK and a REST API are also documented

The examples directory contains over twenty Next.js projects demonstrating AI calendars, AI spreadsheets, AI slideshows, code collaboration, and comment overlays on canvas. These are not bundled functionality: they are starter projects that show how to compose the packages.

The monorepo toolchain requires Node.js 24.x or newer, as stated in the engines field of the root package.json. Consumer projects can use older Node versions, but the development environment for contributing to the repository requires 24.x.

A First Integration with the React Package

The README links to a tutorial at liveblocks.io/docs/tutorial/react/getting-started. The core package is installed per the standard npm workflow:

npm install @liveblocks/client @liveblocks/react

From there, an app wraps its components with a LiveblocksProvider that holds the API key, then uses the hooks exported from @liveblocks/react to read and write shared state. The REST API and webhook events allow server-side handlers to react to collaboration events.

For Yjs integration, the @liveblocks/yjs package provides a Liveblocks-backed Yjs provider. Any Yjs-compatible editor, such as Tiptap or ProseMirror, can use it as a drop-in replacement for other Yjs network providers:

npm install @liveblocks/yjs

The WebSocket connection is managed by the Liveblocks infrastructure. The client SDK reconnects automatically, but the underlying state is stored on Liveblocks servers rather than the app developer's database. Persistence strategy, data retention, and access controls are governed by the Liveblocks service terms rather than any configuration file in this repository.

Genuine Limitations and Where It Is the Wrong Tool

The hosted architecture is also the main limitation. An organisation that cannot send document state to a third-party service for compliance, legal, or security reasons cannot use Liveblocks as deployed. There is no officially supported self-hosted server path in this repository.

The AGPL-3.0-or-later licence on some components is a real constraint. The README states that most of the repository is Apache License 2.0, but some components are AGPL-3.0-or-later. Any company modifying those components and running them as part of a service must disclose the source under AGPL terms. The LICENSE file and the licenses/ directory in the repository contain the full details.

Liveblocks also has no built-in conflict resolution outside of its own synchronisation model. A team building a use case that requires a specific CRDT algorithm or deterministic merge behaviour not covered by the Liveblocks state model would need to use @liveblocks/yjs and accept Yjs's operational semantics.

Finally, Liveblocks has a pricing tier for production use. The client packages are open source, but the collaboration infrastructure requires an account at liveblocks.io. Teams that need to estimate cost before building should check liveblocks.io/pricing directly.

Yjs as an Alternative Approach

Yjs is the most common alternative for teams that want CRDT-based collaboration without a managed service. The difference is architectural: Yjs is a CRDT library that runs in the browser and syncs via a provider, while Liveblocks is a complete service where the protocol, storage, and delivery are managed.

With Yjs, a team chooses a provider (y-websocket, y-webrtc, y-indexeddb) and operates the server themselves. This gives full control over data residency and the ability to run offline or in an air-gapped environment. The cost is infrastructure ownership: someone must run and maintain the websocket server, handle reconnection edge cases, and manage persistence.

Liveblocks provides @liveblocks/yjs specifically to allow Yjs-based editors to use Liveblocks infrastructure as the network provider. This means the CRDT logic stays in the browser (using Yjs) while Liveblocks handles transport and persistence, combining Yjs's document model with Liveblocks's managed delivery layer.

Maintenance and Licence Details

The last push was on 2026-09-26, and the most recent release is v3.24.2 from 2026-09-21. The release history in the repository and the public changelog show regular versioning activity.

The monorepo uses pnpm 10.33.0 as the package manager, enforced via a preinstall check. The build pipeline runs through Turborepo. Contributing guide, code of conduct, and security policy files are all present.

The licence is split: most of the codebase is Apache License 2.0, copyright 2021-present Liveblocks. Some components are AGPL-3.0-or-later. The specific files are identified in the LICENSE file and the licenses/ directory. Developers who need a clean permissive licence for all components should audit the exact package they depend on before publishing.

Editorial conclusion

Liveblocks suits teams building document editors, design tools, or AI-augmented apps that need presence, comments, and notifications without operating a synchronisation server. The managed infrastructure is the product. A team that must keep all collaboration data on their own servers should evaluate self-hosted alternatives before starting. Before committing, check the licensing terms: most of the repository is Apache 2.0, but some components carry AGPL-3.0-or-later, which imposes source-disclosure requirements on any modified version shipped as a service. The node engines field in package.json specifies node >= 24.x for the monorepo toolchain.

Frequently asked questions

Official sources

1. Issues
2. liveblocks/liveblocks on GitHub
3. Project website
4. README
5. Releases