Self-host Docmost on Netcup — a Confluence and Notion alternative for under 11 €

TL;DR: Running Docmost on Netcup in 5 minutes

Self-host Docmost on a Netcup VPS to run a real-time collaborative wiki without paying per-seat to Atlassian or shipping every page of internal knowledge to a US-jurisdiction database. Docmost is a self-hosted Notion alternative and Confluence alternative with multi-workspace spaces, page history, comments, diagrams, and live cursors — and it ships as three containers.

• What it is: a TypeScript / Node.js wiki with PostgreSQL 18 storage and Redis-backed real-time collaboration.
• Competes with: Confluence, Notion, Outline, BookStack, XWiki.
• Hosting profile: ~1 GB RAM minimum, 2 GB comfortable. Three Docker containers (app, Postgres, Redis).
• Storage: text-heavy and modest until you start uploading attachments — local disk by default, S3 optional.
• License: AGPL-3.0 for the core; an enterprise edition adds SSO, RBAC, and audit features under a separate licence.
• Latest release: v0.80.x line, shipped from the docmost/docmost GitHub org.

Install on a fresh Debian 12 box:

mkdir -p /opt/docmost && cd /opt/docmost
curl -O https://raw.githubusercontent.com/docmost/docmost/main/docker-compose.yml
sed -i "s/REPLACE_WITH_LONG_SECRET/$(openssl rand -hex 32)/" docker-compose.yml
docker compose up -d

Primary pick: VPS 1000 G12 — 4 vCore, 8 GB DDR5 ECC, 256 GB NVMe, around 10 € a month. Plenty of headroom for Postgres 18, Redis, the Node app, and a Caddy reverse proxy in front, with room to throw a second self-hosted service on the same box.

• First month free: 5799nc17800061380
• Second code: 5799nc17804382700
• Third code: 5799nc17800061382

Introduction

Most teams that adopt Confluence end up with a five-figure annual line item by year three, and most teams that adopt Notion end up wondering where their data actually lives when the renewal email lands. Docmost sits in the gap: a real-time editor, the page tree people expect from a wiki, comments and history that work, and an export path that is just pg_dump plus a tar of the storage directory.

That makes the maths easy. A Netcup VPS at roughly 10 € a month runs Docmost for a team of ten without breaking a sweat — and the same hardware runs it for a team of fifty if traffic is bursty rather than constant. Compare that to per-seat SaaS pricing and the break-even is somewhere around the third or fourth seat. Self-hosting also means the company knowledge base is on hardware in Nuremberg, Vienna, or Karlsruhe rather than on whichever cloud the vendor happens to be reselling this quarter.

By the end of this article: a working Docmost instance behind HTTPS, automatic restarts on host reboot, a daily Postgres dump, and a clear sense of which Netcup tier matches the size of the team you are putting it in front of. No "official partner" reseller markup, no enterprise sales call.

A scope note. If your "wiki" is one person writing four notes a month, do not bother — a static site generator costs nothing to host. Docmost earns its keep at the team level, where the collaborative editing, comments, and permission model actually move the needle.

What is Docmost?

Docmost is an open-source wiki and documentation platform built for teams that need a Confluence-style page tree and Notion-style real-time editing without giving either vendor a credit card. It runs as three Docker containers, stores everything in PostgreSQL, and exposes a single web app on port 3000.

Architecture

Three containers, three jobs:

• docmost — the Node.js application. Serves the web UI, the REST API, and the WebSocket endpoint that powers live cursors and collaborative editing. Listens on port 3000. Mounts a volume at /app/data/storage for uploaded attachments.
• db — PostgreSQL 18. Stores pages, spaces, users, permissions, comments, page history, and a full-text search index. The official compose pins the major version, so upgrades are deliberate rather than accidental.
• redis — Redis 8, with appendonly yes and maxmemory-policy noeviction. Backs the real-time collaboration layer and the background-job queue.

Attachments and uploads go to local disk by default. The configuration also supports S3-compatible object storage if you want to keep the VPS disk free of binary blobs — useful once a wiki accumulates years of screenshots and PDFs.

Who maintains it

Docmost is a relatively young project that grew quickly: roughly 20k GitHub stars, an active release cadence (multiple releases per month on the v0.80 line), and a dual-licence model that funds development without making the core proprietary. The core is AGPL-3.0, which is the right licence for an internal-knowledge tool — any vendor that wants to ship a hosted Docmost-derived service has to publish their changes back. Enterprise features (SAML SSO, group-level RBAC, audit log, page verification workflows) live under a separate enterprise licence and are clearly marked as such in the repository under apps/server/src/ee and friends. The community edition is a complete wiki on its own.

