Best Real-Time Collaboration Boilerplates (2026)

TL;DR

A collaborative SaaS starter is not complete when it only opens a WebSocket. The real architecture includes a local store, sync provider, authoritative backend, conflict policy, and migration seam—and your team must know which of those pieces it owns.

• Choose managed collaboration infrastructure when presence, shared state, comments, notifications, and editor integrations matter more than controlling every sync component.
• Choose an operator-owned Yjs or Automerge stack when local durability, transport choice, data portability, or a custom authorization model justifies owning more infrastructure.
• Choose a stateful room server when each room needs application-specific server logic. Treat the room runtime, durable storage, authentication, reconnect behavior, and conflict semantics as separate decisions.
• Use pub/sub or presence channels for ephemeral signals such as cursors and online state. Do not mistake event delivery for durable collaborative state or conflict handling.
• Treat Convex as a reactive server backend with optimistic UI and server-side transaction semantics, not as proof of a durable offline mutation queue or local authority.

Architecture decision tree

Start with the state that users share, not the vendor name.

1. Is the data ephemeral? Cursor positions, active selections, typing indicators, and “who is here” state can usually use presence or pub/sub. Losing an old cursor position after a disconnect is acceptable.
2. Does each room need custom server logic? A game, live auction, whiteboard session, or moderated event may need a stateful room process. The server can sequence messages and enforce room rules, but it still needs a deliberate persistence and recovery design.
3. Can two people edit the same document while disconnected? Use a document collaboration model such as Yjs or Automerge, then select local persistence and network adapters separately. The CRDT library is one module, not the whole backend.
4. Are users changing structured business records? Orders, roles, approvals, billing state, and cross-record constraints usually need an authoritative server. Optimistic UI can make the product feel immediate, but server validation, rejected writes, and recovery UX remain part of the contract.

This framing prevents two common mistakes: buying a document-collaboration service for a presence-only feature, or assuming a reactive backend automatically supplies durable offline writes and semantic conflict resolution.

Responsibility matrix

Responsibility	Managed collaboration service	Operator-owned Yjs or Automerge	Stateful room or pub/sub layer
Offline-loadable app shell	Your app	Your app	Your app
Local document persistence	Product-specific; verify the exact integration	Choose and test a storage adapter	Add explicitly if needed
Network transport	Managed room/provider connection	Choose or build adapters/providers	Room socket or channel transport
Authoritative business records	Usually your application backend	Usually your application backend	Room server or application backend
Authentication and authorization	Integrate application identity with room permissions	Design provider/server auth and per-document access	Enforce connection, room, and message permissions
Concurrent document merge	Service storage model or integrated CRDT	CRDT library plus application policy	Not automatic unless you add a merge model
Semantic conflict UX	Your product	Your product	Your product
Comments and notifications	May be managed features	Build or integrate separately	Build or integrate separately
Persistence, compaction, backups	Split between vendor and your app; verify exports	You own the selected storage path and operations	You own durable room state and recovery
Migration seam	Export/rebuild rooms, data, auth, and product integrations	Preserve document formats and replace adapters incrementally	Preserve message/state contracts and move room routing

The deepest module is the one that hides transport, reconnect, persistence, and collaboration behavior behind a stable application interface. If UI components import vendor room objects everywhere, the migration seam is shallow and switching costs spread across the codebase.

Managed Liveblocks boundaries

Liveblocks is a managed collaboration path with rooms, presence, storage, comments, notifications, and Yjs integration. Its documented client behavior includes reconnect and synchronization states, which helps an application show whether local changes are still synchronizing after a network interruption.

The offline boundary is narrower than “the product works offline.” The Liveblocks Yjs API documents IndexedDB support as experimental, and the option is disabled by default. Even when enabled, IndexedDB is document persistence; an app that must open with no network also needs its JavaScript, CSS, routes, fonts, and other shell assets available offline. Authorization, business-record validation, and rejected-write UX remain application concerns.

