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

What Colanode replaces, and for whom

Colanode is an all-in-one collaboration workspace: real-time chat, rich text pages for documents and wikis, customizable databases with table, kanban and calendar views, and file management. The README frames it as a Slack and Notion alternative, and the topic list on the repository repeats that pairing. The audience is narrower than that framing suggests. It is for teams that already accept running their own infrastructure, because the self-hosted model is the point rather than an option. A single person can use it, and the README says it adapts from a small project to an entire organization, but the setup cost only pays off when several people share the workspace.

The reason to pick it over a hosted product is data control. The README states that with the self-hosted model you retain full control over your data, and every change is written to a local SQLite database before it reaches a server. That matters when the content is sensitive enough that a third-party host is a problem, or when you want the workspace to keep working through a network outage. It is not a drop-in replacement for either tool it is compared to. Slack and Notion have years of integrations, permissions tooling and admin surfaces that the README does not claim. Colanode gives you the core collaboration loop on infrastructure you own.

Local SQLite first, CRDTs for pages, plain tables for messages

The architecture is split between a client app (web or desktop) and a self-hosted server. One app can connect to multiple servers, and each server holds one or more workspaces. After login you pick a workspace, and from there you send messages, edit pages or update database records. Reads happen locally, so any content you have permission to view opens immediately rather than after a round trip.

Writes take the local-first path. Every change lands in a local SQLite database first, and a background process syncs it to the server. The README states this explicitly: the background process handles synchronization so you can keep working even if your computer or the server goes offline. That is the whole design in one sentence, and it also explains the failure modes described further down.

The interesting split is in how concurrent edits are handled. Pages and database records use Conflict-free Replicated Data Types powered by Yjs, so multiple people can edit the same entry and the system merges the updates. Deletions are tracked as specialized transactions rather than as a simple flag. Messages and file operations do not support concurrent edits at all and use simpler database tables. That is a deliberate narrowing: chat messages are append-only in practice, so a CRDT would add merge machinery for a conflict that rarely happens. The cost is that anything built on top of messages cannot assume the same merge guarantees that pages get.

Self-hosting Colanode with Docker Compose and config.json

The repository keeps deployment files under hosting/. The Docker Compose file is hosting/docker/docker-compose.yaml, and there is a separate hosting/kubernetes/ folder with Helm charts and its own README. Before running anything, you need Postgres with the pgvector extension, Redis (the README notes any Redis-compatible service works, for example Valkey), and a storage backend. The default storage is the local filesystem, and STORAGE_TYPE switches it to S3-compatible, Google Cloud Storage or Azure Blob Storage.

The server image ships with a full config.json, so most defaults work without touching environment variables. Only POSTGRES_URL and REDIS_URL are required out of the box. The config file is the single source of truth, and the loader resolves pointers at runtime: env://VAR_NAME pulls a value from an environment variable, and file://path/to/secret.pem inlines the contents of a mounted file. Appending ? to either makes it optional. This is the part that surprises people, because environment variables no longer override regular config fields. Only values explicitly tagged with env:// are read from the environment.

To customize, copy apps/server/config.json, edit it, and mount or bind it when using Docker Compose. For Helm, enable colanode.configFile.enabled and pass your file in, as the Kubernetes README describes. To bring up local dependencies for development, run this from the project root:

docker compose -f hosting/docker/docker-compose.yaml up -d

That starts Postgres, Redis and a mail server, using filesystem storage by default. If you want an S3-compatible backend locally, the compose file includes an optional MinIO service behind a profile:

docker compose -f hosting/docker/docker-compose.yaml --profile s3 up -d

The compose file also defines a server service. When you want to run the API locally with npm run dev, the README says to comment out or override that service. For a first real use, the fastest path is not self-hosting at all: the web app at app.colanode.com needs no installation, and the README notes it is in early preview and may show bugs or compatibility issues in some browsers. The desktop app is on the downloads page and is described as better for performance. Both clients can connect to the free beta cloud servers in the EU and US, which the README says are free for now with pricing to be announced.