How big does the data get

Docmost is text-first, which keeps the database small. A wiki with thousands of pages, page history, comments, and a years-deep audit trail tends to land in the low gigabytes for the Postgres data directory. The footprint that matters is the storage volume: every uploaded image, attached PDF, embedded diagram export, and avatar lives under /app/data/storage. A team that pastes screenshots liberally can put 20–50 GB in there over a year without trying.

The license is AGPL-3.0 for the core. That matters: anyone who modifies Docmost and offers it as a service is obligated to publish the modifications. It is the legal mechanism that keeps the open-source edition from quietly turning into a SaaS-only project the way some of its predecessors did.

How to use Docmost

Day-to-day, Docmost behaves like the wiki the team kept asking for and was never quite given. The interesting choices happen in the first week, while the page tree is still small enough to restructure.

Core concepts

• Workspace: the top-level container. Most self-hosted instances run a single workspace; the multi-workspace model exists for organisations that want hard isolation between, say, engineering and HR.
• Space: a sub-container within a workspace, with its own permission boundary. Spaces map naturally to teams, projects, or product lines. Each space owns its page tree.
• Page: the unit of content. Pages can nest arbitrarily deep, support drag-and-drop reordering, and live in a tree on the left rail.
• Block: the editor primitive. Blocks include rich text, headings, code, tables, callouts, images, and embedded diagrams (Draw.io, Excalidraw, Mermaid).
• Comment: an inline thread anchored to a selection. Comments persist alongside the page and resolve in place rather than turning into stale margin notes.
• Page history: every save is a revision, browsable and revertable. There is no "undo limit" — the database keeps the lineage.

Day-to-day workflow

A team member opens the URL, picks a space, lands on the page tree, types / to bring up the block menu, and starts writing. Two people editing the same page see each other's cursors live; the editor merges keystrokes via the WebSocket layer rather than fighting over a "last write wins" save. Comments anchor to the highlighted text, mentions notify the named user, and the search bar covers titles, body, and attachment filenames once the index has caught up.

Permissions cluster at the space level: a viewer can read but not edit, an editor can write but not invite, an admin owns membership. That is enough for most teams; the enterprise-edition group permissions add another layer if you actually need it.

Integrations and extensibility

Docmost exposes a REST API for ingestion and migration. The repository ships importers for Confluence and Notion — pointed at an export, they reconstruct the page tree, preserve internal links, and bring across attachments. Diagrams (Draw.io, Excalidraw, Mermaid) are first-class blocks rather than embedded iframes, which means the diagram source travels with the page rather than living in some third-party SVG host.

Authentication is local by default. The enterprise edition adds SAML, OpenID Connect, and LDAP; for a single-tenant self-hosted deployment behind a VPN or Cloudflare Access, the built-in user database is usually enough.

Backup and operational reality

Three things matter for backups:

1. The PostgreSQL database. pg_dumpall from inside the db container, gzipped, on a daily cron — this is your truth. Page content, comments, history, users, permissions all live here.
2. The storage volume at /app/data/storage (or your S3 bucket if you switched). Every uploaded attachment and image. Lose this and the wiki is full of broken-image icons.
3. The .env and docker-compose.yml. Specifically the APP_SECRET — it signs session tokens, and if you regenerate it, every user gets logged out. Treat it like a database password.

Postgres history grows linearly with edits. If the team is heavy on edits and the database starts to feel large, the Docmost docs cover history pruning settings — but for most teams the volume is small enough that "back up everything, prune later" is the right answer.

Quick Start Guide

Six steps from a fresh Netcup box to a working Docmost instance behind HTTPS, with auto-restart and a daily backup.

1. Provision the box

Sign up for the VPS 1000 G12 at netcup.com using coupon 5799nc17718015261 for one free month. Pick Debian 12 as the image, paste in your SSH public key, and skip the password option entirely. As soon as the VPS boots, SSH in and harden it:

# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Reboot, reconnect, confirm sshd came back cleanly before closing the existing session.

2. Install Docker

Docmost ships as Docker Compose. Three coordinated containers, all version-pinned in the upstream compose file — running them by hand would be a worse trade than just installing Docker.

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
docker compose version

docker compose version should report v2.20 or newer. Older releases miss the dependency-condition syntax the upstream compose relies on, and you will spend the rest of the evening debugging container start order.

3. Install Docmost

Pull the official compose, generate a real APP_SECRET, and replace the placeholder password.

