Wer im Team Wissen festhalten will, braucht kein teures Confluence-Abo: Wiki.js ist eine moderne, selbst hostbare Wiki-Plattform auf Node.js-Basis, die mit Markdown-, WYSIWYG- und Raw-HTML-Editor, eingebauter Git-Synchronisierung und über 50 Integrationsmodulen punktet. Mit 28.400+ GitHub-Stars (Stand Juni 2026) ist Wiki.js die populärste Open-Source-Wiki-Software überhaupt – und dank des offiziellen Docker-Images in wenigen Minuten auf jedem Linux-Host lauffähig. Die Anleitung richtet sich an KMU-Admins und ambitionierte Selfhoster, die eine dauerhafte Wissensdatenbank mit Versionskontrolle aufbauen möchten.

Voraussetzungen

Docker Engine 20.10+ 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.
Mindestens 1 GB RAM (empfohlen: 2 GB für komfortablen Betrieb mit mehreren gleichzeitigen Nutzern).
Mindestens 10 GB freier Speicher für Docker-Images, PostgreSQL-Daten und zukünftige Wiki-Inhalte.
Netzwerkzugang zu Docker Hub für den einmaligen Image-Download (requarks/wiki:2, ca. 157 MB, und postgres:16-alpine).
Optional: Domain und Reverse Proxy für den Produktionsbetrieb mit HTTPS – empfohlen sind Caddy mit automatischem HTTPS oder Traefik.

Schritt 1: Projektordner anlegen

Lege einen dedizierten Ordner für das Wiki.js-Deployment an. Alle Konfigurationsdateien liegen dort; die eigentlichen Daten werden in einem Docker Named Volume verwaltet.

mkdir -p /opt/wikijs
cd /opt/wikijs

Alternativ funktioniert auch ~/wikijs in deinem Home-Verzeichnis, falls du keinen Root-Zugriff hast. Der Pfad selbst ist unkritisch – wichtig ist nur, dass compose.yaml und .env im selben Verzeichnis liegen.

Verifizieren: ls /opt/wikijs zeigt ein leeres Verzeichnis. Noch keine weiteren Ausgaben erwartet.

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

Lege eine .env-Datei an und ersetze die Platzhalterwerte durch echte, zufällig generierte Passwörter. Verwende niemals Beispielwerte wie wikijsrocks oder 12345678 in einer produktiven Installation – das ist das häufigste Sicherheitsversäumnis bei Wiki.js-Deployments.

Sichere Passwörter lassen sich schnell per Terminal generieren:

openssl rand -base64 24

Führe den Befehl zweimal aus – einmal für das Datenbankpasswort, einmal für das Admin-Passwort. Trage die Werte dann in die .env-Datei ein:

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

# Admin-Erstkonto (wird beim ersten Start automatisch angelegt)
ADMIN_EMAIL=admin@beispiel.de
ADMIN_PASS=HIER_SICHERES_ADMIN_PASSWORT_EINTRAGEN

# Zeitzone
TZ=Europe/Berlin

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

Schütze die Datei vor unbefugtem Zugriff, da sie Klartextpasswörter enthält:

chmod 600 /opt/wikijs/.env

Verifizieren: ls -la /opt/wikijs/.env zeigt Berechtigungen -rw------- und den richtigen Besitzer. Mit cat /opt/wikijs/.env prüfst du, ob alle Variablen korrekt gesetzt sind – keine leeren Werte, keine Anführungszeichen-Fehler.

Schritt 3: compose.yaml erstellen

Die compose.yaml definiert zwei Services: db (PostgreSQL 16) und wiki (Wiki.js 2.x). Das entscheidende Detail ist der Healthcheck mit depends_on: Wiki.js startet erst, wenn PostgreSQL wirklich bereit ist – ohne diese Absicherung schlägt der erste Start regelmäßig mit „the database system is starting up" fehl.

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}
      ADMIN_EMAIL: ${ADMIN_EMAIL:-admin@example.com}
      ADMIN_PASS: ${ADMIN_PASS:?ADMIN_PASS must be set}
      TZ: ${TZ:-Europe/Berlin}
    ports:
      - "${WIKI_PORT:-3000}:3000"