The self-hosting boundary is also specific. Liveblocks has published an open sync engine and development server/CLI, but the checked official material focuses that surface on local development and testing. It is not evidence of production self-host parity with the managed service. Do not make a production self-host decision until the current vendor documentation covers the exact features, operational guarantees, export path, and license boundary you need.

The repository license is mixed: most of the repository is Apache-2.0, while the server and CLI are covered by AGPL-3.0-or-later terms. Check the exact component rather than applying one license label to the whole platform.

Operator-owned Yjs architecture

Yjs supplies CRDT shared types such as maps, arrays, text, and XML fragments. Persistence and network transport are separate providers. That separation is useful because it lets a team choose an editor binding, local storage, and sync server independently, but it also means Yjs alone is not a hosted backend or a full application database.

A production Yjs stack typically needs these explicit modules:

• Document model: define which state belongs in shared Yjs types and which state stays in authoritative application records.
• Local persistence: y-indexeddb can persist a Yjs document in the browser so edits and document state survive reloads.
• Offline app shell: a service-worker or equivalent strategy is still required if the application itself must launch without a network connection.
• Network provider: select a WebSocket, WebRTC, managed, or custom provider and test reconnect plus duplicate-delivery behavior.
• Server persistence: decide how document updates or snapshots are stored, compacted, backed up, and restored.
• Authorization: authenticate the connection and enforce document-, workspace-, and operation-level permissions.
• Product conflict policy: define locks, review flows, or manual resolution for fields where a converged value can still violate user intent.
• Migration: version document schemas and keep the provider seam narrow enough to replace the transport or server later.

Yjs updates converge when providers exchange them, but convergence is not the same as preserving every business invariant. This is an architectural interpretation of the documented merge model: a deterministic result can still surprise both editors, violate a uniqueness rule, or conflict with an approval workflow. Use an authoritative server and explicit conflict UI wherever semantics matter more than retaining concurrent document edits.

Operator-owned Automerge architecture

Automerge follows the same broad local-first principle: users update local document copies, then peers exchange changes through selected network adapters. Automerge Repo separates storage and networking through adapters, so WebSocket, BroadcastChannel, MessageChannel, and other transports can sit behind a repository interface.

Its conflict model deserves product-level handling. Concurrent list and text insertions are retained in a deterministic order. Concurrent writes to the same object property select a visible value while retaining the competing values for optional inspection. That gives the application a seam for manual resolution, but it does not decide whether a status change, approval, ownership transfer, or billing update was semantically correct.

Plan major-version migrations as data migrations, not routine package bumps. The official Automerge 2-to-3 guide exists because document and API compatibility need deliberate review. Preserve test fixtures from real documents, exercise old-to-new loading, and verify mixed-client behavior before rolling a new major version to every collaborator.

Where Convex fits—and where it does not

Convex provides a reactive server database, server functions, subscriptions, and optimistic client updates. Its server mutations use optimistic concurrency control, serializable atomic transactions, and deterministic retries. Those are valuable server-authority semantics for structured SaaS records.

They are not evidence of a durable offline queue or a locally authoritative database. A client can render an optimistic result while a request is in flight, but an offline-capable product still needs to answer where pending mutations survive a reload, how they are scoped to the signed-in user, how retries are deduplicated, and what happens when the server rejects a stale or unauthorized write.

Convex can therefore be the authoritative record backend beside a document-collaboration layer, or the main reactive backend for online-first structured collaboration. Do not label that architecture offline-first unless its durable local write path and recovery behavior are separately implemented and tested.

Convex self-hosting is available under the backend's current FSL-1.1-Apache-2.0 license terms, including a competing-use restriction and future Apache-2.0 conversion. The official self-hosting documentation recommends the hosted product for teams that want hands-off operation. Evaluate the current license and operating surface directly before treating self-hosting as a low-burden escape hatch.

Stateful rooms and pub/sub are supporting layers

Stateful room servers and pub/sub platforms can be the correct modules, but they answer narrower questions than a collaboration architecture.