mkdir -p /opt/docmost && cd /opt/docmost
curl -O https://raw.githubusercontent.com/docmost/docmost/main/docker-compose.yml

The shipped compose has three placeholders to replace: REPLACE_WITH_LONG_SECRET, STRONG_DB_PASSWORD (in two places — application env and Postgres env), and APP_URL. A scripted way to do it:

APP_SECRET=$(openssl rand -hex 32)
DB_PASS=$(openssl rand -hex 24)
sed -i "s/REPLACE_WITH_LONG_SECRET/${APP_SECRET}/" docker-compose.yml
sed -i "s/STRONG_DB_PASSWORD/${DB_PASS}/g" docker-compose.yml
sed -i 's|http://localhost:3000|https://wiki.example.com|' docker-compose.yml

Note DB_PASS is hex-only on purpose. The Postgres image will accept anything, but the application reads the same value out of an env var that gets URL-encoded into a DSN — special characters there are an opaque footgun. A 48-character hex string is plenty of entropy and avoids the problem entirely.

Bring it up:

docker compose up -d
docker compose ps

Within thirty seconds all three containers should be running. The web app is now answering on port 3000 over plain HTTP — do not expose this directly.

4. Put Caddy in front

Caddy fetches a Let's Encrypt cert the first time it sees an HTTPS request — no certbot, no cron, no expiry surprises. It also handles WebSocket upgrades correctly with no additional configuration, which Docmost's real-time editor depends on.

apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -fsSL 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' \
  | gpg --dearmor -o /usr/share/keyrings/caddy-stable.gpg
echo "deb [signed-by=/usr/share/keyrings/caddy-stable.gpg] https://dl.cloudsmith.io/public/caddy/stable/deb/debian any-version main" \
  > /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

Replace /etc/caddy/Caddyfile:

wiki.example.com {
    reverse_proxy localhost:3000
    request_body {
        max_size 100MB
    }
}

The max_size line matters — Caddy's default body limit is small enough that uploading a moderately sized PDF will fail with a confusing 413. Reload Caddy with systemctl reload caddy. Within thirty seconds the cert is provisioned and https://wiki.example.com answers.

5. First run and onboarding

Open the URL, register the first account — this becomes the workspace owner. Create a space (call it "Engineering" or whatever your first team is), invite the rest of the team via email, and start writing. The block menu opens with /; the search bar lives in the top rail; spaces and the page tree live on the left.

Confirm the WebSocket is working: open the same page in two browser windows, type in one, watch the cursor and characters appear in the other. If they do not, the reverse proxy is not upgrading WebSocket connections and the editor has fallen back to polling mode. The Caddy config above handles this correctly out of the box; nginx requires explicit Upgrade and Connection header passes.

6. Schedule backups

The compose already sets restart: unless-stopped on every service, so a host reboot brings the stack back automatically. Add a daily database dump and a weekly storage snapshot:

# /etc/cron.daily/docmost-db-backup
#!/bin/sh
set -e
mkdir -p /srv/docmost-backups
docker exec -t docmost-db-1 pg_dumpall -U docmost \
  | gzip > /srv/docmost-backups/db-$(date +\%F).sql.gz
find /srv/docmost-backups -name 'db-*.sql.gz' -mtime +14 -delete

# /etc/cron.weekly/docmost-storage-backup
#!/bin/sh
set -e
docker run --rm \
  -v docmost_docmost:/data:ro \
  -v /srv/docmost-backups:/backup \
  alpine tar czf /backup/storage-$(date +\%F).tar.gz -C /data .
find /srv/docmost-backups -name 'storage-*.tar.gz' -mtime +30 -delete

chmod +x both. Push the resulting tarballs to off-site cold storage on a separate cadence — restic to a Backblaze B2 bucket is the cheap, durable answer. The volume name (docmost_docmost) follows Docker Compose's <project>_<volume> convention; verify with docker volume ls if it differs.

Choosing the Right Netcup Server for cheap Docmost hosting

Docmost's resource curve is gentle. The Node app idles at a few hundred megabytes, Postgres 18 sits comfortably at half a gigabyte under normal load, and Redis 8 with noeviction will use whatever it needs and no more. The decision is less about peak resource use and more about how many people are editing concurrently and how aggressively the team is going to upload attachments.

VPS 500 G12 — the thrifty starter

Specs: 2 vCore, 4 GB DDR5 ECC, 128 GB NVMe, traffic included. Around 6 € a month (verify on netcup.com).