volumes:
  db-data:

Ein paar Hinweise zur Konfiguration:

Image-Tag requarks/wiki:2: Dieses Tag folgt automatisch der neuesten stabilen 2.x-Version (aktuell 2.5.314, Stand Mai 2026). Das Alpha-Image ghcr.io/requarks/wiki:3 ist nicht produktionsreif und hat eine abweichende Konfiguration – verwende es nicht für diese Anleitung.
DB_HOST muss exakt dem Service-Namen entsprechen: Im Compose-Stack heißt der Datenbankservice db – daher DB_HOST: db. Benennt man den Service um, muss DB_HOST mitziehen.
Named Volume db-data: Pflicht für Datenpersistenz. Fehlt dieses Volume, gehen alle Wiki-Inhalte beim nächsten docker compose down unwiederbringlich verloren.
Kein Application-Volume für Wiki.js 2.x nötig: Alle Seiteninhalte liegen in PostgreSQL. Ein separater Volume-Mount für die Node.js-App ist nicht erforderlich.

Schritt 4: Stack starten

Starte den Stack aus dem Projektverzeichnis heraus:

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üfe den Status direkt danach:

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

Siehst du restarting beim Wiki-Container, liegt meist ein Konfigurationsfehler vor – prüfe 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 oder eine 302-Weiterleitung auf /login – beides zeigt, dass Wiki.js antwortet.

Schritt 5: Ersteinrichtung im Browser

Öffne http://<server-ip>:3000 im Browser. Beim ersten Aufruf begrüßt dich der Wiki.js-Setup-Assistent. Da du ADMIN_EMAIL und ADMIN_PASS in der .env-Datei gesetzt hast, legt Wiki.js das Admin-Konto automatisch an – du wirst direkt zur Login-Seite weitergeleitet.

Melde dich mit den Zugangsdaten aus deiner .env an. Nach dem Login öffnet sich das Admin-Panel, in dem du:

