Colanode: a local-first Slack and Notion alternative you host yourself

The gap Colanode fills: chat, pages and databases in one self-hosted workspace

Most teams end up stitching together a chat tool, a wiki and a spreadsheet or database product, then pay three vendors and accept that the data sits on three sets of servers. Colanode's README frames the project as an all-in-one platform for collaboration with a local-first design, and the feature list maps directly onto that stack: real-time chat, rich text pages for documents and wikis, customizable databases with table, kanban and calendar views, and file management inside workspaces. The target user is a team or an individual who wants those four capabilities in a single workspace and wants to run the workspace on their own infrastructure. The README states that the self-hosted model exists so you retain control over your data, and the repository ships a hosting folder with a Docker Compose file and Kubernetes Helm charts rather than leaving deployment to the reader. That is a meaningful signal: the project treats self-hosting as a first-class path, not an afterthought bolted onto a SaaS product.

Local-first data flow: SQLite writes first, server sync in the background

The architecture described in the README is a client app (web or desktop) plus a self-hosted server. A single client can connect to multiple servers, and each server holds one or more workspaces for different teams or projects. The local-first part works like this: every change is written to a local SQLite database first, then a background process syncs it to the server. Reads also happen locally, so content you have permission to view is available immediately, and the documentation states you can keep working when either your machine or the server goes offline. That ordering matters for how you reason about failures. A dropped connection does not block editing; it delays propagation. The trade-off is that the client carries a full local store, and the sync process becomes the component you have to trust. The README does not describe conflict resolution for the sync layer itself beyond saying a background process handles it, so if you are evaluating this for a team that edits the same records constantly, that is a question to answer from the source rather than the README.

Yjs CRDTs for pages and database records, plain tables for messages

Colanode splits its concurrency model by entry type. Pages and database records use Conflict-free Replicated Data Types, specifically Yjs, so multiple people can edit the same entry at once and the system merges the updates. Deletions are tracked as specialized transactions rather than as simple row removals. Messages and file operations do not support concurrent edits and use simpler database tables. This is a deliberate split, and it is the right kind of split: applying CRDT machinery to an append-only chat log buys nothing, while applying last-write-wins to a shared document loses work. The consequence for operators is that two storage paths exist side by side, one CRDT-backed and one table-backed, and backup or export tooling has to handle both. The README does not document the on-disk shape of the CRDT updates or how to export a page as plain text, which is the kind of gap that matters if you are migrating off another tool.

Running the server: Postgres with pgvector, Redis, and a config.json that is the source of truth

Self-hosting requires Postgres with the pgvector extension, Redis or a Redis-compatible service such as Valkey, a storage backend for user files, and the Colanode server API Docker image. Storage defaults to the local filesystem and can be switched with the STORAGE_TYPE setting to S3-compatible, Google Cloud Storage or Azure Blob Storage. The configuration model changed in a way worth reading carefully: the server image ships with a full config.json, and that file is the single source of truth. Sensitive values are referenced with env://VAR_NAME, and file contents can be inlined with file://path/to/secret.pem; appending a question mark to either makes it optional. Only POSTGRES_URL and REDIS_URL are required out of the box. The README is explicit that environment variables no longer override regular config fields, and that only values tagged with env:// are read from the environment. Anyone carrying over an older deployment that relied on env overrides will find those settings silently ignored, which is the most likely upgrade trap in this release line. To customize, copy apps/server/config.json, edit it, and mount it in Docker Compose, or for Helm enable colanode.configFile.enabled and pass the file with --set-file colanode.configFile.data=./config.json.

Local development: npm scripts, Docker Compose, and the optional MinIO profile

The README gives a development workflow. Clone the repository, run npm install at the project root, then start individual apps. For the server, cd apps/server, copy .env.example to .env, and run npm run dev. Local dependencies come up with docker compose -f hosting/docker/docker-compose.yaml up -d, which starts Postgres, Redis and a mail server and uses filesystem storage by default. If you want an S3-compatible backend locally, add the s3 profile: docker compose -f hosting/docker/docker-compose.yaml --profile s3 up -d, which enables an optional MinIO service. One detail to note: the compose file includes a server service, and the README says to comment it out or override it when you want to run the API locally with npm run dev. Running both at once against the same Postgres and Redis is the obvious way to get confusing behaviour, so pick one path per session.

Where Colanode is the wrong tool

The hosted cloud servers, EU and US, are described as beta and free to use with pricing to be announced. That is not a foundation for a team that needs a vendor with a support contract and a published SLA today. The web app is called an early preview under testing, and the README warns you may encounter bugs or compatibility issues in certain browsers, so browser-only teams should treat the desktop app as the supported path. The CRDT boundary is another limit: because messages and file operations use simpler tables and do not support concurrent edits, Colanode will not behave like a document editor for chat content, and anyone expecting edits to a message to merge across clients should not assume that. Finally, the configuration model assumes you are willing to own a config.json and mount it. If your organization's deployment pipeline is built entirely around environment variables, the env:// indirection will feel like extra work, and the fact that plain env vars no longer override fields means a migration is not a drop-in.

How Colanode differs from running Mattermost plus a separate wiki

The closest comparison in self-hosted collaboration is Mattermost for chat with a separate wiki product alongside it, or a hosted combination like Slack plus Notion. The difference in approach is where the data lives and how edits converge. Mattermost is server-authoritative: the client sends a message, the server stores it, and the client's view is a projection of server state. Colanode inverts that. The client writes to local SQLite first and syncs in the background, and concurrent edits to pages and database records are merged through Yjs CRDTs rather than resolved by the server. That buys offline editing and immediate local reads, and it costs you a more complex client and a sync layer you have to reason about during incidents. A Slack plus Notion setup gives you two mature products with hosted reliability and two separate data stores to govern. Colanode gives you one workspace and one server to run, at the price of a younger project and a beta cloud option.

Licence, maintenance and what to check before you commit

Colanode is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, but it also requires that you preserve licence and notice files and state significant changes when you redistribute. If you plan to modify the server and ship it to customers, read the licence text yourself rather than relying on a summary; this is not legal advice. On maintenance, the release cadence visible in the repository shows v0.4.5 and v0.4.6 roughly a week apart in February 2026 and v0.4.7 in early April 2026, so the project is active but still in the 0.4 line, which is where breaking configuration changes like the config.json shift are most likely to appear. Budget for reading release notes before each upgrade, and pin your server image tag rather than tracking latest. The first things to verify on a trial deployment: that your Postgres has pgvector available before you start, that your mounted config.json is actually the file the container reads, and that the storage backend you chose behaves correctly for file uploads and deletes under the STORAGE_TYPE you set.

Editorial conclusion

Adopt Colanode if you want one self-hosted workspace covering chat, rich text pages and databases, and you are comfortable running Postgres with pgvector, Redis and a storage backend yourself. Do not adopt it if you need a hosted service with published uptime and pricing today, or if your team only needs a wiki and no chat. Before committing, verify the CRDT behaviour on the entry types you care about, confirm the config.json mounting path in hosting/docker/docker-compose.yaml against your deployment, and read the Apache-2.0 terms for the parts of the stack you intend to redistribute.

Official sources

1. colanode/colanode on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases