Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Docker 18.07.2026 · 9 min Lesezeit

Wiki.js mit Docker installieren: Modernes, leichtgewichtiges Wiki mit Git-Integration

Wiki.js 2.x mit PostgreSQL per Docker Compose installieren: sichere .env, Healthcheck, Setup-Assistent, Reverse Proxy mit Trust Proxy, Update mit pg_dump-Backup und typische Fehler.

Geprüft am 29.09.2026 · für wiki 2

WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Regal mit Ordnern, Büchern und kleinem Server als Sinnbild für eine selbst gehostete Wissensdatenbank

Wiki.js ist eine selbst hostbare Wiki-Plattform auf Node.js-Basis mit Markdown-, WYSIWYG- und HTML-Editor, Git-Synchronisierung und Anbindung an LDAP, Active Directory und OAuth. Diese Anleitung richtet Wiki.js 2.x mit PostgreSQL per Docker Compose ein, inklusive Reverse Proxy, Update und Backup.

Voraussetzungen

  1. Docker Engine 24 oder neuer und Docker Compose Plugin v2 (docker compose ohne Bindestrich) auf einem Linux-Host, einer VM oder einem NAS mit Docker-Unterstützung – falls noch nicht vorhanden, hilft die Anleitung Docker und Docker Compose auf Linux installieren.
  2. Mindestens 1 GB RAM (empfohlen 2 GB) und 1 CPU-Kern (empfohlen 2), amd64 oder arm64.
  3. Mindestens 10 GB freier Speicher für Docker-Images, PostgreSQL-Daten und zukünftige Wiki-Inhalte.
  4. Netzwerkzugang zu Docker Hub für den einmaligen Image-Download (requarks/wiki:2, rund 170 MB, und postgres:16-alpine).
  5. Optional: Domain und Reverse Proxy für den Produktionsbetrieb mit HTTPS – empfohlen sind Caddy mit automatischem HTTPS oder Traefik.

Schritt 1: Projektordner anlegen

Legen Sie einen eigenen Ordner für Wiki.js an. Dort liegen die Konfigurationsdateien; die Daten verwaltet Docker in einem Named Volume.

sudo mkdir -p /opt/wikijs
sudo chown $USER: /opt/wikijs
cd /opt/wikijs

Der Pfad ist frei wählbar; compose.yaml und .env müssen im selben Verzeichnis liegen.

Verifizieren: ls -ld /opt/wikijs zeigt Ihren Benutzer als Besitzer.

Schritt 2: .env-Datei mit sicheren Passwörtern anlegen

Erzeugen Sie ein zufälliges Datenbankpasswort. Verwenden Sie nicht das Beispielpasswort wikijsrocks aus der offiziellen Dokumentation. Die Option -hex vermeidet Sonderzeichen, die in YAML oder Verbindungszeichenfolgen Probleme machen:

openssl rand -hex 24

Legen Sie damit die .env-Datei an:

# Wiki.js – Umgebungsvariablen
# Datenbankzugangsdaten
POSTGRES_USER=wikijs
POSTGRES_DB=wiki
POSTGRES_PASSWORD=HIER_SICHERES_PASSWORT_EINTRAGEN

# Zeitzone
TZ=Europe/Berlin

# Externer Port (Standard 3000; bei Konflikt z. B. 8080 eintragen)
WIKI_PORT=3000

Schützen Sie die Datei, weil sie das Passwort im Klartext enthält:

chmod 600 /opt/wikijs/.env

Verifizieren: ls -la /opt/wikijs/.env zeigt -rw------- und Ihren Benutzer als Besitzer. grep -c = /opt/wikijs/.env gibt 5 aus, und keine Zeile endet auf =.

Schritt 3: compose.yaml erstellen

Die compose.yaml definiert zwei Services: db (PostgreSQL 16) und wiki (Wiki.js 2.x). Der Healthcheck mit depends_on sorgt dafür, dass Wiki.js erst startet, wenn PostgreSQL bereit ist. Ohne ihn scheitert der erste Start oft mit „the database system is starting up“.

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB:-wiki}
      POSTGRES_USER: ${POSTGRES_USER:-wikijs}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD must be set}
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-wikijs} -d ${POSTGRES_DB:-wiki}"]
      interval: 10s
      timeout: 5s
      retries: 5

  wiki:
    image: requarks/wiki:2
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: ${POSTGRES_USER:-wikijs}
      DB_PASS: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD must be set}
      DB_NAME: ${POSTGRES_DB:-wiki}
      TZ: ${TZ:-Europe/Berlin}
    ports:
      - "${WIKI_PORT:-3000}:3000"

