DXOS: a TypeScript implementation of the DXOS protocols, SDK and Composer

A decentralized operating system, and the licence question it raises

DXOS is the Decentralized Operating System, described as a platform for building fully decentralized applications. The package description is blunter: a decentralized alternative to the commercial cloud for privacy preserving software.

The repository is the TypeScript implementation of the DXOS protocols, SDK, toolchain and Composer. The topics list the mechanisms that make it interesting for a technical reader: ai, automerge, crdt, database, decentralized and p2p. Automerge and CRDT are the data model, peer-to-peer is the transport, and the database sits on top of that.

That combination is what makes the interesting engineering claim. A decentralized application has no server to arbitrate writes, so the conflict resolution has to live in the data model itself, and a CRDT is how you get writes that converge without a coordinator. Automerge is the concrete implementation of that idea, and DXOS is the platform built on it.

The licence is the thing to read first, and it is not an OSI open source licence. The README states FSL-1.1-Apache-2.0, Copyright 2022 DXOS, and the package manifest records the same licence value. The Functional Source License with a future Apache grant is a source-available arrangement: the code is published, the licence converts to Apache 2.0 after a change date, and until then there are use restrictions. GitHub records the licence on the project as a custom one it cannot classify, which is consistent with that.

For a company evaluating this, the licence is the first question, not the architecture. The project entry lists the licence as a custom one GitHub cannot classify, with a pointer to the LICENSE file, and the README names FSL-1.1-Apache-2.0. Read the LICENSE file, because the FSL's use restrictions and change date determine whether you can ship what you build on top.

The project is not archived, the last push was on 2026-10-20, and the releases include v0.14.0 on 2026-10-10 and v0.13.0 on 2026-10-07, alongside a matching plugins release.

Composer, the IDE that ships with the platform

DXOS is also the home of Composer, an extensible IDE built for both real time and async collaboration. The README describes Composer as helping teams build and organize knowledge and create customizable AI-driven workflows, all in one modular, composable workspace, and it lives at composer.space.

This is the more unusual part of the repository. Most decentralized platforms are libraries, and the IDE in which you use them is somebody else's product. Here the IDE is a first-class deliverable in the same monorepo, which means the collaboration model of the platform is exercised by a real application rather than only demonstrated in test fixtures. A workspace that several people edit at once, with changes propagating peer to peer, is the hardest case for a CRDT-backed store, and Composer is that case shipped as a product.

The documentation is split accordingly, with an SDK Intro and an API Reference on docs.dxos.org, a separate Composer Intro section, and a Repository Guide in the repository itself at REPOSITORY_GUIDE.md. The README points contributors to that guide for how to set up for development and contribution, alongside a code of conduct, an issue guide and a PR contribution guide in CONTRIBUTING.md.

The AI-driven workflow angle is worth noting as a design decision rather than a feature list. The wording is customizable AI-driven workflows inside a modular, composable workspace, so the AI part is described as something you configure rather than a feature you switch on. Whether that is a productive way to work is a question for the team using it, but the commitment to make the workflows part of the workspace composition is the notable part.

The homepage is dxos.org, the developer documentation is docs.dxos.org, and the community channel is a Discord linked from the site.

A monorepo whose build is driven by moon and changesets

The repository layout is a large TypeScript monorepo, and the tooling tells you how it is actually run.

The workspace is pnpm based, with a pnpm-workspace.yaml and a pnpm-lock.yaml, and the build goes through moon, with the build script defined as moon run :build. A .moon/ directory holds the moon configuration. Releases go through changesets, with a .changeset/ directory and scripts for changeset version, changeset publish and a check-changeset script that the CI presumably runs on every pull request. A scripts/sync-versions.mjs step keeps the version numbers aligned across packages during a release.

The package scripts in the root manifest show the shape of the release process in detail. There are checks for cycles between packages, for public dependencies, for the publish configuration, and for whether packages are actually published, plus a script that compares against the changed set. Formatting is handled by oxfmt with a format-check variant, and linting by oxlint, both with their own config files, alongside a .prettierrc for the code that is still formatted that way.

There is also a patches/ directory, which is the marker of a monorepo that carries local modifications to upstream dependencies, and a .pnpmfile.cjs, which customises the pnpm install itself. The .prototools directory suggests protobuf definitions are versioned with their own tool, and the .trace-imports/ directory is a tracing setup for import resolution.

One script in the list is worth a second look. The credentials script pipes a set of exported environment variables through op inject, referencing secret paths like op://CI/Claude - agents/credential and op://CI/dev.dxos.network/CLOUDFLARE_API_TOKEN. That is 1Password service account or vault injection, and it tells you the project's own CI pulls its secrets from 1Password rather than a cloud secret manager.

