Wiki.js auf Synology NAS installieren: Git-gestütztes Firmen-Wiki mit PostgreSQL

Ein zentrales Firmen-Wiki muss mehr leisten als nur Seiten anzuzeigen: Es soll schnell sein, Markdown unterstützen, lokal auf deinem NAS liegen und gleichzeitig versioniertes Backup bieten. Wiki.js vereint diese Anforderungen in einer modernen Node.js-Anwendung, die sich auf einem Synology NAS als Docker-Container betreiben lässt. In dieser Anleitung richtest du Wiki.js mit PostgreSQL als Datenbank ein, konfigurierst den ersten Admin-Account und verbindest das Wiki per Git-Storage-Modul mit einem Repository – ideal für technische Teams, die ihren Wissensstand in Git sichern wollen. Im Vergleich zu BookStack, Outline oder Docmost punktet Wiki.js mit nativem Git-Backup, einem klaren Markdown-Editor und einem Fokus auf Entwickler- und Admin-Teams.

Voraussetzungen

Das offizielle Docker-Image von Wiki.js ist ghcr.io/requarks/wiki:2. Pinne das Major-Tag :2, nicht latest. Damit bleibst du in der 2.x-Linie und vermeidest Überraschungen bei zukünftigen Versionen. Für ARM-basierte Synology-Modelle gilt: arm64 wird unterstützt, arm/v7 aber nur bis Wiki.js 2.5.303. Prüfe die Architektur deines NAS, bevor du den Container startest.

Ein wichtiger Hinweis vorab: Wiki.js legt die Datenbank nicht selbst an. PostgreSQL muss beim ersten Start bereits eine leere Datenbank mit passendem Benutzer bereitgestellt haben. Das Compose-File übernimmt diese Aufgabe, indem es die POSTGRES_DB-Variable setzt.

Schritt 1: Projektverzeichnis und Datenbank-Ordner anlegen

Öffne die File Station und navigiere zu /volume1/docker. Erstelle dort den Ordner wikijs und darin den Unterordner db. Der Pfad sollte also lauten:

/volume1/docker/wikijs/db

Der db-Ordner wird später an PostgreSQL gebunden und enthält alle Datenbankdateien. Achte darauf, dass der Ordnerbesitzer dein Container Manager ist oder zumindest Schreibrechte für Docker bestehen. In der Regel reicht es, die Ordner über die File Station unter deinem eigenen DSM-Benutzer anzulegen.

Verifizieren: In der File Station siehst du den Pfad /volume1/docker/wikijs/db als leeren, beschreibbaren Ordner. Notiere dir den vollständigen Pfad, du brauchst ihn im Compose-File.

Schritt 2: Compose-Datei im Container Manager erstellen

Öffne den Container Manager und wähle Projekt > Erstellen. Gib als Namen wikijs ein und wähle als Pfad /volume1/docker/wikijs. Im nächsten Schritt legst du die compose.yaml an. Füge folgenden Inhalt ein:

services:
  db:
    image: postgres:15-alpine
    container_name: wikijs-db
    hostname: wikijs-db
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    volumes:
      - /volume1/docker/wikijs/db:/var/lib/postgresql/data
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U wikijs -d wiki"]
      interval: 10s
      timeout: 5s
      retries: 5

  wiki:
    image: ghcr.io/requarks/wiki:2
    container_name: wikijs
    hostname: wikijs
    depends_on:
      db:
        condition: service_healthy
    environment:
      DB_TYPE: postgres
      DB_HOST: wikijs-db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    ports:
      - "3540:3000"
    restart: unless-stopped

Einige Erklärungen zu den Entscheidungen in diesem Stack:

1. Offizielles Image statt LinuxServer: Manche Anleitungen im Netz nutzen ghcr.io/linuxserver/wikijs. Das ist ein Community-Image mit eigenen Pfaden wie /config und Variablen wie PUID/PGID/TZ. Das offizielle Image speichert Inhalte in der Datenbank und kennt diese Variablen nicht.
2. PostgreSQL 15: Die offizielle Docker-Dokumentation von Wiki.js verwendet postgres:15-alpine. PostgreSQL 18 existiert zwar, wird aber in den offiziellen Beispielen nicht genannt. Für Stabilität bleiben wir bei 15.
3. Host-Port 3540: Synology reserviert 80 und 443 für den Reverse Proxy. Daher lauscht Wiki.js intern auf Port 3000 und wird auf dem Host auf 3540 gemappt.
4. Keine SSL-Variablen: Weil SSL in der Regel am Synology-Reverse Proxy terminiert wird, bleiben SSL_ACTIVE, LETSENCRYPT_DOMAIN und LETSENCRYPT_EMAIL leer. Port 3443 brauchst du hier nicht.

