Docmost für IT-Dokumentation: Warum ich von BookStack zu Docmost gewechselt bin

IT-Dokumentation ist eines dieser Themen, bei denen fast jeder zustimmt, dass sie wichtig ist, aber nur wenige setzen sie wirklich konsequent um. Ich kenne das aus eigenen Projekten, aus Kundensituationen und auch aus meiner eigenen Infrastruktur. Solange alles läuft, wirkt Dokumentation schnell wie ein zusätzlicher Arbeitsschritt. Sobald aber ein System ausfällt, eine Migration ansteht oder ein Kunde nach einer konkreten Konfiguration fragt, entscheidet gute Dokumentation darüber, ob man souverän arbeiten kann oder hektisch in alten Tickets, Chatverläufen und Shell-Histories sucht. Das gilt für die eigene Infrastruktur genauso wie für Kundenprojekte. Wer nicht dokumentiert, lebt mit einem Risiko.

Ohne Dokumentation und Wissensmanagement über Anhängigkeiten könnt Ihr nicht zuverlässig abschätzen wie der Blast-Radius eines Ausfalls ist, wie lange die Wiederherstellung dauert oder welche Systeme betroffen sein könnten.

Ich nutze Docmost inzwischen produktiv als zentrale Wissensdatenbank für meine IT-Infrastruktur, Kundenumgebungen und Projekte. Vorher war BookStack lange Zeit mein wichtigstes Werkzeug für Dokumentation. BookStack ist aus meiner Sicht weiterhin ein sehr gutes Open-Source-Projekt. Die klare Struktur aus Regalen, Büchern, Kapiteln und Seiten ist leicht verständlich und gerade für viele Teams ein großer Vorteil. Ich möchte BookStack deshalb nicht schlechtreden. Es hat mir über längere Zeit zuverlässig geholfen, Ordnung in technische Informationen zu bringen. Trotzdem bin ich von BookStack zu Docmost gewechselt. Der Grund war nicht ein einzelnes fehlendes Feature, sondern die Summe aus Arbeitsgefühl, Kollaboration, moderner Oberfläche und der Art, wie ich Dokumentation heute nutze. Ich schreibe nicht mehr nur fertige Handbuchseiten weg. Dokumentation ist bei mir stärker Teil des laufenden Betriebs geworden: während einer Migration, beim Aufbau eines Docker-Hosts, beim Planen von Firewall-Regeln, beim Festhalten von Kundeninformationen oder beim Review eines Backup-Konzepts. Dafür passt Docmost besser zu meiner Arbeitsweise. Docmost fühlt sich für mich näher an modernen Wissensplattformen wie Confluence, Notion oder Outline an, bleibt dabei aber self-hosted und Open Source. Genau diese Kombination ist für mich spannend: eine moderne Oberfläche, Echtzeit-Kollaboration, Spaces, Seitenhierarchien, Kommentare, Anhänge, Diagramme und Docker-Betrieb, aber ohne die eigene Dokumentation komplett in eine fremde SaaS-Plattform auszulagern. Dieser Artikel ist deshalb kein neutraler Produktkatalog, sondern ein Praxisbericht mit Anleitung. Ich zeige, warum IT-Dokumentation für mich geschäftskritisch ist, wie ich Docmost strukturiere, wie man Docmost auf einem Netcup VPS mit Docker Compose installiert, worauf man bei Reverse Proxy, Backups und Restore achten sollte und wie ich den Wechsel von BookStack zu Docmost einschätze.

Warum IT-Dokumentation extrem wichtig ist

Gute IT-Dokumentation ist kein Luxus. Sie ist ein Teil der Betriebsstabilität. Das klingt trocken und langweilig, wird aber im Alltag sehr konkret. Wenn ein Server nicht erreichbar ist, ein VPN nicht funktioniert oder eine DNS-Zone falsch gepflegt wurde, zählt jede Minute. Eine aktuelle Dokumentation beantwortet dann Fragen, die man unter Druck nicht erst rekonstruieren möchte: Wo läuft der Dienst? Wer ist verantwortlich? Welche Ports müssen offen sein? Wo liegen Backups? Welche Abhängigkeiten gibt es? Wann wurde die letzte Änderung durchgeführt?

Ausfälle sind der offensichtlichste Fall. Ein System fällt aus, und plötzlich wird sichtbar, ob Wissen sauber abgelegt wurde. Ohne Dokumentation beginnt die Fehlersuche oft bei null. Man verbindet sich auf den Server, schaut in Container, prüft Cronjobs, rekonstruiert Reverse-Proxy-Regeln und sucht Zugangsdaten. Mit Dokumentation beginnt man dagegen mit einem Lagebild. Das spart Zeit, reduziert Fehler und macht Kommunikation mit Kunden oder Kollegen deutlich einfacher.

Personalwechsel sind der zweite große Punkt. In vielen Umgebungen steckt entscheidendes Wissen in den Köpfen einzelner Personen. Das funktioniert so lange, bis diese Person im Urlaub ist, krank wird oder das Unternehmen verlässt. Dann werden Wissensinseln zum Risiko. Eine Self Hosted Knowledge Base wie Docmost hilft dabei, Wissen aus einzelnen Köpfen in eine gemeinsame Struktur zu bringen.

Auch Kundenprojekte profitieren massiv von guter Dokumentation. Gerade bei Infrastruktur-, Netzwerk- oder Automatisierungsprojekten entstehen viele Details, die später wieder relevant werden: Ansprechpartner, Domains, DNS-Einträge, VPN-Zugänge, Wartungsfenster, Besonderheiten einzelner Standorte, eingesetzte Systeme, Abhängigkeiten und vereinbarte Betriebsprozesse. Wenn diese Informationen nur in E-Mails oder Tickets liegen, sind sie zwar irgendwo vorhanden, aber nicht zuverlässig nutzbar.

Bei Sicherheitsvorfällen wird Dokumentation noch wichtiger. Wer im Incident-Fall erst herausfinden muss, welche Systeme zu einem Kunden gehören, welche Firewall-Regeln aktiv sind oder wo Logs liegen, verliert wertvolle Zeit. Eine gute IT-Dokumentation hilft, schneller zu priorisieren, Zuständigkeiten zu klären und Maßnahmen nachvollziehbar zu machen.

