Docmost selbst hosten: Eine sichere Alternative zu Confluence und Notion

Docmost bietet eine quelloffene, kollaborative Wiki-Lösung.

Docmost selbst hosten: Eine sichere Alternative zu Confluence und Notion

Ein kollaboratives Wiki oder eine Dokumentationsplattform ist für viele Teams unerlässlich. Lösungen wie Confluence oder Notion sind populär, bringen aber oft Abhängigkeiten von Cloud-Anbietern oder proprietäre Lizenzen mit sich. Für technisch versierte Anwender, die Wert auf Datenhoheit, Anpassbarkeit und die Kontrolle über ihre Infrastruktur legen, bietet die Selbsthosting-Option eine attraktive Alternative. Docmost, eine quelloffene, kollaborative Wiki- und Dokumentationssoftware, ermöglicht genau dies und lässt sich mittels Docker Compose effizient und sicher auf dem eigenen Server betreiben.

Was ist Docmost und warum selbst hosten?

Docmost stellt sich als eine quelloffene Alternative zu bekannten Dokumentations- und Wissensmanagement-Tools wie Confluence oder Notion vor. Es ermöglicht Teams, Dokumente gemeinsam zu erstellen, zu verwalten und zu organisieren. Zu den Kernfunktionen zählen Echtzeit-Kollaboration, die Unterstützung von Diagrammen (Draw.io, Excalidraw, Mermaid), Seitenverlauf, umfangreiche Suchfunktionen, Kommentarfunktionen, detailliertes Berechtigungsmanagement und die Organisation von Inhalten in hierarchischen Strukturen und Räumen (Spaces).

Der Reiz des Selbsthostings, insbesondere für IT-Sicherheitsexperten, liegt in der vollständigen Kontrolle über die Daten. Sensible Informationen verlassen den eigenen Server nicht und sind somit keinen fremden Datenschutzrichtlinien unterworfen. Dies erhöht nicht nur die Sicherheit, sondern auch die Unabhängigkeit. Des Weiteren bietet das Selbsthosting die Möglichkeit, die Anwendung exakt an die eigenen Bedürfnisse anzupassen und die Infrastrukturkosten transparent zu halten.

Das Herzstück: Docker Compose-Konfiguration

Die Installation von Docmost erfolgt mittels Docker Compose, was die Koordination der verschiedenen Dienste – der Docmost-Anwendung selbst, einer PostgreSQL-Datenbank und eines Redis-Caches – erheblich vereinfacht.

Eigener Webserver mit offiziellen Zertifikaten
Der Basis-Artikel für alle folgenden Services, die ich hier demonstrieren werde…

Die docker-compose.yml-Datei und eine .env-Datei werden erstellt. Die .env-Datei dient dazu, sensible Informationen und Konfigurationen getrennt von der docker-compose.yml zu halten, was die Wartung und Sicherheit verbessert. Darin kann man den Variablen entsprechende Werte zuweisen, damit man sie nicht in der docker-compose.yml direkt eintragen muss.

Die docker-compose.yml definiert die Architektur der Anwendung:

services:
  docmost_app:
    image: docmost/docmost:latest
    container_name: docmost_app
    hostname: docmost_app
    depends_on:
      - docmost_db
      - docmost_redis
    environment:
      # Übernahme der Variablen aus der .env-Datei
      APP_URL: ${APP_URL}
      APP_SECRET: ${APP_SECRET}
      DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@docmost_db:5432/${POSTGRES_DB}?schema=public
      REDIS_URL: redis://docmost_redis:6379
      # Optionale SMTP-Konfiguration für E-Mail-Funktionen
      MAIL_DRIVER: ${MAIL_DRIVER}
      SMTP_HOST: ${SMTP_HOST}
      SMTP_PORT: ${SMTP_PORT}
      SMTP_USERNAME: ${SMTP_USERNAME}
      SMTP_PASSWORD: ${SMTP_PASSWORD}
      MAIL_FROM_ADDRESS: ${MAIL_FROM_ADDRESS}
      MAIL_FROM_NAME: ${MAIL_FROM_NAME}
    ports:
      - "3000:3000" # Host-Port:Container-Port. Für produktive Umgebungen mit Reverse Proxy absichern!
    restart: unless-stopped
    volumes:
      - docmost_data:/app/data/storage # Persistente Speicherung der Docmost-Daten
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:3000/api/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s

  docmost_db:
    image: postgres:16-alpine
    container_name: docmost_db
    hostname: docmost_db
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    restart: unless-stopped
    volumes:
      - db_data:/var/lib/postgresql/data # Persistente Speicherung der PostgreSQL-Daten
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5

  docmost_redis:
    image: redis:7.2-alpine
    container_name: docmost_redis
    hostname: docmost_redis
    restart: unless-stopped
    volumes:
      - redis_data:/data # Persistente Speicherung der Redis-Daten
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  docmost_data:
  db_data:
  redis_data:

Um diese Container hinter dem Nginx-Proxy-Manager zu platzieren, muss die ports Direktive der docmost_app entfernt oder durch expose ersetzt werden.

Die obige Konfiguration umfasst somit drei Hauptkomponenten:

  • docmost_app: Der eigentliche Docmost-Dienst, der auf dem offiziellen docmost/docmost:latest Image basiert. Er ist über den Port 3000 erreichbar und speichert seine Daten im docmost_data-Volume. Ein Gesundheitscheck prüft die Erreichbarkeit des /api/health-Endpunkts.
  • docmost_db: Eine PostgreSQL-Datenbank (Version 16-alpine), die als persistenter Datenspeicher für Docmost dient. Ihre Daten werden im db_data-Volume abgelegt. Auch hier sorgt ein Gesundheitscheck für die Überwachung der Datenbankbereitschaft.
  • docmost_redis: Ein Redis-Cache (Version 7.2-alpine), der von Docmost für verschiedene Funktionen genutzt wird. Seine Daten werden im redis_data-Volume gespeichert, und ein Gesundheitscheck prüft die Verfügbarkeit.

