We are excited to announce the first step in open sourcing the Liveblocks server
stack. Today we’re releasing two packages to help you develop and test your
application with a Liveblocks server:

- `@liveblocks/server`, the core technology behind our WebSocket infrastructure,
  a realtime data storage and presence server compatible with two sync
  engines—[Liveblocks Storage](/docs/collaboration-features/multiplayer/sync-engine/liveblocks-storage)
  and
  [Yjs](/docs/collaboration-features/multiplayer/sync-engine/liveblocks-yjs).
- `liveblocks-cli`, a command line interface (CLI) with a bundled development
  server for running the Liveblocks stack locally with a single command.

If you’ve built with Liveblocks, you know that our client libraries and SDKs
have been open since day one, allowing you to read the code, debug issues, and
audit exactly what’s built into your application. We have long wanted to provide
this same experience for the full platform, and as of today, we have the first
piece ready: you can now develop and test your multiplayer applications built
with Liveblocks Storage or Yjs however you like, even in an air-gapped
environment. We will continue on this journey throughout the year; this is the
first step to making that commitment.

Our client libraries and SDKs remain open source under the Apache 2.0 license,
exactly as they are today, and nothing changes for users of the Liveblocks
platform, we are simply beginning to open up our server-side infrastructure,
starting now with the multiplayer core functionality. Server-side components are
released under the Affero GPL v3 license, with more parts of the tech stack on
the way.

<GitHubStars
  className="mt-4 mb-6"
  org="liveblocks"
  name="liveblocks"
  url="https://github.com/liveblocks/liveblocks"
/>

## What we’re releasing

### A realtime server package

The
[`@liveblocks/server` package](https://github.com/liveblocks/liveblocks/tree/main/packages/liveblocks-server)
is the brain that enables multiplayer collaboration, providing the server-side
runtime for two realtime sync engines: Liveblocks Storage and Yjs. This is now
available as a package you can inspect, audit, and run yourself. Whether you’re
building against it in CI or running integration tests, the source is there for
you to read, run, and build on.

<TerminalResolve1153 caption="The Liveblocks dev server running locally on port 1153." />

### A command line interface with an embedded dev server

The
[Liveblocks CLI](https://github.com/liveblocks/liveblocks/tree/main/tools/liveblocks-cli)
with its `dev` subcommand gives you a local development server for the
Liveblocks stack. If you’ve ever wished to start a Liveblocks dev environment
running on your machine or in a Continuous Integration environment with a single
command, this is it:

- No cloud dependency during routine development
- Fast iteration loops
- Predictable test environments

<Figure>
  <MuxVideo
    playbackId="X9OPbQekFzciskBNaARGH9Yo5wiEZqyqW01d7XV36bIs"
    alt="Dev server running locally"
    static={true}
  />
</Figure>

The dev server stores its data in a `.liveblocks/` directory relative to your
working directory, using a per-room SQLite database. This means your data
persists across restarts and you can inspect it directly.

This first release of the CLI is focused on providing the dev server. You can
expect our CLI to over time gain more dev and test cycle utility, as well as the
ability to manage Liveblocks infrastructure.

#### Run the dev server

Using the Liveblocks CLI, you can start the Liveblocks dev server with a single
command. It binds to port 1153 by default.

<InstallCommand
  options={[
    { label: "npm", command: "npx liveblocks dev" },
    { label: "yarn", command: "yarn dlx liveblocks dev" },
    { label: "pnpm", command: "pnpm dlx liveblocks dev" },
    { label: "bun", command: "bunx liveblocks dev" },
    {
      label: "docker",
      command: "docker run -p 1153:1153 ghcr.io/liveblocks/cli dev",
    },
  ]}
/>

Additionally, we’ve written two new related guides:

- [How to set up Continuous Integration (CI) testing](/docs/guides/how-to-set-up-continuous-integration-ci-testing)
- [How to set up End-to-End (E2E) testing with Playwright](/docs/guides/how-to-set-up-end-to-end-e2e-testing-with-playwright)

Learn more about the Liveblocks CLI in the new
[dev server documentation](/docs/tools/dev-server).

## Building in the open

This release marks a shift in how we develop Liveblocks. We’re moving to
building our software open-source-by-default for our server-side infrastructure,
starting with the multiplayer core and expanding from here.

If you use Liveblocks for realtime collaboration with a sync engine such as
Liveblocks Storage or Yjs, you’re trusting us with your data. We believe you
should be able to inspect and understand the infrastructure that handles it.
When your security team reviews Liveblocks, they should be able to read the
source and contribution history. We’re now developing that way, and work is
already underway to open more of the serverside platform.

## What this means for you

- **Develop locally, iterate faster.** Run a full Liveblocks environment on your
  machine—a complete open-source realtime collaboration server with no cloud
  dependency. Wipe and reset test data whenever you need to. It works in Docker
  on CI too.
- **Debug the full stack.** Read the server source, set breakpoints, and trace
  behavior from your client code through to CRDT resolution—no more guessing
  whether the issue is on your side or ours.
- **Improved AI assistance.** Agentic coding tools provide far more accurate
  answers when they can access the source of your dependencies, and inspect
  persisted data.
- **Audit your dependencies.** Your security team gets full source access and
  contribution history for the infrastructure handling your users’ data. And for
  teams building critical workflows on Liveblocks, the source being open means
  your investment is protected no matter what.
- **Help make it better, together.** Found a bug? See a documentation gap? We
  appreciate all community contributions, from feedback to fly-by pull requests.

## Licensing

We chose the [AGPL v3](https://www.gnu.org/licenses/agpl-3.0.en.html) license
for the server-side packages deliberately: it is an
[OSI](https://opensource.org/)-approved open-source license that protects
openness of the licensed code, and does not prevent commercial reuse—if you
modify the server and offer it as a service, you are simply obligated to share
those modifications back. For us this is the right balance for providing genuine
openness whilst not risking the sustainability of our business model.

Our client libraries and SDKs such as `@liveblocks/client`, `@liveblocks/react`,
`@liveblocks/node` and others remain under Apache 2.0. This split is
intentional; the code that runs in your application stays under permissive
terms, while the server code is made open through copyleft. This is a tried and
tested approach used by companies like Grafana Labs, Element (Matrix), and
Mattermost — each placing their server under AGPL while keeping client SDKs
under permissive licenses.

## What’s next

The dev server exposes the full Liveblocks API surface, but not every endpoint
is implemented yet. Today, you get the ability to connect to a realtime room to
use Liveblocks Storage and Yjs, the core of the multiplayer stack. Commenting,
notifications, and AI functionality are next, and we expect to ship them in the
coming months.

If you’d like to learn more, here are some resources for you:

- [Set up the dev server](/docs/tools/dev-server)
- [Download live examples](/examples)
- [Get started with Liveblocks](/docs/get-started)

We’d love your feedback—open an issue, start a discussion on
[GitHub](https://github.com/liveblocks/liveblocks), or reach out to us on
[Discord](/discord) or [X](https://x.com/liveblocks).

<GitHubStars
  className="mt-4 mb-6"
  org="liveblocks"
  name="liveblocks"
  url="https://github.com/liveblocks/liveblocks"
/>

---

## FAQs

<FaqSection />