Onboarding ist ein weiterer Bereich, der oft unterschätzt wird. Neue Mitarbeiter, externe Dienstleister oder Projektpartner müssen verstehen, wie eine Umgebung aufgebaut ist. Eine saubere Dokumentationssoftware reduziert Rückfragen und verhindert, dass Einführungen jedes Mal mündlich neu stattfinden müssen.

Auch Compliance spielt eine Rolle. Nicht jede kleine Umgebung braucht ein Enterprise-GRC-System. Aber viele Unternehmen müssen nachvollziehen können, wie Backups funktionieren, wer Zugriff hat, welche Systeme personenbezogene Daten verarbeiten und welche Prozesse im Betrieb gelten. Eine strukturierte Wissensdatenbank ist dafür oft der pragmatische erste Schritt.

Schlechte Dokumentation kostet Geld. Sie kostet Zeit bei Störungen, erzeugt doppelte Arbeit, erhöht Projektrisiken und macht Systeme schwerer wartbar. Das Teure ist selten die Wiki-Software selbst. Teuer ist die Stunde, in der niemand weiß, wie ein wichtiges System wiederhergestellt wird.

Was Nutzer häufig über Docmost wissen wollen

Kann Docmost Confluence ersetzen?

Docmost kann Confluence in vielen Szenarien ersetzen, aber nicht in jedem. Wenn ein Team Confluence vor allem als Wiki, Projektwissen, technische Dokumentation oder interne Knowledge Base nutzt, ist Docmost eine sehr ernstzunehmende Confluence Alternative. Der große Unterschied liegt bei Ökosystem, Integrationen, Enterprise-Prozessen und gewachsenen Atlassian-Workflows. Wer stark in Jira, Confluence-Makros, Marketplace-Apps und komplexe Freigabeprozesse investiert hat, sollte vorher genau testen.

Für Teams, die eine moderne Open-Source-Wissensplattform mit Self-Hosting, Docker und Datenhoheit suchen, ist Docmost dagegen sehr attraktiv.

Ist Docmost besser als BookStack?

Nicht pauschal. Docmost ist für meine Anforderungen besser. BookStack ist weiterhin stark, wenn man eine sehr klare, handbuchartige Struktur sucht und mit dem Konzept aus Regalen, Büchern, Kapiteln und Seiten glücklich ist. Docmost passt besser, wenn man stärker in Spaces denkt, gemeinsam in Echtzeit arbeitet, eine modernere Oberfläche bevorzugt und eine Plattform sucht, die sich näher an aktuellen Collaboration-Tools anfühlt.

Für wen ist Docmost nicht geeignet?

Docmost ist nicht ideal für Teams, die eine reine Dateiablage suchen, die komplett ohne Serverbetrieb auskommen wollen oder deren Prozesse vollständig auf spezielle Confluence-Apps angewiesen sind. Auch wer extrem granulare Compliance-Workflows benötigt, sollte genau prüfen, ob die Community- oder Enterprise-Funktionen zum eigenen Bedarf passen.

Features von Docmost im Detail

Spaces

Spaces sind für mich das zentrale Ordnungselement in Docmost. Ich verwende Spaces nicht als dekorative Ordner, sondern als fachliche Grenzen. Ein Space kann zum Beispiel “IT-Infrastruktur”, “Kunden”, “Projekte”, “Betrieb”, “Security” oder “Vorlagen” heißen.

Der Vorteil: Jede größere Wissensdomäne bekommt einen eigenen Kontext. In BookStack musste ich stärker darüber nachdenken, ob etwas ein Buch, ein Kapitel oder eine Seite ist. In Docmost denke ich eher in Arbeitsbereichen. Das fühlt sich natürlicher an, wenn Dokumentation nicht nur als Handbuch, sondern als lebendige Knowledge Base genutzt wird.

Seitenstruktur

Innerhalb eines Spaces lassen sich Seiten verschachteln. Für Server-Dokumentation ist das sehr praktisch. Eine Seite kann den Server beschreiben, darunter liegen Unterseiten für Docker-Container, Backup, Monitoring, Wartung und bekannte Probleme. Bei Kunden kann eine Hauptseite die Übersicht liefern, darunter folgen Domains, DNS, VPN, Systeme und Prozesse.

Eine gute Seitenstruktur verhindert, dass Seiten zu lang werden. Ich versuche, eine Seite jeweils auf ein Thema zu begrenzen. Wenn eine Seite mehrere völlig unterschiedliche Fragen beantworten soll, wird sie später schwer pflegbar.

Echtzeit-Kollaboration

Echtzeit-Kollaboration ist einer der Gründe, warum Docmost für mich moderner wirkt als klassische Wikis. Mehrere Personen können gleichzeitig an einer Seite arbeiten, ohne sich gegenseitig Inhalte zu überschreiben. In der Praxis ist das bei Projektübergaben, Workshops oder Störungen hilfreich.

Wenn während einer Migration mehrere Dinge parallel passieren, kann eine Person technische Schritte dokumentieren, während eine andere offene Punkte ergänzt oder Screenshots einfügt. Dokumentation entsteht dadurch nicht erst nach dem Projekt, sondern während der Arbeit.

Volltextsuche

Eine Wissensdatenbank ist nur so gut wie ihre Auffindbarkeit. Ich nutze die Suche ständig, oft schneller als die Navigation. Wenn ich nach einem Hostnamen, einer IP-Adresse, einem Kundennamen oder einem Dienst suche, muss das Ergebnis zuverlässig auftauchen.

Für produktive Dokumentation ist das entscheidend. Eine schöne Struktur hilft, aber niemand erinnert sich nach Monaten noch exakt, wo eine bestimmte Information liegt. Deshalb sollten Seiten auch Suchbegriffe enthalten, die man im Ernstfall wirklich eingibt: Hostnames, Aliase, Projektnamen, technische Kürzel, Standorte und Kundennamen.

Kommentare

Kommentare sind nützlich, um Rückfragen und Reviews direkt an der Dokumentation zu halten. Statt eine Seite per Chat zu diskutieren, kann man konkrete Stellen kommentieren. Das ist besonders hilfreich, wenn Dokumentation von mehreren Personen gepflegt wird oder wenn Kunden- und Projektinformationen überprüft werden müssen.

Ich nutze Kommentare vor allem für offene Punkte: “Bitte DNS-Zone prüfen”, “Backup-Restore noch testen”, “Screenshot nach Go-live ersetzen”. Solche Hinweise gehören nicht immer dauerhaft in den Seitentext, sollen aber im Arbeitsprozess sichtbar bleiben.

Dateianhänge

Dateianhänge sind bei IT-Dokumentation unvermeidlich. Netzwerkpläne, PDF-Auszüge, Screenshots, Konfigurationsdateien, Exportdateien oder Projektunterlagen müssen an der richtigen Stelle liegen. Wichtig ist dabei Disziplin: Anhänge sollten nicht zur ungeordneten Dateiablage werden.

Meine Regel: Ein Anhang braucht Kontext. Wenn ich eine Datei hochlade, beschreibe ich auf der Seite kurz, was sie enthält, wann sie erstellt wurde und wofür sie gedacht ist. Sonst ist der Anhang später nur eine weitere Datei mit unklarem Nutzen.

Rollen und Berechtigungen

Berechtigungen sind ein zentraler Punkt, besonders bei Kundendokumentation. Nicht jede Person muss alles sehen. In Docmost lassen sich Zugriffe über Benutzer, Gruppen und Space-Berechtigungen organisieren. Für kleinere Setups reicht oft eine einfache Trennung: Administratoren, interne Bearbeiter, Leser und gegebenenfalls externe Benutzer.

Bei sensiblen Daten sollte man konservativ vorgehen. Infrastruktur- und Sicherheitsdokumentation enthält Informationen, die nicht breit verteilt werden sollten. Eine gute Struktur hilft auch hier: Wenn sensible Inhalte in separaten Spaces liegen, lassen sie sich leichter absichern.

Diagramme mit Mermaid, Draw.io und Excalidraw

Diagramme sind für technische Dokumentation Gold wert. Text beschreibt Abläufe, aber Diagramme machen Zusammenhänge sichtbar. Mermaid eignet sich gut für einfache Ablaufdiagramme, Sequenzen oder Infrastruktur-Skizzen direkt im Text. Draw.io ist stark für klassische Netzwerk- und Architekturdiagramme. Excalidraw wirkt freier und eignet sich gut für Skizzen, Konzepte und Workshop-Notizen.

Ich würde Diagramme nicht als Dekoration verwenden. Ein gutes Diagramm beantwortet eine konkrete Frage: Wie fließt der Traffic? Welche Systeme hängen voneinander ab? Wo endet die Verantwortung eines Dienstleisters? Welche Backup-Kette gibt es?

Moderne Benutzeroberfläche

Die Oberfläche war für mich ein wichtiger Wechselgrund. Docmost wirkt aufgeräumt, schnell und näher an dem, was viele Nutzer von modernen Tools erwarten. Das reduziert Reibung. Wenn ein Wiki altbacken wirkt oder sich mühsam bedienen lässt, wird es weniger genutzt. Dokumentation lebt aber davon, dass Menschen sie ohne Widerstand aktualisieren.

Docker-Betrieb und Self-Hosting

Docmost lässt sich sehr gut mit Docker betreiben. Für mich ist das wichtig, weil ich viele Dienste standardisiert deploye: eigener Ordner unter /opt, .env, docker-compose.yml, Reverse Proxy, Backup-Skript, Monitoring. Dadurch passt Docmost sauber in bestehende Self-Hosting- und Homelab-Umgebungen.

Team-Wissensdatenbank

Docmost ist mehr als ein Ablageort für fertige Seiten. Richtig genutzt wird es zur Team-Wissensdatenbank. Dazu gehören Vorlagen, Reviews, Verantwortlichkeiten, Projektseiten, Betriebsnotizen, Entscheidungsdokumente und wiederkehrende Checklisten. Je konsequenter man diese Arbeitsweise etabliert, desto wertvoller wird das System.

Meine Docmost-Struktur im Detail

Meine eigene Struktur ist bewusst praxisnah aufgebaut. Ich orientiere mich nicht an einer theoretischen Taxonomie, sondern daran, wie ich im Alltag Informationen suche.

IT-Infrastruktur

Der Space “IT-Infrastruktur” ist meine technische Hauptzentrale. Dort dokumentiere ich übergreifende Systeme, Netzwerke, Server, Dienste, Backups, Monitoring und Security-Themen. Die erste Ebene enthält Übersichtsseiten, damit ich schnell sehen kann, welche Systeme existieren und wie sie zusammenhängen.

Cloud Infrastruktur

In der Cloud-Infrastruktur trenne ich nach Providern:

• Netcup VPS
• Hetzner Cloud
• IONOS Cloud

Für jeden Provider gibt es eine Übersicht mit Accounts, Projekten, Netzwerken, Servern, DNS-Bezug, Backup-Konzept und Besonderheiten. Bei Netcup dokumentiere ich zum Beispiel, welche VPS für produktive Dienste genutzt werden, welche Reverse Proxies aktiv sind und welche Domains auf welche Systeme zeigen.

On-Premise Infrastruktur

On-Premise dokumentiere ich getrennt von Cloud-Systemen. Dazu gehören:

• OPNsense
• Identity Management
• Backup
• Storage
• interne DNS- und DHCP-Strukturen
• VPN-Zugänge
• Monitoring

Bei OPNsense sind Firewall-Regeln, NAT, VPN, Zertifikate und wichtige Aliase dokumentiert. Beim Identity Management halte ich fest, welche Benutzerquellen genutzt werden, welche Gruppen relevant sind und welche Dienste angebunden sind. Beim Backup geht es nicht nur darum, welches Tool läuft, sondern auch darum, was gesichert wird, wie oft, wohin und wie ein Restore funktioniert.

Kundendokumentation

Kundendokumentation ist ein eigener Bereich, weil sie anders gepflegt wird als interne Infrastruktur. Pro Kunde gibt es eine Übersichtsseite mit den wichtigsten Eckdaten und darunter Unterseiten für:

• Ansprechpartner
• Domains
• DNS
• VPN
• Zugangsdaten beziehungsweise Verweise auf den Passwortmanager
• Systeme
• Wartungsprozesse
• Abhängigkeiten
• Besonderheiten im Betrieb