Wichtige Umgebungsvariablen in der .env-Datei: Bevor Docmost gestartet werden kann, müssen die Platzhalter in der .env-Datei mit tatsächlichen, sicheren Werten gefüllt werden. Eine beispielhafte .env-Datei könnte wie folgt aussehen:

# Allgemeine App-Einstellungen
APP_URL=https://docmost.example.com
APP_SECRET=<Ihr_zufälliges_App_Secret> # Generieren mit 'openssl rand -hex 32'

# PostgreSQL-Datenbank-Einstellungen
POSTGRES_DB=docmost
POSTGRES_USER=docmost
POSTGRES_PASSWORD=<Ihr_zufälliges_DB_Passwort> # Generieren mit 'openssl rand -hex 32'

# Redis-URL (normalerweise keine Änderung erforderlich)
REDIS_URL=redis://docmost_redis:6379

# Optionale SMTP-Konfiguration für E-Mail-Funktionen
# Entfernen Sie die Kommentarzeichen und füllen Sie die Werte aus, um E-Mails zu aktivieren.
# MAIL_DRIVER=smtp
# SMTP_HOST=smtp.example.com
# SMTP_PORT=587
# SMTP_USERNAME=your_smtp_username
# SMTP_PASSWORD=your_smtp_password
# MAIL_FROM_ADDRESS=noreply@docmost.example.com
# MAIL_FROM_NAME=Docmost

Sichere Geheimnisse generieren: Für APP_SECRET und POSTGRES_PASSWORD sollten kryptographisch starke Zufallswerte verwendet werden. Die offiziellen Docmost-Dokumente empfehlen für APP_SECRET eine Mindestlänge von 32 Zeichen. Mit openssl rand -hex 32 lassen sich 32 Zufallsbytes in einer 64 Zeichen langen Hexadezimaldarstellung generieren, was mehr als ausreichend ist:

# App-Secret generieren
openssl rand -hex 32

# Beispielausgabe: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2

Diese generierten Werte werden dann in die .env-Datei eingetragen.

In Betrieb nehmen: Start und Überprüfung

Nachdem die docker-compose.yml und die .env-Datei konfiguriert wurden, kann Docmost gestartet werden:

docker compose up -d

Der Parameter -d sorgt dafür, dass die Container im Hintergrund laufen und die Konsole freigegeben wird. Der Startvorgang kann je nach System einige Minuten dauern, da Docker die benötigten Images herunterladen muss.

Der Status der laufenden Dienste kann jederzeit überprüft werden:

docker compose ps

Eine erwartete Ausgabe zeigt, dass alle Dienste (docmost_app, docmost_db, docmost_redis) den Status “running” aufweisen:

NAME                COMMAND                  SERVICE         STATUS              PORTS
docmost_app         "docker-entrypoint.s…"   docmost_app     running             0.0.0.0:3000->3000/tcp
docmost_db          "docker-entrypoint.s…"   docmost_db      running (healthy)   5432/tcp
docmost_redis       "docker-entrypoint.s…"   docmost_redis   running (healthy)   6379/tcp

Erste Schritte in der Weboberfläche: Nach erfolgreichem Start sollte Docmost unter http://localhost:3000 (oder der IP-Adresse Ihres Servers, falls Sie direkt zugreifen) im Webbrowser erreichbar sein. Beim ersten Zugriff wird der Einrichtungsassistent angezeigt, der die Erstellung des ersten Workspace und des Administratorkontos ermöglicht.

Sicherheit geht vor: Reverse Proxy und SSL

Für den produktiven Einsatz und den Zugriff über eine eigene Domain ist die Absicherung mittels SSL/TLS-Verschlüsselung unerlässlich. Dies schützt die Kommunikation zwischen dem Client und dem Docmost-Server vor Abhören und Manipulation. Ein Reverse Proxy ist hier die bevorzugte Lösung, um SSL zu terminieren, den Datenverkehr an den Docmost-Container weiterzuleiten und erweiterte Sicherheitsfunktionen (z.B. HTTP-Header-Härtung) zu implementieren.

Erweiterungen: E-Mail-Funktionalität

Für Benachrichtigungen, Benutzerregistrierung und die Funktion zum Zurücksetzen des Passworts ist die Konfiguration eines SMTP-Servers in Docmost unerlässlich. Die docker-compose.yml ist bereits vorbereitet, um die notwendigen Umgebungsvariablen aus der .env-Datei zu übernehmen. Nach dem Ausfüllen der SMTP-Daten in der .env-Datei und einem Neustart des Docmost-Containers stehen die E-Mail-Funktionen zur Verfügung.

Fazit

Docmost bietet als quelloffene, kollaborative Wiki- und Dokumentationssoftware eine leistungsstarke und flexible Alternative zu kommerziellen Lösungen. Die Installation und der Betrieb mittels Docker Compose auf dem eigenen Server ermöglichen maximale Kontrolle über Daten und Infrastruktur. Durch die Kombination einer robusten Docker Compose-Konfiguration, der Nutzung sicherer Geheimnisse und der Integration eines Reverse Proxys mit SSL-Verschlüsselung lässt sich eine sichere und wartbare Plattform für das Wissensmanagement im Team aufbauen.