The repository reads like an agent-first codebase

The top-level listing of this repository is unusual, and it is worth describing because it tells you something about how the project works.

There are directories and configuration for a wide range of coding agents. There is a.claude/ directory and a.claude-plugin/ directory, a.cursor/ directory, a.windsurf/ directory, a.zed/ directory, a.opencode/ directory and an.opencode.yaml file, a.mcp.json file, a.agents/ directory, a skills/ directory with a skills-lock.json, an agents/ directory, a.coderabbit.yaml, plus a GEMINI.md, a CLAUDE.md and an AGENTS.md at the root. The.fleet/ and.depot/ directories are less obvious, and there is an.actrc for a runner called act.

What this amounts to is a repository where the agent tooling is part of the source tree rather than a personal preference of one contributor. The agent instruction files sit next to the code, and the skills directory with a lock file suggests the project's own skills are tracked as a dependency, which is how a team keeps every contributor and every agent on the same instructions.

There is also a plans/ directory and a docs/ directory, and the root documentation set is unusually complete for an open source project: AGENTS.md, AUDIT.md, CHANGELOG.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, OPS_GUIDE.md, REPOSITORY_GUIDE.md, SECURITY.md, TROUBLESHOOTING.md and CLAUDE.md, with the REPOSITORY_GUIDE.md also being a documented tool for setting up a development environment.

For an adopter this matters in a practical way. A platform with a dozen packages, a moon-driven build and changesets-based releases is a codebase where you will spend real time on the onboarding path, and the fact that a maintained guide exists for that is the main reason the setup is not a black box.

What the SDK looks like as a consumer

The npm package that most consumers would reach for is @dxos/client, and the README badges track its version and download count. The root package is @dxos/dxos, and the repository publishes a set of related packages under the packages/ directory.

The SDK Intro at docs.dxos.org is the entry point for using the platform, with the API Reference as the detailed lookup. Since the README does not give an install command or a code sample, the honest way to describe the first use is that it starts in the documentation, not in a snippet. The reference to a Repository Guide for development setup, and the existence of a fixtures script at tools/fixtures/bin/fixtures.mjs, suggests that the intended way to evaluate the SDK is to run it against prepared fixtures rather than to paste a fragment into a scratch project.

That last point is worth flagging for evaluators. A platform whose value is in its replication semantics cannot really be assessed from an API listing, because the behaviour that matters is what happens when two peers edit the same object concurrently. Anything you read in a reference will tell you the shape of the API; only running it will tell you whether the convergence behaves the way your application needs.

The plugin release published alongside v0.14.0 on the same day suggests the plugin surface is versioned in step with the core, which is a detail to check before you pin versions across a workspace with plugins.

Where DXOS is the wrong choice

Three situations call for something else, and one of them is about the licence rather than the technology.

The first is a single-user application with no collaboration. If there is one writer, a server is fine, a CRDT buys you nothing, and the peer-to-peer layer becomes complexity you have to operate and debug. DXOS is built for the multi-writer case, and using it for the single-writer case means paying for a distributed system you do not need.

The second is a closed-source commercial product. FSL-1.1-Apache-2.0 is source-available with a change date before it becomes Apache 2.0, and the use restrictions apply during that window. If your distribution model conflicts with those restrictions, no amount of architectural fit makes it the right choice, and the alternative of building on the underlying CRDT layer directly, or using a conventional database, sidesteps the question entirely.

The third is maturity. The version numbers are in the low teens of a 0.x line, releases are frequent, and the release cadence in October 2026 was two version bumps and a matching plugins release inside about a week, which is a project moving quickly. That is a virtue in a young platform and a risk in something you depend on.

One more practical constraint. The Composer side of the project is a browser application, and a distributed, real-time collaborative IDE is a heavy thing to run and to integrate with. If your interest is the SDK alone, the workspace tooling is a much larger surface than you need, and the packages/ directory is where you would be looking instead.

Editorial conclusion

Adopt DXOS if you are building a collaborative application that needs offline-tolerant replicated data and you want a TypeScript SDK and a reference IDE to build against, and you are comfortable with a licence that is source-available rather than open source. Do not adopt it for a single-user web app, for a closed-source commercial product without reading the FSL terms, or if you need a maturity record. Verify first that the FSL-1.1-Apache-2.0 licence suits your distribution model, that the version of @dxos/client on npm matches the core release you are targeting, and that you have read the Repository Guide before you set up a development environment.

Frequently asked questions

Official sources

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