Zugangsdaten dokumentiere ich nicht einfach im Wiki. Wenn Passwörter notwendig sind, verweise ich auf den passenden Eintrag im Passwortmanager oder beschreibe den Zugriffspfad. Ein Wiki ohne klares Sicherheitskonzept ist kein geeigneter Passwortsafe.

Projekte

Im Projekt-Space dokumentiere ich laufende und abgeschlossene Arbeiten:

• Migrationen
• Netzwerkprojekte
• Automatisierungen
• Systemeinführungen
• Troubleshooting-Fälle
• technische Entscheidungen

Bei Migrationen dokumentiere ich Ausgangslage, Zielbild, Risiken, Rollback-Plan, Schritte, Tests und offene Punkte. Bei Automatisierungen halte ich fest, welches Problem gelöst wird, wo der Code liegt, welche Zugangsdaten benötigt werden, wie Logs geprüft werden und wer verantwortlich ist.

Server-Dokumentation

Jeder wichtige Server bekommt eine eigene Seite. Meine Standardfelder sind:

• Hostname
• IP-Adresse
• Betriebssystem
• Provider oder Standort
• Zweck des Systems
• installierte Dienste
• Docker Container
• offene Ports
• Reverse-Proxy-Zuordnung
• Monitoring
• Backup-Konzept
• Restore-Hinweise
• Verantwortlichkeiten
• letzte Prüfung

Diese Struktur spart im Alltag enorm viel Zeit. Wenn ein Dienst auffällig ist, suche ich nach dem Hostnamen und sehe sofort, welche Container laufen, wo Logs liegen und welches Backup-Konzept gilt.

Docmost auf einem VPS mit Docker Compose installieren

Für ein produktionsnahes Setup nutze ich einen eigenen VPS, Ubuntu 24.04, Docker Compose, PostgreSQL, Redis und einen Reverse Proxy mit HTTPS. Die folgenden Schritte sind bewusst ausführlich gehalten, damit sie als solide Grundlage dienen. Passwörter, Domains und Pfade müssen natürlich angepasst werden.

VPS bei Netcup vorbereiten

Ein kleiner Netcup VPS oder bei Hetzner reicht für den Start aus. Für eine einzelne Docmost-Instanz mit wenigen Benutzern würde ich mindestens 2 vCPU, 4 GB RAM und ausreichend SSD-Speicher einplanen. Wer viele Anhänge, Screenshots oder Importdateien nutzt, sollte Speicher großzügiger kalkulieren.

Neukunden bei Netcup können meinen 5 € Gutscheincode verwenden: 36nc174291601049

Nach der Bereitstellung installiere ich Ubuntu 24.04 LTS, setze einen SSH-Key, deaktiviere Passwort-Login für SSH und lege bei Bedarf einen administrativen Benutzer an. Root-Login per Passwort sollte auf produktiven Systemen nicht offen bleiben.

Ubuntu 24.04 aktualisieren

sudo apt update
sudo apt upgrade -y
sudo reboot

Nach dem Neustart prüfe ich, ob das System sauber erreichbar ist:

ssh admin@SERVER-IP
lsb_release -a

Firewall-Grundkonfiguration

Für ein einfaches Setup mit UFW:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Port 3000 muss nicht öffentlich erreichbar sein, wenn Docmost hinter einem Reverse Proxy läuft. Ich binde ihn in der Compose-Datei deshalb nur an 127.0.0.1.

Docker und Docker Compose Plugin installieren

sudo apt install docker.io docker-compose-v2 -y

.env Datei erstellen

Die .env trennt sensible Werte von der Compose-Datei. Die Werte unten sind Beispiele und müssen ersetzt werden.

nano .env

APP_URL=https://wiki.example.de
APP_SECRET=REPLACE_WITH_OPENSSL_RAND_HEX_32_OR_LONGER

POSTGRES_DB=docmost
POSTGRES_USER=docmost
POSTGRES_PASSWORD=REPLACE_WITH_STRONG_DATABASE_PASSWORD

DATABASE_URL=postgresql://docmost:REPLACE_WITH_STRONG_DATABASE_PASSWORD@db:5432/docmost
REDIS_URL=redis://redis:6379

TZ=Europe/Berlin

APP_SECRET kann man zum Beispiel so erzeugen:

openssl rand -hex 32

Wichtig: Das Passwort in POSTGRES_PASSWORD und in DATABASE_URL muss identisch sein. APP_URL muss später exakt zur extern erreichbaren URL passen, also inklusive https://.

Produktionsnahe docker-compose.yml

nano docker-compose.yml

services:
  docmost:
    image: docmost/docmost:latest
    container_name: docmost
    depends_on:
      - db
      - redis
    environment:
      APP_URL: ${APP_URL}
      APP_SECRET: ${APP_SECRET}
      DATABASE_URL: ${DATABASE_URL}
      REDIS_URL: ${REDIS_URL}
      PORT: 3000
      TZ: ${TZ}
    ports:
      - "127.0.0.1:3000:3000"
    restart: unless-stopped
    volumes:
      - docmost_storage:/app/data/storage
    networks:
      - docmost_internal

  db:
    image: postgres:18
    container_name: docmost-db
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      TZ: ${TZ}
    restart: unless-stopped
    volumes:
      - postgres_data:/var/lib/postgresql
    networks:
      - docmost_internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 30s
      timeout: 10s
      retries: 5

  redis:
    image: redis:8
    container_name: docmost-redis
    command: ["redis-server", "--appendonly", "yes", "--maxmemory-policy", "noeviction"]
    restart: unless-stopped
    volumes:
      - redis_data:/data
    networks:
      - docmost_internal
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 30s
      timeout: 10s
      retries: 5

networks:
  docmost_internal:
    name: docmost_internal

volumes:
  docmost_storage:
  postgres_data:
  redis_data:

Dieses Setup nutzt PostgreSQL für die Datenbank, Redis für interne Dienste und ein Docker-Volume für lokale Uploads und Anhänge. Der Docmost-Port ist nur lokal auf dem Server erreichbar. Der öffentliche Zugriff läuft später über den Reverse Proxy.

Container starten und Logs prüfen

cd /opt/docmost
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f docmost

Wenn Docmost sauber startet, sollte der Dienst lokal auf http://127.0.0.1:3000 erreichbar sein. Von außen erfolgt der Zugriff nach der Reverse-Proxy-Konfiguration über https://wiki.example.de.

