The Problem
Teams need the collaboration features of Slack and Notion—chat, documents, databases, files—without surrendering data to a third-party cloud. Existing self-hosted options are either single-purpose (chat OR docs) or require significant infrastructure expertise. Colanode attempts to combine all of it into one local-first, self-hostable package.
What This Does
Colanode is a monorepo with three apps: apps/desktop (Electron), apps/mobile (Expo), and apps/server (Fastify). The desktop and mobile apps write all changes to a local SQLite database first, then sync to the server via a background process. Real-time collaboration on documents and database records uses Yjs CRDTs, so concurrent edits merge gracefully.
The server (apps/server/src) is the substantial part: 32 database migrations (apps/server/src/data/migrations/), a full auth system (email, Google, password reset), file upload via TUS, Redis-backed job queues, and an AI assistant layer (apps/server/src/lib/ai/) that handles embeddings, chunking, and LLM calls. Storage is pluggable—local filesystem, Azure, or GCS (apps/server/src/lib/storage/).
How To Use It
The README references a hosting/ directory for self-hosting instructions, but that directory is not present in the analyzed file list. The server has a Dockerfile and a config.example.json, plus .env.example, but no documented setup commands are available in the repo analysis.
Setup: Clone the repo. The server requires PostgreSQL, Redis, and an S3-compatible storage backend. Copy apps/server/.env.example to .env and apps/server/config.example.json to config.json and fill in the values.
Running the server: cd apps/server npm install npm run dev
Running the desktop app: cd apps/desktop npm install npm run start
The exact start scripts are not confirmed—check the package.json files in each app directory.
Real-World Use
A small team (5–20 people) that wants full control over its data deploys Colanode on a single VPS with Docker. Team members use the desktop app for daily work—chat, shared wikis, project databases. The local SQLite cache means an editor on a train can keep writing; changes sync when connectivity returns. The team connects the same desktop app to a second Colanode server for a client project, keeping data isolated per organization.
Code Health & Issues
Med - No lockfile in apps/desktop/package.json - non-reproducible builds. Dependencies can drift between installs. Med - No tests for the desktop or mobile apps - only 3 test files exist in the entire repo, all presumably server-side. The CRDT sync logic is the highest-risk area and appears untested. Low - The mobile app appears minimal - apps/mobile/src has only 8 files compared to the server's 100+. It may be a stub or early prototype. Low - No license file in the analyzed structure - the README mentions Apache 2.0, but LICENSE is not in the file list. Verify before using. Low - 10 GitHub Actions workflows - CI is well-configured for builds and publishing, but only pr-tests.yml runs tests.
The Bottom Line
Colanode is a serious, well-architected effort—the migration structure, storage abstraction, and AI layer show real engineering depth. The local-first architecture is genuinely useful for teams with strict data requirements. However, the lack of tests on the sync layer and the missing lockfiles are real risks for production adoption. This is best suited to a team that wants a self-hosted Notion/Slack hybrid and is willing to invest in hardening it.