volumes:
  db-data:

Hinweise zur Konfiguration:

  1. Image-Tag requarks/wiki:2: Dieses Tag folgt der neuesten stabilen 2.x-Version (derzeit 2.5.315, September 2026) und wird von den Entwicklern empfohlen; latest sollten Sie nicht nutzen. Die Tags 3.0.0-beta… gehören zur Beta von Wiki.js 3 und passen nicht zu dieser Anleitung.
  2. DB_HOST muss exakt dem Service-Namen entsprechen: Im Compose-Stack heißt der Datenbankservice db – daher DB_HOST: db. Benennen Sie den Service um, passen Sie DB_HOST an.
  3. Named Volume db-data: hält die Datenbank über Neuerstellungen des Containers hinweg. docker compose down -v löscht es samt allen Inhalten.
  4. Kein Volume für Wiki.js selbst nötig: Seiten, Benutzer und Einstellungen liegen in PostgreSQL.

Verifizieren: docker compose config --quiet endet ohne Ausgabe. Meldet der Befehl POSTGRES_PASSWORD must be set, fehlt der Wert in der .env.

Schritt 4: Stack starten

Starten Sie den Stack im Projektverzeichnis:

cd /opt/wikijs
docker compose up -d

Docker lädt beide Images herunter (beim ersten Mal ca. 200–300 MB), startet PostgreSQL, wartet auf den Healthcheck und startet dann Wiki.js. Das dauert je nach Verbindungsgeschwindigkeit und Hardware 30–90 Sekunden.

Prüfen Sie den Status:

docker compose ps

Erwartete Ausgabe (beide Services running bzw. healthy):

NAME            IMAGE                COMMAND                  SERVICE   STATUS
wikijs-db-1     postgres:16-alpine   "docker-entrypoint.s…"   db        running (healthy)
wikijs-wiki-1   requarks/wiki:2      "node server"            wiki      running

Zeigt der Wiki-Container restarting, liegt meist ein Konfigurationsfehler vor. Prüfen Sie die Logs:

docker compose logs wiki --tail 50

Verifizieren: Beide Container zeigen running in der Spalte STATUS, der db-Container zusätzlich (healthy). Abschließender HTTP-Test:

curl -I http://localhost:3000

Erwartete Antwort: HTTP/1.1 200 OK. Das Log zeigt Browse to http://YOUR-SERVER-IP:3000/ to complete setup!.

Schritt 5: Ersteinrichtung im Browser

Öffnen Sie http://<server-ip>:3000 im Browser. Der Setup-Assistent fragt E-Mail-Adresse und Passwort des Administratorkontos sowie die Site URL ab. Tragen Sie dort die spätere Adresse ein, zum Beispiel https://wiki.example.de; Wiki.js erzeugt damit absolute Links. Schließen Sie den Assistenten zeitnah ab: Bis dahin kann jeder, der den Port erreicht, das Administratorkonto anlegen.

Melden Sie sich danach an. Unter Administration legen Sie fest:

  1. den Wiki-Titel und die Sprache (Deutsch unter Locale herunterladen),
  2. weitere Benutzer oder eine Authentifizierungsquelle (LDAP, Active Directory, OAuth),
  3. bei Bedarf die Git-Storage-Integration (siehe „Häufige Fragen“).

Verifizieren: Nach dem Login erreichen Sie Administration; unter System Info steht die Version, zum Beispiel 2.5.315.

Schritt 6: Reverse Proxy und HTTPS einrichten (Produktion)

Im Produktivbetrieb läuft Wiki.js hinter einem Reverse Proxy mit TLS. Wiki.js kann zwar selbst Let's-Encrypt-Zertifikate beziehen (SSL_ACTIVE, Port 3443), ein vorgelagerter Proxy ist aber einfacher zu warten.

Die vollständige Reverse-Proxy-Einrichtung beschreiben die Grundanleitungen Caddy als Reverse Proxy mit automatischem HTTPS und Traefik als Docker-Reverse-Proxy.

Für Nginx reichen im location-Block diese Zeilen:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://127.0.0.1:3000;

Aktivieren Sie danach unter Administration → Security die Option Trust Proxy, damit Wiki.js die weitergereichten Client-Adressen und das Protokoll übernimmt.