Erste Einrichtung im Browser

Beim ersten Aufruf erstellt man den Workspace und den ersten Benutzer. Dieser Benutzer wird der Workspace Owner. Danach sollten direkt die grundlegenden Einstellungen geprüft werden:

• stimmt die externe URL?
• funktioniert HTTPS?
• lassen sich Seiten erstellen?
• funktionieren Uploads?
• greifen Kommentare und Suche?
• ist die Instanz nur über die gewünschte Domain erreichbar?

Reverse Proxy: Nginx Proxy Manager

Ein Reverse Proxy ist für ein produktives Docmost-Setup aus mehreren Gründen sinnvoll. Er terminiert HTTPS, kümmert sich um Zertifikate, leitet Anfragen an den internen Container weiter und macht es möglich, mehrere Dienste auf einem Server sauber über Subdomains zu betreiben.

Typisches Beispiel:

https://wiki.example.de -> Reverse Proxy -> http://127.0.0.1:3000

Nginx Proxy Manager

Nginx Proxy Manager ist im Homelab und bei kleinen Setups beliebt, weil die Konfiguration über eine Weboberfläche erfolgt. Für Docmost legt man einen Proxy Host an:

• Domain: wiki.example.de
• Scheme: http
• Forward Hostname/IP: 127.0.0.1 oder die Docker-Netzwerkadresse
• Forward Port: 3000
• WebSockets aktivieren
• Let’s Encrypt Zertifikat anfordern
• Force SSL aktivieren

WebSockets sind wichtig, weil Echtzeit-Kollaboration darauf angewiesen ist. Wenn die Oberfläche lädt, aber gemeinsame Bearbeitung oder Live-Funktionen merkwürdig reagieren, ist der Reverse Proxy einer der ersten Prüfbereiche.

Typische Fehler bei APP_URL und HTTPS

Der häufigste Fehler ist eine falsche APP_URL. Wenn Docmost extern über https://wiki.example.de erreichbar ist, sollte APP_URL nicht auf http://localhost:3000, eine IP-Adresse oder eine URL mit falschem Port zeigen. Das kann Links, Einladungen, Weiterleitungen und Browser-Verhalten stören.

Weitere typische Fehler:

• WebSockets im Proxy nicht aktiviert
• Port 3000 öffentlich freigegeben, obwohl der Reverse Proxy genutzt wird
• DNS zeigt noch auf die falsche IP
• Let’s Encrypt kann Port 80 nicht erreichen
• gemischte HTTP/HTTPS-Konfiguration
• alte Browser-Caches nach URL-Änderungen

Backup und Restore für Docmost

Backups sind bei Docmost kritisch, weil die Plattform schnell zur zentralen Wissensquelle wird. Wenn die Dokumentation ausfällt oder verloren geht, fehlt im Ernstfall genau das Wissen, mit dem man andere Systeme wiederherstellt. Deshalb gehört ein Backup-Konzept direkt zur Installation, nicht erst irgendwann später.

Was muss gesichert werden?

Mindestens relevant sind:

• PostgreSQL-Datenbank
• Docmost-Storage für Uploads und Anhänge
• docker-compose.yml
• .env Datei
• Reverse-Proxy-Konfiguration
• optional externe Storage-Konfigurationen

PostgreSQL enthält die strukturierten Daten. Uploads und Anhänge liegen im Storage-Volume. Beides muss zusammenpassen. Ein Datenbank-Backup ohne Anhänge ist unvollständig. Anhänge ohne Datenbank sind kaum sinnvoll nutzbar.

PostgreSQL Backup

Ein einfaches manuelles Backup:

cd /opt/docmost
docker compose exec -T db pg_dump -U docmost -d docmost > backups/docmost-postgres-$(date +%F-%H%M%S).sql

Komprimiert:

cd /opt/docmost
docker compose exec -T db pg_dump -U docmost -d docmost | gzip > backups/docmost-postgres-$(date +%F-%H%M%S).sql.gz

Volumes und Uploads sichern

Docker-Volumes kann man auf unterschiedliche Weise sichern. Eine pragmatische Variante ist ein temporärer Container:

docker run --rm \
  -v docmost_storage:/source:ro \
  -v /opt/docmost/backups:/backup \
  alpine tar -czf /backup/docmost-storage-$(date +%F-%H%M%S).tar.gz -C /source .

Für PostgreSQL sollte man nicht einfach nur das Volume kopieren, während die Datenbank läuft. Ein sauberer pg_dump ist für logische Backups die bessere Grundlage.

Beispiel-Skript für Backups

sudo nano /opt/docmost/backup-docmost.sh

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR="/opt/docmost/backups"
TIMESTAMP="$(date +%F-%H%M%S)"

mkdir -p "$BACKUP_DIR"
cd /opt/docmost

docker compose exec -T db pg_dump -U docmost -d docmost | gzip > "$BACKUP_DIR/docmost-postgres-$TIMESTAMP.sql.gz"

docker run --rm \
  -v docmost_storage:/source:ro \
  -v "$BACKUP_DIR:/backup" \
  alpine tar -czf "/backup/docmost-storage-$TIMESTAMP.tar.gz" -C /source .

cp /opt/docmost/docker-compose.yml "$BACKUP_DIR/docker-compose-$TIMESTAMP.yml"
cp /opt/docmost/.env "$BACKUP_DIR/env-$TIMESTAMP.txt"

find "$BACKUP_DIR" -type f -mtime +30 -delete

chmod +x /opt/docmost/backup-docmost.sh
/opt/docmost/backup-docmost.sh

Danach kann das Skript per Cron oder systemd timer ausgeführt werden. Wichtig: Die .env enthält Geheimnisse. Wer sie sichert, muss das Backup-Ziel entsprechend schützen.

Restore testen

Ein Backup ist erst dann vertrauenswürdig, wenn ein Restore getestet wurde. Ich empfehle, regelmäßig eine Testinstanz aufzusetzen und dort Datenbank sowie Storage wiederherzustellen. Dabei prüft man:

• startet Docmost?
• sind Spaces und Seiten vorhanden?
• funktionieren Anhänge?
• stimmen Benutzer und Berechtigungen?
• ist die Suche nutzbar?