Where the local-first model gets uncomfortable

The same design that lets you work offline makes recovery harder. Because changes are applied locally first and synced by a background process, a client that has been offline for a long time accumulates a queue of operations that has to reconcile with whatever the server received in the meantime. The README does not document what happens to that queue if the local SQLite database is lost, or how to inspect pending operations. If a machine dies before syncing, the documentation gives no procedure for recovering its unsynced work.

Concurrent editing is also uneven by design. Pages and database records merge through Yjs, but messages and file operations do not support concurrent edits. If your workflow assumes that two people editing the same message resolves cleanly, that assumption is wrong here.

The configuration model is a second source of friction. Because environment variables no longer override regular config fields, anyone migrating from an older deployment that relied on env vars will find their settings silently ignored unless the config file tags those fields with env://. The README is clear about this, but it is an easy mistake to make and a hard one to notice, since the server starts fine with the wrong values.

Finally, the web app is explicitly labeled early preview and under testing. If browser compatibility matters for your team, the desktop app is the documented alternative, and that means distributing and updating a desktop binary rather than pointing people at a URL.

Colanode compared with Notion, and with running your own wiki stack

The comparison people search for is Colanode versus Notion. The difference is not the feature list, it is where the data lives and who operates the service. Notion is a hosted product: you sign up, and the company runs the infrastructure, the backups and the upgrades. Colanode inverts that. You run Postgres with pgvector, Redis and a storage backend, and you choose between local filesystem, S3-compatible, Google Cloud Storage or Azure Blob Storage for files. The trade is operational work for control, and the local-first client means the workspace keeps functioning offline in a way a hosted editor does not.

The second alternative is assembling the same capabilities from separate self-hosted tools: a chat server, a wiki, and a database or spreadsheet tool, each with its own accounts and backups. Colanode's argument is that these share one workspace, one permission model and one sync engine, so a page can reference a database record without an integration in between. Whether that consolidation is worth it depends on how much you value having one system to operate. If you already run a chat server your team likes, migrating chat to get the page editor is a poor trade.

The third option is simply using the free beta cloud servers the project offers. That removes the self-hosting work entirely, but the README says pricing will be announced, so the free tier is not a commitment you can plan a budget around, and the data-control argument that justifies Colanode in the first place no longer applies.

Maintenance, licence and the cost of staying current

Colanode is licensed under Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive licence, and it means you can fork the server if the project stalls. It does not give you any warranty, and the SECURITY.md file in the repository is the place to check for the disclosure process rather than assuming one exists.

On maintenance, the last push to the default branch was on 2026-04-03, and the most recent release is v0.4.7 from the same day. The two releases before it, v0.4.6 and v0.4.5, landed on 2026-02-09 and 2026-02-02. That is a release cadence measured in months rather than weeks, and the gap between the 0.4.x line and the 1.0.0 version in the root package.json suggests the project does not consider itself finished. The repository is not archived, but the version number and the spacing between releases are the honest signals here, not the activity level.

Upgrade cost is shaped by the configuration model. Because config.json is the single source of truth and the server image ships with a full default file, a new image may introduce config keys your mounted file does not have. The README does not document a migration procedure for config files between versions, so the practical step is to diff your mounted config.json against apps/server/config.json from the new tag before deploying. The same applies to the Helm path, where the config file is passed in with --set-file and is therefore entirely under your control. The database side is the bigger unknown: the README does not describe schema migrations or whether a server version can run against a database created by an older one. Verify that against the release notes for the specific version you are moving to.

Editorial conclusion

Adopt Colanode if your team wants chat, rich text pages and structured databases in one workspace and you are prepared to operate Postgres with the pgvector extension, Redis and a storage backend. Skip it if you need a hosted product with a published support commitment, or if you only want chat, because the database and editor features are where the self-hosting cost pays off. Before committing, mount your own config.json and confirm that the values you change actually take effect, since only fields tagged with env:// are read from the environment. Then verify that your storage backend survives a server restart, because the README documents four backends but not a migration path between them.

Frequently asked questions

Official sources

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