Self-hosted wiki on Docker, with backup & disaster recovery

Own your data

The single most common regret when leaving a SaaS wiki: "I wish I'd owned the data." Export tools break, vendor formats are opaque, and the migration project that was going to be a weekend turns into months.

Wikantik stores your pages as plain Markdown files in a directory you control. Your PostgreSQL database holds structured metadata, search indexes, user accounts, and the knowledge graph — but the content itself is readable and portable without any Wikantik tooling. You can check the page directory into git, back it up with rsync, or export it as a tarball at any time. There is no lock-in step.

Run it on Docker and PostgreSQL

The production deployment is a Docker Compose stack: the Wikantik application container, a PostgreSQL + pgvector database, and a backup sidecar. The application is released as a Docker image to GitHub Container Registry. Deploying a new version is a pull-and-restart, and rolling back is the same operation in the other direction.

The stack requires no special hardware or managed cloud services. A single Linux host with Docker installed is sufficient for a production deployment. Wikantik runs in production at wiki.wikantik.com on this exact stack.

Configuration is injected via environment variables from a .env.prod file (never checked into git). SSO credentials, database passwords, MCP access keys, and SCIM tokens all live there. The docker/entrypoint.sh script maps them to the properties the application reads at startup.

No lock-in: plain Markdown, exportable anytime

Your pages live in a bind-mounted directory on the host. The format is standard CommonMark Markdown with YAML frontmatter — readable in any text editor, importable into any other system that accepts Markdown. If you ever decide to move to a different wiki, your content goes with you in a format that doesn't require a decoder ring.

The database contains structured data — user accounts, groups, knowledge graph nodes, embeddings — that is Wikantik-specific. But a standard pg_dump produces a portable SQL file, and the restore script handles the full schema rebuild. There are no proprietary blob columns or binary-only formats.

Backup: 3-2-1 with off-site pull

The 3-2-1 backup model is a standard: three copies, two different storage types, one off-site. Wikantik implements this with a backup sidecar container that runs on a three-tier schedule:

• Daily snapshots — retained for 30 days on the production host
• Weekly snapshots — retained for 12 weeks
• Monthly snapshots — retained for 12 months

Each snapshot is a self-contained timestamped directory with a full PostgreSQL dump (gzip-compressed), a page-tree tarball, a SHA-256 checksum manifest, and a JSON status manifest. The checksum manifest is verified before any restore proceeds — the restore script will abort rather than load a corrupt snapshot.

Off-site pull: the ransomware control

An off-site NAS pulls the snapshot archive daily via rsync over a read-only SSH key. The key is restricted by a forced rrsync command: the NAS can read the backup directory and nothing else. Your production server holds no credentials that can write to or delete from the NAS. A ransomwared or compromised production host cannot reach the off-site archive.

The NAS independently verifies checksums after each pull and writes a Prometheus heartbeat metric. If the off-site pull fails or the checksums don't match, a missed heartbeat triggers a monitoring alert.

Disaster recovery

A backup system you've never tested is a backup system you don't trust. Wikantik includes a disaster recovery script (bin/dr-restore.sh) that automates a full stand-up on a fresh host from a backup snapshot:

1. Stages the compose files on the target host
2. Pulls or transfers the Docker image (from GHCR or a live source host)
3. Copies a backup snapshot from the NAS and verifies checksums on the target
4. Starts the database and runs the restore
5. Starts the application and runs a smoke test (bin/smoke-wiki.sh): health check, page render, search hit, changes feed

The script refuses to target the production host by accident and supports a --dry-run mode that prints the full plan without changing anything. Run it quarterly to confirm your recovery actually works.

Self-managed vs. fully-managed

If you want to run Wikantik yourself, the software is yours. If you'd rather have someone else handle the ops, fully-managed is available, priced on compute — not per seat. Your team can grow without a per-user licensing conversation.

Either way, the data is yours. Fully-managed doesn't mean your content lives in a system you can't export from.

Frequently asked questions

What does the 3-2-1 backup strategy mean in practice?

Three independent copies of your data exist at all times: the live production database and page tree on your server; tiered local snapshots (daily, weekly, monthly) on the same host; and an off-site archive pulled by a NAS on a daily schedule. The NAS always initiates the pull over a read-only SSH key — your production server cannot write to or delete from the off-site archive, which is the primary ransomware control.

How do I restore from a backup?

For disaster recovery to a fresh host, bin/dr-restore.sh automates the full stand-up: it stages the compose files, pulls or transfers the Docker image, copies and verifies a backup snapshot, restores the database, and runs a smoke test. For a manual in-place restore, stop the app, pick a snapshot, run the restore script in the backup sidecar (which verifies checksums before proceeding), and start the app. The search index rebuilds automatically on startup.

Is there a per-seat pricing difference between self-hosted and fully-managed?

No. Wikantik is not priced per seat. Self-managed is free software — run it yourself at no licensing cost. Fully-managed is priced on compute, not headcount, so your cost scales with usage, not with how many people you onboard.