3-2-1-Regel und Offsite-Backups

Für wichtige Dokumentation gilt die 3-2-1-Regel: drei Kopien, zwei unterschiedliche Medien oder Systeme, eine Kopie extern. Bei einem VPS bedeutet das zum Beispiel: lokale Backups auf dem Server, zusätzliche Backups auf einem separaten Storage und eine verschlüsselte Offsite-Kopie. Offsite kann ein anderer Server, S3-kompatibler Speicher oder ein Backup-Dienst sein.

Migration von BookStack zu Docmost

Mein Wechsel von BookStack zu Docmost war eine reine Copy-Paste-Aktion. Eine Migration auch ist die beste Gelegenheit, Dokumentation aufzuräumen. BookStack arbeitet stark mit Regalen, Büchern, Kapiteln und Seiten. Diese Struktur ist klar und hat Vorteile. Docmost arbeitet stärker mit Spaces und flexiblen Seitenbäumen. Wenn man die alte Struktur blind übernimmt, nimmt man möglicherweise alte Unordnung mit und nutzt die Stärken von Docmost nicht aus.

Warum ich gewechselt bin

Ich wollte eine modernere Oberfläche, bessere Zusammenarbeit, Echtzeitbearbeitung und eine Struktur, die mehr nach Arbeitsbereichen als nach Handbüchern funktioniert. Außerdem finde ich die Entwicklung rund um KI, API, Enterprise-Funktionen und MCP spannend, ohne mich heute schon von diesen Funktionen abhängig zu machen.

Inhalte exportieren und neu denken

Bei der Migration sollte man zuerst priorisieren:

• Welche Seiten sind aktuell und wichtig?
• Welche Seiten sind veraltet?
• Welche Inhalte werden häufig gesucht?
• Welche Screenshots müssen erneuert werden?
• Welche Anhänge sind noch relevant?
• Welche Struktur passt künftig besser?

Ich würde nicht mit “alles exportieren, alles importieren” beginnen. Besser ist ein strukturierter Umzug: zentrale Betriebsdokumentation zuerst, dann Kunden, dann Projekte, dann Archiv.

Großer Vergleich: Docmost vs BookStack

Wann BookStack besser passt

BookStack passt sehr gut, wenn man eine feste Handbuchstruktur möchte. Für Teams, die gerne in Büchern und Kapiteln denken, ist BookStack hervorragend. Auch für Dokumentation, die eher gelesen als gemeinsam live bearbeitet wird, bleibt BookStack eine solide Wahl.

Wann Docmost besser passt

Docmost passt besser, wenn Zusammenarbeit, moderne Bedienung, flexible Spaces, Echtzeitbearbeitung und eine zukunftsfähige Knowledge-Base-Plattform wichtiger sind. Für meine Arbeitsweise ist Docmost deshalb inzwischen die bessere BookStack Alternative.

Docmost vs Confluence

Confluence ist in vielen Unternehmen der Standard für Wissensmanagement. Es ist mächtig, integriert sich stark in das Atlassian-Ökosystem und bietet viele Enterprise-Funktionen. Gleichzeitig bringt Confluence Kosten, Abhängigkeiten und je nach Betriebsmodell weniger Kontrolle über die eigene Datenhaltung mit.

Docmost positioniert sich anders. Es ist Open Source, self-hosted betreibbar und deutlich schlanker. Wer vor allem eine interne Wissensdatenbank, IT-Dokumentation oder Projektdokumentation braucht, sollte Docmost ernsthaft prüfen.

Für große Unternehmen mit tiefem Atlassian-Stack kann Confluence weiterhin sinnvoll sein. Für Teams, die bewusst Open Source, Self-Hosting und Kontrolle suchen, ist Docmost eine überzeugende Confluence Alternative.

Docmost vs Wiki.js, Outline und Notion

Wiki.js ist interessant, wenn man ein flexibles Wiki mit vielen technischen Optionen sucht. Es wirkt stärker wie ein klassisches Wiki-System mit modernem Anspruch. Für technisch affine Teams kann das gut passen.

Outline ist eine sehr schöne Knowledge-Base-Lösung mit moderner Oberfläche. Es eignet sich gut für Teams, die eine schlanke, schnelle Dokumentationsplattform suchen. Je nach Hosting- und Authentifizierungsbedarf muss man prüfen, ob es zum eigenen Betriebsmodell passt.

Notion ist für viele Teams ein hervorragendes Produktivitätstool. Als SaaS ist es bequem, flexibel und vielseitig. Für sensible IT-Dokumentation sehe ich aber oft den Nachteil, dass Datenhoheit und Self-Hosting fehlen. Wer interne Infrastrukturdetails, Sicherheitsprozesse oder Kundendokumentation ablegt, sollte diese Frage bewusst entscheiden.

Docmost sitzt für mich genau zwischen diesen Welten: moderner als viele klassische Wikis, self-hosted wie ein Open-Source-Projekt und stärker auf strukturierte Team-Dokumentation ausgelegt als ein reines Notiztool.

Open Source vs Enterprise bei Docmost

Die Open-Source-Version bietet bereits viel von dem, was kleine Teams, Homelabs, Selbstständige und viele interne IT-Abteilungen brauchen: Spaces, Seiten, Zusammenarbeit, Suche, Anhänge, Kommentare, Diagramme und Docker-Betrieb.

Für viele Setups reicht das völlig aus. Wenn ein kleines Team eine zentrale IT-Dokumentation Open Source betreiben möchte, muss nicht sofort Enterprise gekauft werden. Entscheidend ist eher, dass Betrieb, Backup, Berechtigungen und Struktur sauber umgesetzt sind.

Enterprise-Funktionen werden dann interessant, wenn größere Organisationen zusätzliche Anforderungen haben. Dazu können je nach Angebot und Edition gehören:

• LDAP
• SAML
• OpenID Connect
• Multi-Faktor-Authentifizierung
• Audit Logs
• erweiterte Berechtigungen
• Vorlagen und Freigabeprozesse
• bessere Importfunktionen
• API-Zugriff
• Support
• KI-Funktionen
• MCP Server