Binden Sie Wiki.js anschließend nur an localhost, indem Sie in der .env den Port ändern:

WIKI_PORT=127.0.0.1:3000

Übernehmen Sie die Änderung mit docker compose up -d.

Verifizieren: curl -I https://wiki.example.de liefert 200, und curl -I http://SERVER-IP:3000 von einem anderen Rechner schlägt fehl.

Schritt 7: Updates und Backups

Erstellen Sie vor jedem Update ein Datenbankbackup: Wiki.js führt beim Start Datenbankmigrationen aus, die sich nicht rückgängig machen lassen.

# Datenbank-Backup erstellen
docker compose exec -T db pg_dump -U wikijs wiki > /opt/wikijs/backup-$(date +%Y%m%d).sql

# Images aktualisieren und neu starten
docker compose pull
docker compose up -d

# Wiederherstellen (leere Datenbank vorausgesetzt)
docker compose exec -T db psql -U wikijs wiki < backup-DATUM.sql

Die PostgreSQL-Hauptversion (16) wechselt dabei nicht. Ein Wechsel auf eine neue Hauptversion braucht Dump und Wiederherstellung in ein neues Volume.

Benachrichtigungen über neue Image-Versionen liefern Diun oder WUD als Watchtower-Nachfolger.

Verifizieren: Nach dem Update zeigt docker compose ps beide Container als running. System Info zeigt die neue Version. head -3 backup-*.sql beginnt mit -- PostgreSQL database dump.

Eckdaten auf einen Blick

