atomic-server: Self-Hosted Storage and Sync for atomic.place

atomic-server as a Local-First Application Backend

atomic-server addresses the server-side requirements of atomic.place, a local-first workspace for documents, tables, files, chat, meetings, canvas, websites, and application screens. Its users are developers and organizations that want these capabilities without relying entirely on the hosted atomic.place service. The self-hosted server provides storage, search, sharing, and synchronization, while browser, desktop, and mobile clients can continue working locally and synchronize when connectivity returns.

The project is broader than a conventional headless CMS. Its data model can describe custom classes and properties in an Ontology Editor, and those definitions are shared through Atomic Schema. Tables can present the same data through Kanban, calendar, dashboard, and timer views. Collections support pagination, sorting, and filtering, while a REST API exposes JSON-AD as well as RDF, Turtle, N-Triples, and JSON-LD.

This makes atomic-server most relevant when application requirements involve offline-capable clients, shared structured data, and more than one client framework. A team that only needs conventional content pages behind an HTTP API has fewer project-specific reasons to adopt it. The repository includes JavaScript, React, Svelte, Rust, and Dart or Flutter libraries, but the exact maturity and API stability of each client are not documented in the README.

Signed Commits, Loro CRDTs, and AtomicServer Data Flow

The documented local-first design uses a Loro CRDT store and a synchronization protocol shared with applications built on the same data model. Identity functions as a key according to the README, edits are signed by the author, and each agent's local database is encrypted under that agent's key. This changes the server's role in a write path: it is not merely accepting anonymous JSON documents from a stateless application server.

Every write is represented as a signed Atomic Commit, and the project retains full version history. Clients can therefore work from local state and synchronize changes with a self-hosted AtomicServer or the hosted service. The README also describes live cursors, typing indicators, presence, collaborative documents, and shared canvases as features built on the collaboration model.

On the server side, the README identifies actix-web as the HTTP foundation and redb as the database engine. The Cargo workspace includes separate server, desktop, CLI, library, WebAssembly, and plugin components. The plugin runtime is built for `wasm32-wasip2`, and the server loads its artifact instead of linking it directly. The README describes server and client applications as one binary of roughly 70 MB, although no independent measurement is included here.

Data representation remains explicit at API boundaries. JSON-AD is the REST representation, while RDF-family formats support linked-data exchange. Search is described as fuzzy and typeahead-oriented, with the same index on client and server. Any performance figures in the feature list, including the search and response-time claims, are project claims rather than verified results from an independent review.

Self-Hosting AtomicServer with the Repository Compose File

The README links installation documentation at `https://docs.atomicdata.dev/atomicserver/installation` but does not reproduce a complete installation command. The repository does include a `docker-compose.yml`, so the shortest documented configuration path available here is to use that file. Its comment says a `.env` file can be generated with `atomic-server generate-dotenv`; this assumes the `atomic-server` executable is already available and does not explain how to obtain that binary.

The Compose file pulls `ghcr.io/ontola/atomic-server`, maps host port `80` to container port `80`, and attaches the named `atomic-storage` volume at `/atomic-storage`.

The Compose configuration that this command consumes is shown below. It also loads environment values from `.env`.

services:
 atomic-server:
 env_file: ".env"
 image: ghcr.io/ontola/atomic-server
 container_name: atomic-server
 ports:
 - 80:80
 volumes:
 - atomic-storage:/atomic-storage

The named volume makes storage separate from the container filesystem:

volumes:
 atomic-storage:
 driver: local

The repository excerpt does not document the first administrator operation, the expected URL beyond the provided homepage, a health check, or a backup command. It also exposes port `80` directly without displaying a reverse proxy or TLS configuration. The README mentions automatic HTTPS as a binary feature, but the Compose file does not show which environment variables enable it. Those details must be checked in the linked installation documentation before treating this compose file as a complete production deployment.

Permissions, Search, Publishing, and Plugin Boundaries