• A stateful room can own connection lifecycle, message ordering, room-specific validation, and transient server state. It does not automatically define durable local edits, document merge semantics, backups, or cross-room business invariants.
• A pub/sub channel can distribute presence, notifications, and application events. It does not automatically retain authoritative state or merge concurrent document edits.
• A document server can connect Yjs clients and persist updates. Its production fitness still depends on authentication, authorization, storage, compaction, backups, scaling, observability, and migration behavior.

This guide does not make factual capability, pricing, scale, or maturity claims about PartyKit, Hocuspocus, Ably, Pusher, or tldraw because those products were outside the approved source ledger. If one becomes a finalist, evaluate its current primary documentation against the responsibility matrix instead of relying on stale plan limits or generic “best” labels.

Offline recovery is a product contract

An offline-capable collaboration flow should survive more than a short socket drop. Test the full sequence:

1. Load offline: the app shell and the last authorized local document open without a network request.
2. Edit durably: pending document changes or structured-record mutations survive reload, browser restart, and process termination.
3. Show state: the interface distinguishes local, pending, synchronizing, synced, rejected, and conflicted states.
4. Reconnect safely: repeated handshakes or uploads do not duplicate operations, lose local changes, or expose another user's queued data.
5. Reauthorize: expired sessions and revoked access stop synchronization without silently discarding local work.
6. Handle rejection: server-side validation failures enter a visible recovery path instead of looping forever.
7. Resolve semantic conflicts: users can inspect and repair fields where deterministic convergence is not enough.
8. Upgrade data: old local documents, queued writes, and current server schemas can migrate without stranding edits.

For API-level queue, retry, and rejection design, use the offline-first API sync guide on APIScout. For library-level CRDT differences, use the Yjs vs Automerge vs Loro comparison on PkgPulse.

Conditional verdicts

• Choose Liveblocks when the managed room model and product primitives reduce meaningful engineering work, and its experimental offline boundary plus service migration seam match your risk tolerance.
• Choose Yjs when you want broad editor/provider ecosystem choices and are prepared to own persistence, transport, authorization, compaction, operations, and semantic conflict UX.
• Choose Automerge when local copies and adapter-based storage/networking fit the product, and your team is prepared to test conflict presentation and major-version document migrations.
• Choose Convex for server-authoritative reactive records and optimistic online UX. Add a separately designed durable local write path before calling the product offline-first.
• Choose a stateful room or pub/sub layer only after naming the persistence and conflict responsibilities it does not cover.

The right boilerplate is the one whose interfaces make these ownership seams visible. A demo with synchronized cursors proves that a connection works; it does not prove offline durability, authorization, recoverability, or an acceptable exit path.

Migration seams to preserve

Before committing to a collaboration stack, keep these seams narrow:

• represent application identity and room permissions in your own domain model;
• isolate vendor/provider setup behind one collaboration adapter;
• keep authoritative business records outside editor-specific document formats;
• version shared documents and test export/import with real fixtures;
• separate ephemeral presence from durable document state;
• store enough metadata to rebuild room membership and document ownership;
• test a provider outage and a read-only/export mode before launch;
• document which module owns app shell, local data, transport, server validation, comments, notifications, backups, and migrations.

If you are comparing the managed collaboration and reactive-backend options directly, read Convex vs Liveblocks vs Supabase Realtime. For Convex-specific starters, see Best Convex Boilerplates for SaaS. For a foundation you can operate and adapt yourself, see Best Open Source SaaS Boilerplates.

Source notes

The source ledger was accessed on 2026-07-25, and the critical package, offline-support, and license boundaries were rechecked on 2026-07-31. Package versions, product flags, license boundaries, and hosting options can change; verify the current documentation before making a production decision.

• Yjs: shared types and merge model, offline editing with y-indexeddb, connection providers, license, npm package metadata, and release record.
• Automerge: local-first introduction, conflict behavior, network adapters, and Automerge 2-to-3 migration.
• Liveblocks: product documentation index, client reconnection API, Yjs API and experimental IndexedDB option, open sync engine and dev server announcement, repository license, client package metadata, and release record.
• Convex: platform overview, optimistic concurrency control, self-hosting guidance, and backend license.