Verifizieren: Im Container Manager wird das Projekt wikijs angezeigt, die compose.yaml enthält die beiden Services db und wiki, und der Datenbank-Ordner ist korrekt auf /var/lib/postgresql/data gemappt.

Schritt 3: Stack starten und Datenbank prüfen

Klicke im Container Manager auf Erstellen bzw. Bauen und Starten, um das Projekt zu starten. Der Container Manager lädt die Images und startet zuerst die Datenbank. Dank des Healthchecks wartet der Wiki.js-Container automatisch, bis PostgreSQL bereit ist.

Beobachte die Container-Logs, bis du eine Zeile wie diese siehst:

PostgreSQL init process complete; ready for start up.

Anschließend sollte Wiki.js im Log melden, dass es die Verbindung zur Datenbank hergestellt und das Setup abgeschlossen hat. Falls der Wiki-Container neugestartet wird, warte, bis die Datenbank den Healthcheck erfolgreich absolviert hat.

Verifizieren: Im Container Manager sind beide Container als Wird ausgeführt markiert. Der Healthcheck der Datenbank zeigt healthy an, und im Log des wikijs-Containers erscheint keine wiederholende Fehlermeldung zu ECONNREFUSED oder database does not exist.

Schritt 4: Admin-Konto über das Web-Setup anlegen

Rufe im Browser die Adresse deines NAS mit dem internen Port auf:

http://DEINE-NAS-IP:3540

Beim ersten Start zeigt Wiki.js den Setup-Assistenten. Lege dort das Admin-Konto an:

1. Wähle die gewünschte Sprache, z. B. Deutsch.
2. Gib einen Admin-Benutzernamen, eine E-Mail-Adresse und ein sicheres Passwort ein.
3. Bestätige die Angaben und warte, bis Wiki.js die Datenbanktabellen angelegt hat.

Danach gelangst du direkt ins Dashboard. Melde dich mit dem eben erstellten Admin-Account an. Bewahre die Zugangsdaten sicher auf, denn das Admin-Konto lässt sich später nicht ohne weiteres über das Web-Interface wiederherstellen.

Verifizieren: Du kannst dich mit dem Admin-Benutzer anmelden und siehst das Wiki.js-Dashboard mit der linken Seitenleiste und der Willkommensseite.

Schritt 5: SSH-Deploy-Key für Git erzeugen

Für die Git-Synchronisation benötigst du ein passwortloses SSH-Schlüsselpaar. Das Git-Storage-Modul von Wiki.js akzeptiert keine SSH-Keys mit Passphrase. Du kannst den Key entweder über die DSM-eigene Taskplaner-SSH oder von einem beliebigen Rechner mit Git Bash oder OpenSSH erzeugen.

Führe folgenden Befehl aus:

ssh-keygen -t ed25519 -C "wikijs-deploy@deine-domain.de" -f ~/.ssh/wikijs_deploy -N ""

Das erzeugt zwei Dateien:

1. ~/.ssh/wikijs_deploy – der private Schlüssel
2. ~/.ssh/wikijs_deploy.pub – der öffentliche Schlüssel

Öffne die .pub-Datei mit einem Texteditor und kopiere den kompletten Inhalt, der mit ssh-ed25519 beginnt.

Verifizieren: Der private Key enthält keine Passphrase. Du kannst das testen, indem du ssh-keygen -y -f ~/.ssh/wikijs_deploy ausführst – das Kommando fragt nicht nach einem Passwort und zeigt den zugehörigen Public-Key an.

Schritt 6: Git-Repository vorbereiten und Deploy-Key hinterlegen

Erstelle bei deinem Anbieter ein neues, leeres Repository. Nenne es beispielsweise company-wiki. Das Repository sollte ausschließlich Wiki.js vorbehalten sein, denn das Storage-Modul unterstützt keine Unterordner oder Submodule.

Gehe dann zu den Repository-Einstellungen und hinterlege den Deploy-Key:

1. GitHub: Settings > Deploy keys > Add deploy key – füge den Public-Key ein und aktiviere Allow write access.
2. GitLab: Settings > Repository > Deploy keys – füge den Public-Key hinzu und gewähre write-Berechtigung.
3. Andere Anbieter: Suche nach „Deploy keys“ oder „SSH keys“ im Repository-Bereich.

Merke dir die SSH-URL des Repositories, beispielsweise:

git@github.com:DEIN-USER/company-wiki.git

Verifizieren: Im Ziel-Repository deines Anbieters ist der Deploy-Key mit Schreibzugriff hinterlegt, und die SSH-URL ist kopiert. Ein manueller Test mit ssh -T git@github.com von dem Rechner aus, der den private Key besitzt, sollte die Authentifizierung bestätigen.

Schritt 7: Git-Sync in Wiki.js aktivieren