Gerade SSO ist in Unternehmen wichtig. Benutzer manuell in einer Wissensdatenbank zu verwalten, skaliert nur begrenzt. LDAP, SAML oder OpenID Connect sorgen dafür, dass Benutzerverwaltung, Gruppen und Offboarding sauberer an bestehende Identity-Systeme angebunden werden können.

Audit Logs und erweiterte Berechtigungen sind vor allem dann relevant, wenn Dokumentation Compliance-Anforderungen erfüllen muss. Wer nachvollziehen muss, wer welche Inhalte gesehen oder geändert hat, sollte die Enterprise-Funktionen genau prüfen.

Wichtig ist: Ich würde Enterprise nicht nur wegen eines Schlagworts bewerten. Entscheidend ist der konkrete Bedarf. Für ein Homelab ist Enterprise meist nicht nötig. Für ein Unternehmen mit zentralem Identity Provider, Compliance-Vorgaben und Support-Anforderungen kann es dagegen sehr sinnvoll sein.

MCP Server und Model Context Protocol verständlich erklärt

MCP steht für Model Context Protocol. Vereinfacht gesagt geht es darum, KI-Assistenten kontrolliert Zugriff auf Werkzeuge und Datenquellen zu geben. Statt dass ein KI-System nur allgemeines Wissen aus seinem Modell nutzt, kann es über MCP in definierte Systeme schauen und dort relevante Informationen abrufen oder Aktionen vorbereiten.

Für Dokumentation ist das extrem spannend. Eine Wissensdatenbank enthält Kontext, den ein allgemeines KI-Modell nicht kennen kann: interne Servernamen, Backup-Konzepte, Kundenstrukturen, Firewall-Regeln, Betriebsprozesse, Projektentscheidungen und Verantwortlichkeiten. Wenn ein KI-Assistent diesen Kontext sicher und nachvollziehbar nutzen kann, wird Dokumentation noch wertvoller.

Beispiele aus der Praxis:

• “Wie lautet die Backup-Strategie für Server X?”
• “Welche Firewall-Regeln gelten für Standort Y?”
• “Welche Systeme gehören zu Kunde Z?”
• “Welche Docker Container laufen auf dem Netcup VPS?”
• “Welche Schritte sind beim Restore von Dienst A dokumentiert?”
• “Welche offenen Punkte gibt es in der Migration B?”

Ein KI-Assistent könnte solche Fragen nicht sinnvoll beantworten, wenn die Informationen nur in Köpfen, Chats oder verstreuten Dateien liegen. Liegen sie aber strukturiert in Docmost, entsteht eine Grundlage für bessere Assistenz.

Ich formuliere hier bewusst vorsichtig: Die konkrete Implementierung, Berechtigungslogik und der Funktionsumfang eines MCP Servers hängen vom jeweiligen Docmost-Angebot und der Version ab. Relevant ist der Gedanke dahinter: Dokumentation wird nicht nur für Menschen lesbar, sondern kann künftig auch als kontrollierte Wissensquelle für KI-Werkzeuge dienen.

Das erhöht den Wert guter Dokumentation. Schlechte, veraltete oder unstrukturierte Seiten führen auch bei KI zu schlechten Antworten. Gute Dokumentation dagegen wird zu einem operativen Wissenssystem.

Best Practices für IT-Dokumentation

Sofort dokumentieren

Die beste Dokumentation entsteht nah an der Arbeit. Wenn ich nach einem Projekt zwei Wochen warte, fehlen Details. Deshalb dokumentiere ich wichtige Schritte sofort oder zumindest am selben Tag.

Templates nutzen

Templates sparen Zeit und sorgen für Vergleichbarkeit. Für Server, Kunden, Projekte, Anwendungen und Backup-Konzepte sollte es Vorlagen geben. Ein Server-Template verhindert, dass wichtige Felder wie Monitoring oder Restore-Hinweise vergessen werden.

Screenshots einbauen

Screenshots sind hilfreich, wenn sie aktuell sind und Kontext haben. Ich nutze sie für Oberflächen, komplexe Einstellungen und visuelle Prüfungen. Jeder Screenshot sollte eine kurze Bildunterschrift oder Erklärung bekommen.

Diagramme verwenden

Diagramme helfen bei Netzwerken, Datenflüssen, Abhängigkeiten und Migrationsplänen. Sie sollten nicht perfekt sein müssen. Ein einfaches Mermaid-Diagramm ist oft besser als gar keine Visualisierung.

Verantwortlichkeiten festlegen

Jede wichtige Seite sollte eine verantwortliche Person oder Rolle haben. Sonst fühlt sich niemand zuständig und die Dokumentation altert.

Regelmäßige Reviews

Ich empfehle Review-Daten. Eine Seite kann ein Feld “Letzte Prüfung” enthalten. Kritische Dokumentation wie Backup, Restore, Firewall und Kundenzugänge sollte regelmäßig überprüft werden.

Namenskonventionen

Klare Namen helfen der Suche. Server sollten mit Hostname und Zweck benannt werden. Kundenbereiche sollten einheitlich aufgebaut sein. Projektnamen sollten nicht nur interne Spitznamen enthalten, sondern auch verständliche Begriffe.

Keine Passwortablage ohne Sicherheitskonzept

Passwörter gehören nicht einfach in ein Wiki. Wenn Zugangsdaten dokumentiert werden müssen, sollte man einen Passwortmanager nutzen und in Docmost nur referenzieren, wo der Eintrag liegt. Falls Secrets in der Dokumentation landen, braucht es klare Verschlüsselungs-, Berechtigungs- und Audit-Regeln.

Dokumentation als Teil jedes Projekts

Ein Projekt ist für mich erst fertig, wenn die Dokumentation aktualisiert ist. Das gilt für Migrationen, neue Server, geänderte Firewall-Regeln, Automatisierungen und Backup-Anpassungen. Sonst entsteht technische Schuld in der Dokumentation.

Häufige Fehler bei IT-Dokumentation

Der häufigste Fehler ist die große Sammelseite. Alles landet auf einer Seite: Server, IPs, Passwörter, Historie, Screenshots, offene Punkte. Das wirkt am Anfang bequem, wird aber schnell unwartbar.

Der zweite Fehler ist fehlende Aktualisierung. Eine veraltete Dokumentation ist gefährlich, weil sie Vertrauen erzeugt, das nicht mehr gerechtfertigt ist. Deshalb sind Review-Daten und Verantwortlichkeiten wichtig.