AtomicServer applies a common permission model across workspace objects. The README lists read and write rights, hierarchies, and invite links, while the Personal Data Store description associates identity with signing edits. This combination is relevant for shared workspaces, but the README excerpt does not describe the complete authorization evaluation rules or failure responses. It would be unsafe to infer a role hierarchy beyond the documented primitives.

Search covers workspace content through fuzzy, typeahead-oriented full-text search. The same index is reported on server and client, which supports local search while disconnected. Tables also support strict schemas, keyboard navigation, copy and paste, and several view types. These are application-level capabilities associated with the atomic.place repository, not separate guarantees that every client library exposes identical behavior.

The server has additional extension surfaces. Custom application screens can be written in plain JavaScript and backed by project data. The repository also supports Wasm plugins and lists integrations such as syncing from GitHub. Since plugin artifacts use `wasm32-wasip2`, plugin compatibility is constrained by that runtime boundary. The README does not document a plugin permission sandbox, signing policy, or deployment process in the supplied excerpt.

Website publishing includes version rollback according to the feature list. Group chat, attachments, replies, video meetings, shared notes, presence, and canvas are part of the wider workspace. These features make the repository unusually broad, but they also make compatibility testing important. A team interested only in AtomicServer storage should not assume that every workspace feature is a stable server API.

Why atomic-server Is Not Yet a Low-Risk 1.0 Platform

The clearest limitation is stated by the project itself: the status is alpha, and breaking changes are expected until 1.0. Recent release names reinforce that boundary. The listed releases include `v0.41.0-beta.8` and `v0.41.0-beta.7`, alongside `v0.40.4`, so deployment planning must account for version-specific client compatibility and migrations. The README does not provide a stable upgrade procedure or compatibility matrix.

The repository is not archived, and its last push was on 2026-10-16. That is evidence of recent repository activity, not proof that production interfaces are stable. For an application with its own persistence or protocol assumptions, alpha status is a direct engineering constraint rather than a minor documentation warning.

AtomicServer is also a poor fit when a hosted, conventional relational content API is sufficient. Its linked-data model, local-first synchronization, signed history, plugins, and multiple workspace surfaces create more design choices than a simple content delivery service. Its breadth can help teams building agent-native applications, but it can exceed the requirements of a straightforward website backend.

MIT Code Rights and Atomic Branding Restrictions

The README states that the project is MIT licensed, permits forking, modification, and sale, and points to `LICENSE` for the exact terms. Repository metadata identifies the license as a custom classification that GitHub cannot categorize, which conflicts with the README badge and prose. An adopter should therefore inspect the repository's `LICENSE` file rather than relying only on either summary.

The funding section says grants support the MIT licensing and a non-proprietary core. The trademark section places the Atomic names and logos outside that grant. Forks may modify and redistribute the code, but they cannot present themselves as the official Atomic Server. `TRADEMARKS.md` contains the stated policy, while `brand/` is identified as the source for artwork and icons.

Maintenance and upgrade costs are more operational than licensing costs. The repository contains multiple Rust workspace members and several client packages, so keeping server and client libraries on compatible versions is likely to matter in practice. The README provides no migration guide for releases between `v0.40.4` and the `v0.41.0-beta` line. Reviewing `CHANGELOG.md` is therefore part of assessing an upgrade, especially because breaking changes are expected before 1.0.

Editorial conclusion

Adopt atomic-server when a self-hosted backend for atomic.place, signed data history, offline synchronization, and schema-driven applications is central to the design. Do not adopt it without checking API compatibility if production stability is the priority, because the README labels the project alpha and expects breaking changes until 1.0. Before deployment, inspect LICENSE, confirm that the selected release and client libraries match, and validate the Docker persistence and HTTPS configuration for the intended environment.

Frequently asked questions

Official sources

1. Issues
2. ontola/atomic-server on GitHub
3. Project website
4. README
5. Releases