WordPress ist das meistgenutzte Content-Management-System der Welt – und auf einem Synology NAS lässt es sich überraschend unkompliziert als selbst gehostete Website oder als isolierte Staging-Umgebung betreiben. Der Schlüssel liegt im Container Manager (DSM 7.2+): Statt einer klassischen LAMP-Installation auf dem Host läuft WordPress in einem Docker-Compose-Projekt gemeinsam mit MariaDB. Persistente Volumes sichern alle WordPress-Dateien sowie die Datenbankdaten dauerhaft auf deinem NAS – ein Container-Neustart oder Image-Update löscht nichts. Über den eingebauten DSM-Reverse-Proxy erreichst du deine Installation anschließend per HTTPS unter deiner eigenen Domain. Diese Anleitung richtet sich an Hobby-Entwickler, kleine Büros und alle, die WordPress lokal testen oder eine einfache eigene Website auf ihrem Synology betreiben möchten.

Voraussetzungen

Synology NAS mit DSM 7.2 oder neuer und installiertem Container Manager
Mindestens 2 GB freier RAM auf dem NAS (WordPress + MariaDB zusammen)
Mindestens 2 GB freier Speicherplatz auf Volume 1 (Image-Download + WordPress-Dateien)
Domain oder Subdomain mit DNS-Eintrag auf die NAS-IP (für Reverse Proxy; alternativ: Zugriff per IP:8080 möglich)
SSL-Zertifikat im DSM (Let's Encrypt, kostenlos über Systemsteuerung > Zertifikat)
Starke, einzigartige Passwörter für MARIADB_ROOT_PASSWORD und MARIADB_PASSWORD – vor dem Start festlegen
SSH-Zugriff auf das NAS (für Berechtigungsanpassungen; optional, aber empfohlen)

Schritt 1: Ordnerstruktur anlegen

Bevor du das Compose-Projekt startest, müssen die Host-Verzeichnisse existieren. Der Container Manager legt Elternverzeichnisse nicht automatisch an – fehlende Ordner führen dazu, dass MariaDB die Datenbank nicht initialisiert oder WordPress keine Schreibrechte hat.

Öffne die File Station, navigiere zu docker und erstelle folgende Unterordner (Schritt-für-Schritt-Anleitung zu Docker-Ordnern und Berechtigungen auf dem Synology NAS):

/volume1/docker/wordpress/html
/volume1/docker/wordpress/db

Der Ordner html nimmt die komplette WordPress-Installation inklusive wp-content auf. Der Ordner db speichert die MariaDB-Datenbankdateien. Optional kannst du jetzt eine Upload-Konfiguration ablegen:

/volume1/docker/wordpress/php-uploads.ini

Der Inhalt dieser Datei (per SSH oder Text-Editor in der File Station):

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M

Damit hebst du die Standard-PHP-Begrenzung von 2 MB auf 64 MB an – wichtig für Themes und Plugins.

Verifizieren: Öffne die File Station und prüfe, ob /volume1/docker/wordpress/html und /volume1/docker/wordpress/db als leere Ordner existieren. Beide Ordner müssen beim ersten Container-Start leer sein, sonst initialisiert MariaDB die Datenbank nicht neu.

Schritt 2: Compose-Projekt im Container Manager anlegen

Öffne den Container Manager, wechsle zu Projekt und klicke auf Erstellen. Vergib den Projektnamen wordpress und wähle als Pfad /volume1/docker/wordpress. Wähle „compose.yaml erstellen" und füge folgenden Inhalt ein (allgemeine Anleitung zum Anlegen von Compose-Projekten im Container Manager):

services:
  db:
    image: mariadb:lts
    container_name: wordpress-db
    restart: always
    environment:
      MARIADB_DATABASE: wordpress_db
      MARIADB_USER: wp_user
      MARIADB_PASSWORD: sicheres_passwort
      MARIADB_ROOT_PASSWORD: sicheres_root_passwort
      TZ: Europe/Berlin
    volumes:
      - /volume1/docker/wordpress/db:/var/lib/mysql
    networks:
      - wordpress_net

  wordpress:
    image: wordpress:latest
    container_name: wordpress-app
    restart: always
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: sicheres_passwort
      WORDPRESS_DB_NAME: wordpress_db
      WORDPRESS_TABLE_PREFIX: wp_
      TZ: Europe/Berlin
    volumes:
      - /volume1/docker/wordpress/html:/var/www/html
      - /volume1/docker/wordpress/php-uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
    networks:
      - wordpress_net

networks:
  wordpress_net:
    driver: bridge

Ersetze sicheres_passwort und sicheres_root_passwort durch tatsächlich starke, unterschiedliche Passwörter. Alle vier WORDPRESS_DB_*-Variablen sind Pflicht – fehlt eine davon, startet die Datenbankverbindung nicht und der WordPress-Installer bleibt auf dem Fehlerscreen hängen.

Parameter	Wert	Hinweis
WordPress-Image	`wordpress:latest`	Aktuell WP 7.0.0 / PHP 8.3 / Apache; für feste Version: `wordpress:7.0.0-php8.4-apache`
MariaDB-Image	`mariadb:lts`	Aktuell 12.3.2-noble; für 11.x explizit: `mariadb:11-lts`
Externer Port	`8080`	Nur intern; wird per Reverse Proxy auf HTTPS gemappt
MariaDB-Port	nicht exponiert	Läuft nur im Container-Netz `wordpress_net`
Volume html	`/volume1/docker/wordpress/html`	Gesamte WP-Installation inkl. wp-content
Volume db	`/volume1/docker/wordpress/db`	MariaDB-Datenbankdateien
restart	`always`	Robuster als `on-failure:5` nach Stromausfall auf NAS

Ein Hinweis zu Image-Tags: wordpress:latest folgt automatisch neuen WordPress-Releases. Wer reproduzierbare Deployments bevorzugt, pinnt auf einen versionierten Tag wie wordpress:7.0.0-php8.4-apache. Für MariaDB gilt: Die alten MYSQL_*-Variablen, die ältere Anleitungen noch zeigen, funktionieren zwar noch als Legacy-Aliase, sind aber seit MariaDB 10.5+ offiziell deprecated – die MARIADB_*-Variablen sind der korrekte Weg.

Verifizieren: Klicke nach dem Einfügen auf „Weiter" und dann „Fertig". Im Container Manager sollten jetzt zwei Container erscheinen: wordpress-db und wordpress-app, beide mit Status „Wird ausgeführt" (grünes Symbol). Falls wordpress-db sofort stoppt, prüfe die Compose-Syntax auf Einrückungsfehler.

Schritt 3: Datenbankverbindung und WordPress-Installer prüfen

Nach dem Start der Container wartest du 20 bis 30 Sekunden, bis MariaDB vollständig initialisiert ist. Das liegt daran, dass depends_on in Compose nur prüft, ob der Container läuft – nicht ob MariaDB tatsächlich Verbindungen akzeptiert. Rufst du die Seite zu früh auf, erscheint kurzzeitig „Error establishing a database connection" – ein einfaches Neuladen nach der Wartezeit behebt das.

Öffne im Browser:

http://<NAS-IP>:8080

Du solltest die WordPress-Sprachauswahl sehen, gefolgt von der Installer-Seite mit Feldern für Seitenname, Admin-Benutzername und E-Mail-Adresse. Fülle die Felder aus und schließe die Installation ab.

Verifizieren: Nach dem Abschluss des Installers gelangst du zum WordPress-Admin-Dashboard unter http://<NAS-IP>:8080/wp-admin/. Im linken Menü siehst du den Seitennamen und in der Statusleiste oben rechts deinen Admin-Benutzernamen. Falls der Installer nicht erscheint, prüfe per SSH den Container-Log auf Fehler:

docker logs wordpress-app --tail 30

Schritt 4: Reverse Proxy und HTTPS einrichten

Damit WordPress unter einer eigenen Domain per HTTPS erreichbar ist, richtest du im DSM einen Reverse-Proxy-Eintrag ein. Öffne Systemsteuerung > Anmeldeportal > Reverser Proxy und klicke auf Erstellen.

Quellenprotokoll: HTTPS, Port 443, deine Domain (z. B. blog.meine-domain.de)
Zielprotokoll: HTTP, Ziel-Host localhost, Zielport 8080

Wichtig: Wechsle zum Tab Benutzerdefinierte Kopfzeile und füge folgende Header hinzu:

X-Forwarded-Proto   $scheme
X-Forwarded-Host    $host

Ohne den X-Forwarded-Proto: https-Header generiert WordPress seine URLs intern als HTTP, obwohl der Browser HTTPS nutzt – das führt zu Mixed-Content-Fehlern und Redirect-Schleifen.

Damit WordPress seine eigene URL korrekt kennt, fügst du in der Compose-Datei unter wordpress > environment folgende Variable hinzu und deployst das Projekt neu:

WORDPRESS_CONFIG_EXTRA: |
  define('WP_HOME','https://blog.meine-domain.de');
  define('WP_SITEURL','https://blog.meine-domain.de');
  define('FORCE_SSL_ADMIN', true);

WORDPRESS_CONFIG_EXTRA schreibt beliebige PHP-Konfigurationszeilen in die wp-config.php, ohne dass du die Datei manuell editieren musst. Änderungen bleiben auch nach Image-Updates erhalten, solange das Volume gemountet ist.

Verifizieren: Rufe https://blog.meine-domain.de auf. Das Schloss-Symbol im Browser muss grün sein. Klicke auf eine Unterseite – die URL muss weiterhin https:// zeigen. Falls du eine Redirect-Schleife erhältst, fehlen die benutzerdefinierten Kopfzeilen im Reverse-Proxy-Eintrag.

Schritt 5: Permalink-Test und .htaccess

Nach der Domain-Konfiguration musst du WordPress einmalig die .htaccess-Datei neu schreiben lassen. Ohne diese Datei liefern alle Unterseiten außer der Startseite einen 404-Fehler.

Melde dich im WordPress-Admin an und navigiere zu Einstellungen > Permalinks. Wähle ein Permalink-Muster (z. B. „Beitragsname") und klicke auf Änderungen speichern. WordPress schreibt dabei die .htaccess im Volume-Pfad /volume1/docker/wordpress/html/ neu. Das offizielle Apache-Image hat AllowOverride All bereits aktiviert, sodass keine weitere Apache-Konfiguration nötig ist.

Verifizieren: Erstelle im WordPress-Admin unter Beiträge > Erstellen einen Test-Beitrag und veröffentliche ihn. Rufe die URL des Beitrags im Browser auf – du solltest den Beitrag sehen, nicht eine 404-Seite. Prüfe außerdem, ob die .htaccess-Datei existiert:

ls -la /volume1/docker/wordpress/html/.htaccess

Schritt 6: Berechtigungen prüfen und ggf. korrigieren

Wenn du Plugins oder Themes über das WordPress-Admin-Dashboard installieren möchtest, muss der Container-Prozess (www-data, UID 33) auf das Volume-Verzeichnis schreiben können. Synology-eigene Benutzer haben typischerweise UID 1026+, sodass es nach dem Anlegen der Ordner per File Station zu Berechtigungsproblemen kommen kann.

Aktiviere SSH und verbinde dich mit dem NAS (Schritt-für-Schritt: SSH auf dem Synology NAS aktivieren und verbinden), dann führe aus:

sudo chown -R 33:33 /volume1/docker/wordpress/html
sudo chmod -R 755 /volume1/docker/wordpress/html

Den db-Ordner musst du nicht anfassen – MariaDB setzt die Berechtigungen beim ersten Start selbst.

Verifizieren: Navigiere im WordPress-Admin zu Design > Themes und klicke auf Neues Theme hinzufügen. Installiere ein beliebiges kostenloses Theme aus dem Verzeichnis. Schlägt die Installation fehl, prüfe mit folgendem Befehl, ob Besitzer 33 eingetragen ist:

ls -la /volume1/docker/wordpress/html/wp-content/

Schritt 7 (optional): Staging-Umgebung parallel betreiben

Einer der großen Vorteile des Container-Ansatzes ist, dass du eine zweite WordPress-Instanz als Staging-Umgebung neben der Produktivinstanz betreiben kannst – ohne zusätzliche Hardware. Lege dafür ein zweites Container-Manager-Projekt an, z. B. mit dem Namen wordpress-staging, Pfad /volume1/docker/wordpress-staging.

Die Staging-Compose-Datei unterscheidet sich in drei wesentlichen Punkten von der Produktivkonfiguration:

services:
  db:
    image: mariadb:lts
    container_name: wordpress-staging-db
    restart: always
    environment:
      MARIADB_DATABASE: wordpress_staging_db
      MARIADB_USER: wp_staging
      MARIADB_PASSWORD: anderes_passwort
      MARIADB_ROOT_PASSWORD: anderes_root_passwort
      TZ: Europe/Berlin
    volumes:
      - /volume1/docker/wordpress-staging/db:/var/lib/mysql
    networks:
      - wordpress_staging_net

  wordpress:
    image: wordpress:latest
    container_name: wordpress-staging-app
    restart: always
    depends_on:
      - db
    ports:
      - "8081:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp_staging
      WORDPRESS_DB_PASSWORD: anderes_passwort
      WORDPRESS_DB_NAME: wordpress_staging_db
      WORDPRESS_TABLE_PREFIX: stg_
      WORDPRESS_DEBUG: "1"
      TZ: Europe/Berlin
    volumes:
      - /volume1/docker/wordpress-staging/html:/var/www/html
    networks:
      - wordpress_staging_net

networks:
  wordpress_staging_net:
    driver: bridge

Die wichtigsten Unterschiede: anderer externer Port (8081), andere Volume-Pfade (wordpress-staging/), anderer Datenbankname und Benutzer, eigenes Bridge-Netzwerk sowie WORDPRESS_DEBUG: "1" für detaillierte Fehlermeldungen. Im DSM-Reverse-Proxy legst du einen weiteren Eintrag an, der eine Staging-Subdomain (z. B. staging.meine-domain.de) auf Port 8081 weiterleitet.

Für zuverlässiges Cron-Verhalten in beiden Instanzen empfiehlt es sich, den Standard-WP-Cron zu deaktivieren und stattdessen einen echten Cronjob über den Synology Aufgabenplaner einzurichten – wie das geht, zeigt die Anleitung WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen.

Verifizieren: Rufe http://<NAS-IP>:8081 auf. Du solltest den WordPress-Installer der Staging-Instanz sehen. Im Container Manager laufen jetzt vier Container: wordpress-db, wordpress-app, wordpress-staging-db und wordpress-staging-app.

Troubleshooting / Typische Fehler

„Error establishing a database connection" beim ersten Aufruf: MariaDB ist noch nicht vollständig gestartet. depends_on wartet nur auf den Container-Start, nicht auf die Datenbankbereitschaft. Warte 20–30 Sekunden und lade die Seite neu. Tritt der Fehler dauerhaft auf, prüfe mit docker logs wordpress-db --tail 20, ob die Initialisierung erfolgreich war.
MariaDB-Daten werden nicht initialisiert: Das db-Verzeichnis enthielt bereits Dateien von einem fehlgeschlagenen Versuch. MariaDB initialisiert nur bei komplett leerem Verzeichnis. Container stoppen, /volume1/docker/wordpress/db leeren (alle Dateien löschen, nicht den Ordner selbst), Container neu starten.
Mixed-Content-Fehler oder Redirect-Schleife hinter Reverse Proxy: Der X-Forwarded-Proto-Header fehlt im DSM-Reverse-Proxy-Eintrag oder WP_HOME/WP_SITEURL sind noch auf HTTP gesetzt. Beides wie in Schritt 4 beschrieben korrigieren.
404-Fehler auf allen Unterseiten außer Startseite: Die .htaccess-Datei fehlt oder ist leer. Im WordPress-Admin unter Einstellungen > Permalinks einmal auf „Änderungen speichern" klicken.
Plugin-/Theme-Installation schlägt fehl (Schreibrechte): UID-Mismatch zwischen Host-Ordner und Container-Prozess. Per SSH sudo chown -R 33:33 /volume1/docker/wordpress/html ausführen (siehe Schritt 6).
PHP-Upload-Limit zu niedrig: Im WordPress-Admin erscheint eine Warnung zum Upload-Limit. Prüfe, ob die php-uploads.ini korrekt als Volume eingebunden ist, und starte den wordpress-app-Container neu.
WP-Cron löst nicht aus: Bei wenig Traffic werden Cron-Jobs nicht zuverlässig ausgeführt. WORDPRESS_CONFIG_EXTRA mit define('DISABLE_WP_CRON', true); erweitern und einen echten Cron über den Synology Aufgabenplaner einrichten.

Häufige Fragen

Welche WordPress-Version steckt hinter `wordpress:latest`?

Aktuell (Stand Juni 2026) ist es WordPress 7.0.0 mit PHP 8.3 und Apache. Das Tag latest wird bei jedem neuen WordPress-Release automatisch weitergezogen. Für reproduzierbare Deployments – etwa in einer Staging-Umgebung, die du mit einem Produktiv-Stand vergleichen willst – ist ein versionierter Tag wie wordpress:7.0.0-php8.4-apache die bessere Wahl.

Gehen meine Daten verloren, wenn ich den Container neu starte oder das Image aktualisiere?

Nein – solange beide Volumes korrekt gemountet sind. /volume1/docker/wordpress/html enthält die gesamte WordPress-Installation inklusive aller Themes, Plugins und Uploads. /volume1/docker/wordpress/db speichert alle MariaDB-Datenbankdateien. Ein docker pull gefolgt vom Neustart des Projekts bringt die neue Image-Version, ohne Daten zu berühren.

Kann ich MariaDB durch MySQL ersetzen?

Ja. Alle WORDPRESS_DB_*-Variablen funktionieren identisch mit dem offiziellen MySQL-Image (mysql:8.0). Für Synology-NAS-Betrieb ist MariaDB jedoch die häufigere Wahl, weil es breite ARM-Unterstützung bietet und auch von anderen DSM-Paketen genutzt wird.

Muss ich phpMyAdmin installieren, um die Datenbank zu verwalten?

Nein. Du kannst die Datenbank direkt per SSH verwalten: docker exec -it wordpress-db mariadb -u root -p. Alternativ bietet der Container Manager einen einfachen DB-Manager. phpMyAdmin als zusätzlicher Container ist möglich, aber ein separates optionales Setup.

Wie debugge ich WordPress-Fehler im Container?

Setze WORDPRESS_DEBUG: "1" als Umgebungsvariable. Damit Logs in eine Datei geschrieben werden, füge via WORDPRESS_CONFIG_EXTRA noch define('WP_DEBUG_LOG', true); hinzu. Die Logdatei findest du dann unter /volume1/docker/wordpress/html/wp-content/debug.log. Eine ausführliche Anleitung liefert WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler selbst beheben.

Wie sichere ich Passwörter statt Klartext in der Compose-Datei?

Das offizielle WordPress-Image unterstützt das Suffix _FILE bei allen Passwort-Variablen, z. B. WORDPRESS_DB_PASSWORD_FILE=/run/secrets/db-pass. Damit kannst du Passwörter als Docker Secrets einbinden, ohne sie im Klartext in der compose.yaml zu hinterlegen. Für einen ersten Testaufbau ist Klartext akzeptabel; für dauerhaften Produktivbetrieb sind Secrets die sicherere Wahl.

Fazit

WordPress auf dem Synology NAS per Docker Compose aufzusetzen dauert etwa 30 Minuten und bringt dir eine vollständig selbst kontrollierte Umgebung: keine Abhängigkeit von Hosting-Anbietern, persistente Daten auf eigenem Speicher, saubere HTTPS-Terminierung über den DSM-Reverse-Proxy. Der entscheidende Vorteil gegenüber klassischem Shared Hosting ist die Flexibilität – du kannst in wenigen Minuten eine parallele Staging-Instanz hochziehen, Themes und Plugins gefahrlos testen und bei einem Problem einfach den Container zurückrollen. Wer mehrere Self-Hosting-Dienste auf dem NAS betreibt, findet in Matomo eine sinnvolle Ergänzung: Matomo auf dem Synology NAS installieren: DSGVO-konforme Webanalyse zeigt, wie du Website-Statistiken ohne Datenweitergabe an Dritte erhebst.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: WordPress Official Docker Image – Docker Hub | MariaDB Official Docker Image – Docker Hub | Synology Container Manager Project-Funktion – Knowledge Center