Unklare Zielgruppen sind ebenfalls problematisch. Eine Seite für Entwickler darf technischer sein als eine Betriebsübersicht für einen Kunden. Wenn Sprache und Detailtiefe nicht zur Zielgruppe passen, wird die Dokumentation nicht genutzt.

Weitere typische Fehler:

• keine Screenshots bei komplexen Oberflächen
• keine Backup-Dokumentation
• keine Restore-Tests
• keine Suchbegriffe oder Tags
• keine klare Struktur
• fehlende Angaben zu Verantwortlichkeiten
• alte Anhänge ohne Kontext
• Dokumentation nur nach Projektende

SEO-FAQ zu Docmost, Docker, Self-Hosting und IT-Dokumentation

Was ist Docmost?

Docmost ist eine Open-Source-Plattform für Dokumentation, Wissensmanagement und Team-Wikis. Sie eignet sich als Self Hosted Knowledge Base und moderne Dokumentationssoftware.

Ist Docmost kostenlos?

Docmost kann in der Community-Version selbst gehostet werden. Zusätzlich gibt es je nach Angebot kostenpflichtige Enterprise-Funktionen.

Ist Docmost Open Source?

Ja, Docmost ist ein Open-Source-Projekt. Für bestimmte Enterprise-Funktionen kann eine separate Lizenz erforderlich sein.

Kann ich Docmost mit Docker installieren?

Ja. Docker ist aktuell der empfohlene Installationsweg. Ein typisches Setup besteht aus Docmost, PostgreSQL und Redis.

Welche Datenbank nutzt Docmost?

Docmost nutzt PostgreSQL als Datenbank.

Braucht Docmost Redis?

Ja, Redis gehört zum empfohlenen Setup und wird in der offiziellen Docker-Compose-Struktur verwendet.

Ist Docmost eine Confluence Alternative?

Ja, Docmost ist für viele Teams eine gute Confluence Alternative, besonders wenn Open Source, Self-Hosting und Datenhoheit wichtig sind.

Ist Docmost eine BookStack Alternative?

Ja. Docmost ist eine moderne BookStack Alternative, wenn man Spaces, Echtzeit-Kollaboration und eine zeitgemäße Oberfläche bevorzugt.

Kann ich von BookStack zu Docmost migrieren?

Ja, aber man sollte die Migration nutzen, um die Struktur zu überarbeiten. Alte BookStack-Strukturen sollten nicht blind kopiert werden.

Für wen eignet sich Docmost?

Docmost eignet sich für Homelabs, Selbstständige, MSPs, Entwicklerteams, interne IT-Abteilungen und Unternehmen, die eine moderne Wissensdatenbank suchen.

Ist Docmost für Homelabs geeignet?

Ja. Docmost läuft gut auf kleinen Servern oder VPS-Systemen und passt sehr gut in Docker-basierte Homelab-Umgebungen.

Ist Docmost für Unternehmen geeignet?

Ja, abhängig von den Anforderungen. Unternehmen sollten besonders SSO, Berechtigungen, Audit Logs, Backup, Support und Compliance prüfen.

Gibt es LDAP oder SSO?

LDAP, SAML und OpenID Connect sind im Enterprise-Kontext relevant. Welche Funktionen im konkreten Angebot verfügbar sind, sollte vor Einführung geprüft werden.

Was ist der MCP Server in Docmost Enterprise?

Ein MCP Server kann KI-Werkzeugen kontrollierten Zugriff auf Inhalte der Wissensdatenbank ermöglichen. Damit wird Dokumentation als Kontextquelle für KI-Assistenten nutzbar.

Wie sichere ich Docmost?

Wichtig sind HTTPS, starke Passwörter, sichere APP_SECRET-Werte, restriktive Berechtigungen, regelmäßige Updates, Backups, Restore-Tests und ein sauber konfigurierter Reverse Proxy.

Kann ich Docmost auf einem Netcup VPS betreiben?

Ja. Ein Netcup VPS mit Ubuntu 24.04, Docker Compose, PostgreSQL, Redis und Reverse Proxy ist eine praxistaugliche Grundlage.

Welche Alternativen gibt es zu Docmost?

Wichtige Alternativen sind BookStack, Confluence, Wiki.js, Outline und Notion. Welche Lösung passt, hängt von Self-Hosting, Kosten, Struktur, Zusammenarbeit und Enterprise-Anforderungen ab.

Sollte ich Passwörter in Docmost speichern?

Nur mit einem klaren Sicherheitskonzept. In der Regel ist ein Passwortmanager besser geeignet. Docmost kann auf den passenden Passwortmanager-Eintrag verweisen.

Wie wichtig sind Backups für Docmost?

Sehr wichtig. Docmost kann zur zentralen Betriebsdokumentation werden. Datenbank, Uploads, Konfiguration und Restore-Prozess müssen regelmäßig gesichert und getestet werden.

Docmost ist für mich aktuell die passendste Lösung für IT-Dokumentation, Open-Source-Wissensmanagement und eine moderne Self Hosted Knowledge Base. Der Wechsel von BookStack war keine Abwertung von BookStack. BookStack bleibt ein starkes Open-Source-Wiki und ist für viele Teams weiterhin richtig. Für meine heutige Arbeitsweise ist Docmost aber näher an dem, was ich brauche: Spaces, moderne Oberfläche, Echtzeit-Kollaboration, gute Struktur für Kunden und Infrastruktur sowie eine spannende Perspektive rund um Enterprise-Funktionen, KI und MCP.

Wichtig ist, Docmost nicht nur als Tool zu betrachten. Der Erfolg hängt weniger vom Logo der Software ab als von der eigenen Dokumentationsdisziplin. Wer sofort dokumentiert, Templates nutzt, Backups testet, Verantwortlichkeiten festlegt und Dokumentation als Teil des Betriebs versteht, bekommt mit Docmost eine sehr starke Plattform.

Für Homelabs, MSPs, Selbstständige und Unternehmen, die eine Open Source Wiki Lösung oder Confluence Alternative suchen, ist Docmost definitiv einen Test wert. Besonders in Kombination mit Docker Compose auf einem Netcup VPS entsteht ein Setup, das überschaubar, kontrollierbar und produktiv nutzbar ist.