AtlasWiki: multi-tenant knowledge base

The problem

Notion is where company knowledge goes to live on someone else’s servers, behind a subscription, one pricing change away from a migration project. Open-source wikis either look like 2008 or require a Kubernetes cluster and a part-time administrator. The gap: a wiki that feels modern, runs on a single box, and treats tenant isolation as a database guarantee rather than an if-statement.

What we built

A multi-tenant knowledge base with the editing experience people expect after Notion: a TipTap-based WYSIWYG editor with slash commands, nested pages, backlinks, and inline embeds, on top of an architecture that takes isolation seriously.

• Row-level security as the isolation boundary. Tenant separation is enforced by PostgreSQL RLS policies, not application code. A forgotten WHERE clause in some future endpoint cannot leak another tenant’s pages, because the database refuses to return them.
• Attachments as a service. Files attached to pages are not stored by the wiki at all. They go through the internal API of our self-hosted file platform over a private container network, one storage plane, consistent backups, no duplicated upload code.
• Fast by architecture. Server-rendered page shells, lean API payloads, aggressive indexing. Sub-100ms page loads on a mini PC, no CDN involved.

Architecture

FastAPI, React, PostgreSQL with RLS, deployed as containers behind a Traefik reverse proxy with TLS and security headers. Service-to-service calls ride an internal Docker network that is never exposed publicly.

Outcome

A knowledge base that costs nothing monthly, loads faster than the SaaS it replaced, and demonstrates the security pattern we now reuse everywhere: push isolation guarantees down to the database, integrate services over private networks, and let each platform do one job well.