Comfortably above Docmost's documented 1 GB RAM minimum, with room for Postgres, Redis, the Node app, Caddy, and a small buffer. 128 GB NVMe is enough for a small or medium team's wiki for several years, assuming attachment uploads are screenshots rather than video walkthroughs. Real-time editing for two or three concurrent writers is fine; a dozen people typing on the same page is where you would feel the smaller core count.

Coupons (each pops a different code at build time):

• 36nc17718015544
• 36nc17718015543
• 36nc17718015540

VPS 1000 G12 — recommended for most Docmost deployments

Specs: 4 vCore, 8 GB DDR5 ECC, 256 GB NVMe, traffic included. Around 10 € a month (verify on netcup.com).

This is the tier the article was written around. 8 GB RAM gives Postgres room to cache a real working set, the Node app room to handle concurrent WebSocket sessions for a team of twenty without flinching, and the host enough headroom to run Caddy plus a second self-hosted service (Vaultwarden, Forgejo, a status page) on the same box. 256 GB NVMe holds a wiki's worth of attachments for the better part of a decade. This is the answer for most readers.

Coupons:

• 5799nc17800061381
• 5799nc17774618550
• 5799nc17800061380

VPS 2000 G12 — when the wiki is the company memory

Specs: 8 vCore, 16 GB DDR5 ECC, 512 GB NVMe, traffic included. Around 19 € a month (verify on netcup.com).

For a team of fifty or more, or a Docmost instance that has become the canonical home for engineering docs, RFCs, post-mortems, and onboarding — the kind of wiki that ten people are reading at any given moment and three are editing. 16 GB RAM keeps Postgres' shared buffers warm even with deep history and full-text search. 512 GB NVMe absorbs years of design files, recorded-meeting transcripts, and attachment drift. The eight cores matter for the Postgres workload more than for the Node app.

Coupons:

• 5800nc17718015230
• 5800nc17804382710
• 5800nc17802654090

RS 1000 G12 — when latency matters

Specs: 4 dedicated AMD EPYC 9645 cores, 8 GB DDR5 ECC, 256 GB NVMe. Around 13 € a month (verify on netcup.com).

Same RAM and disk as the VPS 1000 G12, but the cores are dedicated rather than oversubscribed. The practical difference for Docmost: real-time editor responsiveness during sustained concurrent typing stays flat instead of stuttering when a noisy neighbour decides to compile something on the host. For a team that uses the wiki during synchronous meetings — collaborative note-taking on a call, spec-writing in pairs — the dedicated cores remove a class of "why did the cursor jump" support tickets. For a wiki that is mostly read, this is overkill; for a wiki that is mostly written together, it is the cleaner option.

Coupons (Root Server codes give two free months):

• 5159nc17718015443
• 5159nc17718015441
• 5997nc17755880771

Comparison

If you are spinning up Docmost for a small team and want to keep the bill under a beer, take VPS 500 G12. If you are putting it in front of a normal company team and want it to keep up as the page tree grows, take VPS 1000 G12 — the right answer for almost everyone. If the wiki is becoming the institutional memory of a 50-person organisation, jump to VPS 2000 G12 before the database starts swapping. If your team writes documents together in real time as a workflow rather than as an occasional event, RS 1000 G12 removes the noisy-neighbour variance and is worth the small premium over VPS 1000 G12.

Web Hosting is not a fit here — Docmost needs a Node daemon, a Postgres process, and a Redis process. Shared hosting cannot run any of them.

Conclusion

A working Docmost install on a Netcup VPS 1000 G12 lands at roughly 10 € a month after the first free month from 5799nc17804382700, with 8 GB of RAM, 256 GB of NVMe, and the entire stack — wiki, database, real-time collaboration, reverse proxy — running on a single box. That is less than one Confluence seat at standard pricing, with the company knowledge base sitting on hardware in the EU rather than on whichever cloud the vendor happens to prefer this quarter.

If you want a few euros off the first invoice or want to bundle a domain registration on the same order, drop the €5-off-any-order coupon 36nc17718015545 in at checkout — it stacks with the VPS-specific code on a separate order if you bring up a second box later for staging.

Things to keep an eye on once it is running: the Postgres dump's daily file size (a sudden jump usually means someone uploaded a large attachment that landed in the wrong table), free disk on the storage volume (Docmost does not auto-prune old revisions or attachments), and the upstream release notes — the v0.80 line is shipping fast, and the upgrade path is "stop, pull, up" rather than in-place hot reload. Read the release notes before each compose pull and the boring stuff stays boring.

The wiki is yours, the bytes are yours, and the bill is one fixed line item per month. That is the whole point.