EigenschaftWert
Offizielles Imagerequarks/wiki:2 (Docker Hub)
Image-Größerund 170 MB
Stabile Version2.5.315 (September 2026)
LizenzAGPL-3.0
DatenbankPostgreSQL (empfohlen, ab 9.5), auch MySQL, MariaDB, MS SQL, SQLite; Wiki.js 3 unterstützt nur noch PostgreSQL
Container-Port3000 (HTTP), optional 3443 (HTTPS mit Let's Encrypt)
Architekturenamd64, arm64
RAM-Minimum1 GB (empfohlen: 2 GB)
UmgebungsvariablePflichtBeschreibung
DB_TYPEJaDatenbanktyp: postgres, mysql, mariadb, mssql, sqlite
DB_HOSTJaHostname des DB-Containers (= Compose-Service-Name)
DB_PORT, DB_USER, DB_PASS, DB_NAMEJaDatenbankzugangsdaten; statt DB_PASS geht DB_PASS_FILE für Docker Secrets
SSL_ACTIVE, LETSENCRYPT_DOMAIN, LETSENCRYPT_EMAILOptionaleingebautes HTTPS über Let's Encrypt
HA_ACTIVEOptionalHochverfügbarkeit mit mehreren Instanzen (nur PostgreSQL)

Troubleshooting und typische Fehler

  1. „FATAL: the database system is starting up“ – Wiki.js startet, bevor PostgreSQL bereit ist. Ursache: depends_on ohne condition: service_healthy. Lösung: die compose.yaml aus Schritt 3 mit pg_isready-Healthcheck verwenden.
  2. „connection refused“ oder „ECONNREFUSED 5432“ – DB_HOST stimmt nicht mit dem Compose-Service-Namen überein. Prüfen Sie, ob der Service db heißt und DB_HOST: db gesetzt ist.
  3. „address already in use“ beim Start – Port 3000 ist bereits belegt. Lösung: WIKI_PORT=8080 in der .env eintragen, dann docker compose up -d.
  4. Wiki.js startet, aber alle Inhalte sind nach einem Neustart weg – Der Named Volume db-data fehlt oder ist falsch gemountet. Prüfen Sie mit docker volume ls, ob wikijs_db-data existiert. Wichtig: docker compose down -v löscht Volumes – docker compose down (ohne -v) nicht.
  5. „password authentication failed for user“ – Das Passwort in der .env wurde nach dem ersten Start geändert. PostgreSQL übernimmt POSTGRES_PASSWORD nur beim Anlegen des Volumes. Setzen Sie den alten Wert zurück oder ändern Sie das Passwort per ALTER USER in psql.
  6. Admin-Passwort vergessen – Der Setup-Assistent läuft nur beim ersten Start. Legen Sie deshalb früh ein zweites Administratorkonto an oder richten Sie unter Administration → Mail einen SMTP-Server ein, damit die Funktion „Passwort vergessen“ arbeitet.
  7. Links zeigen hinter dem Reverse Proxy auf http oder die falsche Adresse – Die Site URL unter Administration → General stimmt nicht, oder X-Forwarded-Proto und Trust Proxy fehlen (siehe Schritt 6).

Häufige Fragen

Welche Datenbank soll ich verwenden?

PostgreSQL. Das Projekt empfiehlt es ausdrücklich, nur damit funktionieren die PostgreSQL-Suche und Hochverfügbarkeit, und Wiki.js 3 unterstützt keine anderen Datenbanken mehr. MySQL, MariaDB, MS SQL und SQLite erschweren daher den späteren Umstieg.

Wie aktiviere ich die Git-Synchronisierung?

Wiki.js synchronisiert Seiten als Markdown-Dateien in ein Git-Repository, auf Wunsch in beide Richtungen. Aktivieren Sie unter Administration → Storage → Git das Modul, tragen Sie ein Remote-Repository (GitHub, GitLab, Gitea) ein und hinterlegen Sie die Authentifizierung per SSH-Key oder HTTPS-Token. Git ist im Docker-Image enthalten. Einen eigenen Git-Server beschreibt die Anleitung Gitea mit Docker: eigener Git-Server als GitHub-Alternative.

Wie sichere ich meine Wiki.js-Installation regelmäßig?

Mit dem pg_dump-Befehl aus Schritt 7, täglich per cron und mit Kopie außerhalb des Servers. Eine automatisierte, rotierte Sicherung beschreibt die Anleitung MySQL & PostgreSQL Backup automatisieren mit cron. Das Git-Storage-Modul ergänzt das, ersetzt aber kein Datenbankbackup: Benutzer, Rechte und Einstellungen liegen nur in PostgreSQL.

Kann ich Wiki.js hinter einem Reverse Proxy mit HTTPS betreiben?

Ja, das ist der empfohlene Weg, siehe Schritt 6. Wiki.js muss dabei auf einer eigenen (Sub-)Domain laufen; ein Unterordner wie /wiki wird nicht unterstützt.

Wie viele Nutzer kann Wiki.js gleichzeitig bedienen?

Für typische KMU-Wikis mit einigen Dutzend gleichzeitigen Nutzern reicht eine Instanz mit 2 GB RAM. Große Installationen nutzen unter Administration → Search Engine PostgreSQL oder Elasticsearch statt der Basissuche. Mehrere Instanzen hinter einem Load Balancer erfordern PostgreSQL und HA_ACTIVE=true.

Was ist der Unterschied zwischen Wiki.js 2.x und 3.x?

Wiki.js 3 ist ein Neubau und befindet sich im September 2026 in der Beta-Phase (Tags 3.0.0-beta…). Konfiguration und Datenmodell weichen von 2.x ab, und nur PostgreSQL wird unterstützt. Für den Produktivbetrieb bleibt requarks/wiki:2 die stabile Wahl.

Wird die AGPL-3.0-Lizenz zum Problem für mein Unternehmen?

Für die reine interne Nutzung ohne Modifikation des Wiki.js-Quellcodes ist AGPL-3.0 kein Problem. Die Pflicht zur Offenlegung greift, wenn Sie Wiki.js verändern und Dritten als Netzwerkdienst anbieten; dann müssen Sie diesen Nutzern den geänderten Quellcode zugänglich machen. Ein internes KMU-Wiki ist davon in aller Regel nicht betroffen.

Fazit

Wiki.js 2.x mit PostgreSQL läuft per Docker Compose mit wenig Aufwand und ohne Lizenzkosten. Entscheidend sind ein zufälliges Datenbankpasswort, der Healthcheck, das Named Volume, ein zügig abgeschlossener Setup-Assistent und regelmäßige pg_dump-Sicherungen. Für versionierte Inhalte ergänzt Gitea als selbst gehostete Git-Plattform das Git-Storage-Modul.

Weiterführende Anleitungen und Quellen

  1. Docker und Docker Compose auf Linux installieren – die Self-Hosting-Grundlage
  2. Caddy als Reverse Proxy mit automatischem HTTPS einrichten
  3. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS
  4. MySQL & PostgreSQL Backup automatisieren mit cron und rclone
  5. Gitea mit Docker: eigener Git-Server als GitHub-Alternative
  6. Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only

Offizielle Quellen: Wiki.js Installationsdokumentation (Docker) · Wiki.js GitHub-Repository · Wiki.js Docker Hub · Wiki.js Systemanforderungen · Wiki.js Git-Storage-Dokumentation