Den Wiki-Titel und die Sprache der Oberfläche festlegst (Deutsch ist verfügbar).
Weitere Benutzer anlegen oder eine Authentifizierungsquelle (LDAP, Active Directory, OAuth) verbinden kannst.
Die Git-Storage-Integration aktivierst, falls du Seiteninhalte automatisch in ein Git-Repository synchronisieren möchtest (mehr dazu unter „Häufige Fragen").

Verifizieren: Du siehst nach dem Login das Wiki.js-Dashboard mit dem Menüpunkt „Administration" in der linken Seitenleiste. Unter Administration → System → Info wird die Version (z. B. 2.5.314) angezeigt.

Schritt 6: Reverse Proxy und HTTPS einrichten (Produktion)

Für den Produktionsbetrieb sollte Wiki.js nicht direkt auf Port 80/443 exponiert werden, sondern hinter einem Reverse Proxy mit TLS-Terminierung laufen. Wiki.js erwartet dabei korrekte Weiterleitungsheader.

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 als Reverse Proxy gilt: Setze den Header X-Forwarded-Proto, damit Wiki.js interne Links korrekt generiert:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_pass http://localhost:3000;

Ändere dazu in der .env den Port auf einen internen Wert und binde Wiki.js nur an localhost:

WIKI_PORT=127.0.0.1:3000

Anschließend Stack neu starten: docker compose up -d.

Verifizieren: curl -I https://wiki.beispiel.de liefert HTTP/2 200. Im Browser zeigt die Adressleiste ein gültiges TLS-Zertifikat.

Schritt 7: Updates und Backups

Wiki.js und PostgreSQL lassen sich mit zwei Befehlen aktualisieren. Erstelle vor jedem Update ein Datenbankbackup – Wiki.js führt beim Start automatisch Datenbankmigrationen durch, die nicht rückgängig gemacht werden können:

# Datenbank-Backup erstellen
docker compose exec 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

Für automatische Benachrichtigungen bei neuen Image-Versionen empfiehlt sich Diun oder WUD als Watchtower-Nachfolger.

Verifizieren: Nach dem Update zeigt docker compose ps beide Container als running. Unter Administration → System → Info im Browser bestätigst du die neue Versionsnummer. Das Backup-SQL liegt unter /opt/wikijs/ und ist größer als 0 Byte.

Eckdaten auf einen Blick

Eigenschaft	Wert
Offizielles Image	`requarks/wiki:2` (Docker Hub)
Image-Größe	ca. 157 MB
Stabile Version	2.5.314 (Mai 2026)
Lizenz	AGPL-3.0
Datenbank	PostgreSQL 16 (empfohlen), auch MySQL/MariaDB/SQLite
Container-Port	3000 (HTTP); HTTPS erst in Wiki.js 3.x vorgesehen
Architekturen	amd64, arm64, ARMv7 (alle im Haupt-Tag enthalten)
RAM-Minimum	1 GB (empfohlen: 2 GB)

Umgebungsvariable	Pflicht	Beschreibung
`DB_TYPE`	Ja	Datenbanktyp: `postgres`, `mysql`, `mariadb`, `sqlite`
`DB_HOST`	Ja	Hostname des DB-Containers (= Compose-Service-Name)
`DB_USER`, `DB_PASS`, `DB_NAME`	Ja	Datenbankzugangsdaten
`ADMIN_EMAIL`	Empfohlen	E-Mail-Adresse des automatisch angelegten Admin-Kontos
`ADMIN_PASS`	Empfohlen	Passwort des Admin-Kontos (Standardwert `12345678` unbedingt ändern!)
`TZ`	Optional	Zeitzone, z. B. `Europe/Berlin`

Troubleshooting und typische Fehler

„FATAL: the database system is starting up" – Wiki.js startet bevor PostgreSQL bereit ist. Ursache: depends_on ohne condition: service_healthy. Fix: Die compose.yaml aus dieser Anleitung nutzen, die den pg_isready-Healthcheck enthält.
„connection refused" oder „ECONNREFUSED 5432" – DB_HOST stimmt nicht mit dem Compose-Service-Namen überein. Prüfe, ob der Service wirklich db heißt und DB_HOST: db gesetzt ist.
„address already in use" beim Start – Port 3000 ist bereits belegt. Fix: WIKI_PORT=8080 in der .env eintragen, dann docker compose up -d.
Wiki.js startet, aber alle Inhalte sind nach einem Neustart weg – Der Named Volume db-data fehlt oder ist falsch gemountet. Prüfe mit docker volume ls, ob wikijs_db-data existiert. Wichtig: docker compose down -v löscht Volumes – docker compose down (ohne -v) nicht.
Wiki.js nutzt SQLite statt PostgreSQL – DB_TYPE fehlt oder hat einen Tippfehler. SQLite ist der interne Fallback. Prüfen: docker compose logs wiki | grep -i database.
Admin-Passwort vergessen nach erstem Login – Die Setup-Seite (/finalize) ist nur einmalig beim allerersten Start erreichbar. Danach: Passwort-Reset per E-Mail oder direkt über docker compose exec db psql -U wikijs wiki.
Seiten werden hinter einem Reverse Proxy falsch verlinkt – X-Forwarded-Proto-Header fehlt. Im Nginx/Caddy/Traefik den Header korrekt setzen (siehe Schritt 6).

Häufige Fragen

Welche Datenbank soll ich verwenden?

Für den Produktionsbetrieb ist PostgreSQL die offizielle Empfehlung des Wiki.js-Projekts und bietet die beste Stabilität und Performance. SQLite eignet sich ausschließlich für lokale Tests oder sehr kleine Einzelinstallationen ohne gleichzeitige Zugriffe – in der Produktivumgebung riskierst du damit Datenbankkorruptionen unter Last. MySQL und MariaDB werden ebenfalls unterstützt, falls du bereits eine entsprechende Datenbankinfrastruktur betreibst.

Wie aktiviere ich die Git-Synchronisierung?

Wiki.js kann Seiteninhalte bidirektional als Markdown-Dateien in ein Git-Repository synchronisieren – das ist einer der stärksten Unterschiede zu Confluence. Nach dem Login gehst du zu Administration → Storage → Git und aktivierst das Modul. Du benötigst ein Remote-Git-Repository (GitHub, GitLab, Gitea oder selbst gehostet) und konfigurierst die Authentifizierung per SSH-Key oder HTTPS. Git 2.7.4+ ist Voraussetzung – im offiziellen Docker-Image bereits enthalten. Wer einen eigenen Git-Server bevorzugt, findet die passende Anleitung unter Gitea mit Docker: eigener Git-Server als GitHub-Alternative.

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

Die zuverlässigste Sicherungsmethode ist ein PostgreSQL-Dump des laufenden Containers:

docker compose exec db pg_dump -U wikijs wiki > backup-$(date +%Y%m%d-%H%M).sql

Diese Datei lässt sich mit psql vollständig wiederherstellen. Für eine automatisierte, rotierte Backup-Strategie empfiehlt sich die Anleitung MySQL & PostgreSQL Backup automatisieren mit cron. Zusätzlich kannst du das Git-Storage-Modul aktivieren – dann liegen alle Seiteninhalte automatisch als versionierte Markdown-Dateien in einem Repository.

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

Ja – das ist der empfohlene Weg für den Produktionsbetrieb. Wiki.js läuft intern immer auf Port 3000 (HTTP) und erwartet, dass ein vorgelagerter Reverse Proxy die TLS-Terminierung übernimmt. Caddy ist die einfachste Option (automatische Let's-Encrypt-Zertifikate ohne manuelle Konfiguration), Traefik eignet sich gut für komplexe Multi-Container-Setups. Wichtig: Den Header X-Forwarded-Proto: https im Proxy setzen, damit Wiki.js interne Links mit korrektem Protokoll generiert.

Wie viele Nutzer kann Wiki.js gleichzeitig bedienen?

Mit PostgreSQL als Backend sind mehrere Dutzend gleichzeitige Nutzer problemlos möglich. Für sehr große Installationen mit intensiver Volltextsuche empfiehlt sich die Elasticsearch-Integration (unter Administration → Search Engine konfigurierbar) statt der eingebauten Suche. Wiki.js selbst ist zustandslos und lässt sich horizontal skalieren, wenn alle Instanzen dieselbe Datenbank verwenden.

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

Wiki.js 3.0 wird als vollständiger Neubau der Plattform entwickelt und befindet sich Stand Juni 2026 noch in der Alpha-Phase. Das Image ghcr.io/requarks/wiki:3 hat eine veränderte Konfigurationssyntax und ist nicht mit 2.x kompatibel – nicht für den Produktionsbetrieb geeignet. Verwende für stabile Deployments ausschließlich requarks/wiki:2.

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 Copyleft-Pflicht greift erst, wenn du Wiki.js modifizierst und als Netzwerkdienst anbietest – dann musst du den modifizierten Quellcode veröffentlichen. Ein internes KMU-Wiki ist davon in aller Regel nicht betroffen.

Fazit

Wiki.js ist eine der ausgereiftesten selbst hostbaren Wiki-Plattformen, die KMU heute zur Verfügung steht. Die Kombination aus modernem Interface, mehreren Editoren, Git-basierter Versionierung und einem breiten Integrationsangebot macht sie zur überzeugenden Alternative zu Confluence – ohne Abo-Kosten und ohne Cloud-Abhängigkeit. Der Betrieb per Docker Compose ist dank des offiziellen Images unkompliziert; die kritischen Stolperfallen (fehlender Healthcheck, schwaches Passwort, kein Named Volume) lassen sich mit der Konfiguration aus dieser Anleitung von Anfang an vermeiden. Wer über eine Team-Wissensdatenbank nachdenkt, sollte auch Gitea als selbst gehostete Git-Plattform in Betracht ziehen – beide Dienste ergänzen sich hervorragend, wenn Wiki-Inhalte über das Git-Storage-Modul direkt in ein Gitea-Repository synchronisiert werden.

Weiterführende Anleitungen und Quellen

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