Melde dich als Admin in Wiki.js an und öffne Administration > Storage > Git. Aktiviere das Modul und trage folgende Werte ein:

Speichere die Einstellungen mit Apply Changes. Wiki.js führt nun einen ersten Sync durch und schreibt die vorhandenen Seiten als Markdown-Dateien in das Repository. Ab diesem Zeitpunkt ist jede Änderung im Wiki nach spätestens fünf Minuten im Git-Repository nachvollziehbar.

Verifizieren: Im Ziel-Repository erscheinen Dateien und ein erster Commit von Wiki.js. Ändere oder erstelle eine Seite im Wiki, warte bis zu fünf Minuten und prüfe, ob ein neuer Commit im Repository gelandet ist.

Schritt 8: Externen Zugriff über Reverse Proxy einrichten

Um Wiki.js über eine Domain mit HTTPS zu erreichen, nutzt du am besten den Synology-Reverse-Proxy. Das NAS übernimmt dann die TLS-Terminierung, und Wiki.js selbst muss keine Zertifikate kennen.

Gehe zu Systemsteuerung > Anmeldeportal > Erweitert > Reverse Proxy und erstelle einen neuen Eintrag:

1. Quelle: HTTPS, deine Domain, Port 443
2. Ziel: HTTP, localhost, Port 3540

Falls du Wiki.js intern über HTTPS ansprechen möchtest, belasse es beim Reverse Proxy und verzichte auf SSL_ACTIVE im Container. Das vereinfacht die Verwaltung erheblich, weil Zertifikate und Erneuerung komplett beim NAS liegen.

Verifizieren: Du erreichst Wiki.js über https://wiki.deine-domain.de und siehst im Browser ein gültiges Zertifikat. Die Weboberfläche funktioniert ohne Zertifikatswarnung.

Troubleshooting / Typische Fehler

Häufige Fragen

Welche Datenbank ist für Wiki.js empfohlen?

PostgreSQL ist die empfohlene Datenbank. MySQL, MariaDB, MS SQL Server und SQLite werden in Wiki.js 2.x noch unterstützt, in Version 3.0 aber entfallen. Setze daher gleich auf PostgreSQL, um später keine Migration durchführen zu müssen.

Warum verwendet die Anleitung Port 3540 statt 80 oder 443?

Synology reserviert die Ports 80 und 443 für Systemdienste und den Reverse Proxy. Deshalb wird Wiki.js intern auf einem hohen Host-Port wie 3540 betrieben und über den Reverse Proxy an die HTTPS-Domain weitergeleitet.

Funktioniert Wiki.js auf ARM-basierten Synology-NAS?

Ja, das offizielle Image unterstützt arm64. arm/v7 wird jedoch nur bis Version 2.5.303 unterstützt. Pinne das Major-Tag :2 und prüfe die Architektur deines Modells, bevor du den Container startest.

Kann ich das LinuxServer-Wiki.js-Image stattdessen verwenden?

Du kannst, musst dann aber die LinuxServer-spezifischen Pfade und Variablen beachten. Das offizielle Image ist schlanker, weil es keine extra Volumes wie /config oder /data benötigt und alle Einstellungen über Umgebungsvariablen erhält.

Was passiert, wenn das Git-Repository bereits Dateien enthält?

Das Git-Storage-Modul erwartet ein Wiki.js vorbehaltenes Repository. Vorhandene Dateien oder Unterordner, die nicht dem Wiki.js-Format entsprechen, können den Sync stören. Lege für das Wiki ein frisches Repository an.

Fazit

Wiki.js auf einem Synology NAS zu betreiben, lohnt sich für technische Teams, die ein selbstgehostetes Wiki mit Markdown und versioniertem Backup wollen. Der offizielle Docker-Stack mit PostgreSQL ist überschaubar, und die Git-Synchronisation macht jede Änderung nachvollziehbar und wiederherstellbar. Im Vergleich zu BookStack, Outline oder Docmost hebt sich Wiki.js besonders durch das native Git-Backup und den klaren Fokus auf Entwickler- und Admin-Workflows ab. Halte dich an das Major-Tag :2, lasse SSL am Synology-Reverse Proxy terminiert und nutze ein dediziertes Git-Repository – dann hast du ein robustes Firmen-Wiki, das du lokal kontrollierst und zentral sicherst.

Weiterführende Anleitungen und Quellen

1. BookStack als Firmen-Wiki auf Synology NAS installieren
2. Outline auf Synology NAS: Team-Wiki als Notion-Alternative
3. Docmost auf Synology NAS: Confluence-Alternative für Teams
4. Wiki.js offizielle Docker-Dokumentation
5. Wiki.js Git Storage Modul Dokumentation
6. Wiki.js GitHub Repository
7. Mariushosting: How to install Wiki.js on your Synology NAS