Auf einem Synology NAS betreiben Sie WordPress als eigene Website oder als isolierte Staging-Umgebung. Grundlage ist der Container Manager ab DSM 7.2: WordPress läuft zusammen mit MariaDB in einem Docker-Compose-Projekt, die Dateien und die Datenbank liegen in Ordnern auf dem NAS und überstehen Neustarts und Image-Updates. Über den Reverse Proxy von DSM ist die Installation per HTTPS unter Ihrer Domain erreichbar. Die Anleitung richtet sich an kleine Büros und alle, die WordPress auf dem NAS testen oder eine einfache Website betreiben möchten.

Voraussetzungen

Synology NAS mit DSM 7.2 oder neuer, einem Modell mit Container-Manager-Unterstützung (x86-64 oder ARM64, mindestens 2 CPU-Kerne empfohlen) 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 über Systemsteuerung > Sicherheit > Zertifikat)
Starke, einzigartige Passwörter für MARIADB_ROOT_PASSWORD und MARIADB_PASSWORD – vor dem Start festlegen
SSH-Zugriff auf das NAS: nur für die Rechtekorrektur in Schritt 6 nötig, weil DSM die Eigentümer-UID 33 des Containers nicht über die Oberfläche setzen kann

Hardware für diese Anleitung

Enthält Werbelinks

Synology mit Container Manager	Container laufen nur auf Modellen mit Container Manager, vor allem der Plus-Serie. Vor dem Kauf die Kompatibilitätsliste von Synology prüfen. Bei uns läuft eine DS920+.	Synology bei Amazon (Werbelink)
NAS-Festplatten	Für den Dauerbetrieb Platten mit CMR-Technik wählen, für RAID 1 zwei gleich große.	NAS-Platten bei Amazon (Werbelink)
RAM-Erweiterung	Mehrere Container gleichzeitig brauchen Speicher. Viele Plus-Modelle lassen sich aufrüsten, das passende Modul steht im Datenblatt.	Bei Amazon ansehen (Werbelink)

Vorhandene Hardware reicht oft. Die Liste zeigt, worauf es bei einem Neukauf ankommt. * Werbelink

Schritt 1: Ordnerstruktur anlegen

Die Host-Verzeichnisse müssen vor dem Start existieren. Der Container Manager legt sie nicht an, fehlende Ordner verhindern die Initialisierung der Datenbank.

Öffnen Sie die File Station, wechseln Sie zu docker und erstellen Sie 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. Legen Sie zusätzlich eine Upload-Konfiguration an:

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

Inhalt der Datei (am PC erstellen und per File Station hochladen):

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

Damit steigt das PHP-Upload-Limit von 2 MB auf 64 MB, was für Themes und Plugins meist nötig ist. Die Datei muss existieren, bevor das Projekt startet: Fehlt sie, legt Docker an ihrer Stelle einen leeren Ordner an und der Start scheitert.

Verifizieren: Die File Station zeigt unter docker/wordpress die leeren Ordner html und db sowie die Datei php-uploads.ini. Der Ordner db muss beim ersten Start leer sein, sonst initialisiert MariaDB die Datenbank nicht.

Schritt 2: Compose-Projekt im Container Manager anlegen

Öffnen Sie den Container Manager, wechseln Sie zu Projekt und klicken Sie auf Erstellen. Vergeben Sie den Projektnamen wordpress, wählen Sie als Pfad /volume1/docker/wordpress und unter Quelle „compose.yaml erstellen“. Fügen Sie 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

Ersetzen Sie sicheres_passwort und sicheres_root_passwort durch starke, unterschiedliche Passwörter. MARIADB_PASSWORD und WORDPRESS_DB_PASSWORD müssen identisch sein. Fehlt eine der vier WORDPRESS_DB_*-Variablen, scheitert die Datenbankverbindung.

Parameter	Wert	Hinweis
WordPress-Image	`wordpress:latest`	Stand 01.10.2026: WordPress 7.1.2 mit PHP 8.3 und Apache; feste Version z. B. `wordpress:7.1.2-php8.3-apache`
MariaDB-Image	`mariadb:lts`	Stand 01.10.2026: 12.3.3; für die Reihe 11.8 explizit `mariadb:11.8`
Externer Port	`8080`	Im LAN erreichbar; von außen nur über den Reverse Proxy per HTTPS
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

wordpress:latest folgt automatisch neuen WordPress-Releases. Für reproduzierbare Stände schreiben Sie einen versionierten Tag wie wordpress:7.1.2-php8.3-apache fest. Bei MariaDB funktionieren die älteren MYSQL_*-Variablen noch als Aliase, empfohlen sind die MARIADB_*-Variablen.

Verifizieren: Klicken Sie auf „Weiter“ und „Fertig“. Der Container Manager zeigt wordpress-db und wordpress-app mit dem Status „Wird ausgeführt“. Stoppt wordpress-db sofort, prüfen Sie die Einrückung der Compose-Datei und das Protokoll des Containers.

Schritt 3: Datenbankverbindung und WordPress-Installer prüfen

Warten Sie nach dem Start 20 bis 30 Sekunden, bis MariaDB initialisiert ist. depends_on prüft nur, ob der Container läuft, nicht ob die Datenbank Verbindungen annimmt. Zu früh aufgerufen, erscheint kurz „Error establishing a database connection“, Neuladen behebt das.

Öffnen Sie im Browser:

http://<NAS-IP>:8080

Es erscheint die Sprachauswahl, danach die Installer-Seite mit Feldern für Seitenname, Admin-Benutzer und E-Mail-Adresse. Füllen Sie die Felder aus und schließen Sie die Installation ab.

Verifizieren: Nach der Anmeldung zeigt http://<NAS-IP>:8080/wp-admin/ das Dashboard mit Ihrem Admin-Benutzernamen oben rechts. Erscheint der Installer nicht, prüfen Sie im Container Manager unter Container > wordpress-app > Protokoll die Fehlermeldungen oder per SSH:

docker logs wordpress-app --tail 30

Schritt 4: Reverse Proxy und HTTPS einrichten

Für HTTPS unter Ihrer Domain richten Sie im DSM einen Reverse-Proxy-Eintrag ein. Öffnen Sie Systemsteuerung > Anmeldeportal > Erweitert > Reverse Proxy und klicken Sie auf Erstellen.

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

Wechseln Sie zum Tab Benutzerdefinierte Kopfzeile und fügen Sie folgende Header hinzu:

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

Ohne X-Forwarded-Proto erzeugt WordPress HTTP-URLs, obwohl der Browser HTTPS nutzt. Folge sind Mixed-Content-Fehler und Weiterleitungsschleifen.

Damit WordPress seine URL kennt, ergänzen Sie in der Compose-Datei unter wordpress > environment folgende Variable und erstellen 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 fügt die PHP-Zeilen in die wp-config.php ein, ohne dass Sie die Datei bearbeiten. Die Einstellung bleibt auch nach Image-Updates erhalten.

Verifizieren: https://blog.meine-domain.de lädt ohne Zertifikatswarnung, Unterseiten behalten https://. Bei einer Weiterleitungsschleife fehlen die benutzerdefinierten Kopfzeilen im Reverse-Proxy-Eintrag.

Schritt 5: Permalink-Test und .htaccess

Nach der Domain-Konfiguration lassen Sie WordPress die .htaccess einmal neu schreiben. Fehlt sie oder ist sie leer, liefern alle Unterseiten außer der Startseite 404.

Öffnen Sie im WordPress-Admin Einstellungen > Permalinks, wählen Sie ein Muster (z. B. „Beitragsname“) und klicken Sie auf Änderungen speichern. WordPress schreibt dabei die .htaccess im Volume-Pfad /volume1/docker/wordpress/html/ neu. Das offizielle Apache-Image hat mod_rewrite und AllowOverride All bereits aktiviert.

Verifizieren: Veröffentlichen Sie unter Beiträge > Neuer Beitrag einen Testbeitrag und rufen Sie seine URL auf: Der Beitrag erscheint, keine 404-Seite. Die Datei .htaccess existiert:

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

Schritt 6: Berechtigungen prüfen und ggf. korrigieren

Für Plugin- und Theme-Installationen im Dashboard muss der Container-Prozess (www-data, UID 33) in den Ordner schreiben können. Per File Station angelegte Ordner gehören einem DSM-Benutzer (UID meist ab 1026).

Aktivieren Sie SSH und verbinden Sie sich mit dem NAS (Schritt-für-Schritt: SSH auf dem Synology NAS aktivieren und verbinden), dann führen Sie aus:

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

Den Ordner db lassen Sie unverändert, MariaDB setzt die Rechte beim ersten Start selbst.

Verifizieren: Unter Design > Themes > Neues Theme hinzufügen lässt sich ein Theme ohne FTP-Abfrage installieren. Schlägt das fehl, prüfen Sie, ob als Besitzer 33 eingetragen ist:

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

Schritt 7 (optional): Staging-Umgebung parallel betreiben

Eine zweite WordPress-Instanz als Staging-Umgebung läuft ohne zusätzliche Hardware neben der Produktivinstanz. Legen Sie dafür ein zweites Container-Manager-Projekt an, z. B. mit dem Namen wordpress-staging, Pfad /volume1/docker/wordpress-staging.

Die Staging-Compose-Datei:

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 legen Sie einen weiteren Eintrag an, der eine Staging-Subdomain (z. B. staging.meine-domain.de) auf Port 8081 weiterleitet.

Für zuverlässige geplante Aufgaben ersetzen Sie WP-Cron durch einen echten Cronjob im Synology-Aufgabenplaner, siehe WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen.

Verifizieren: http://<NAS-IP>:8081 zeigt den Installer der Staging-Instanz. Im Container Manager laufen 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. 20 bis 30 Sekunden warten und neu laden. Bleibt der Fehler, mit docker logs wordpress-db --tail 20, die Initialisierung prüfen und die Passwörter in beiden Services vergleichen.
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üfen, ob die php-uploads.ini als Datei (nicht als Ordner) eingebunden ist, dann wordpress-app neu starten.
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`?

Stand 01.10.2026 ist es WordPress 7.1.2 mit PHP 8.3 und Apache. Das Tag wandert mit jedem Release weiter. Für reproduzierbare Stände, etwa beim Vergleich von Staging und Produktion, schreiben Sie einen Tag wie wordpress:7.1.2-php8.3-apache fest.

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

Nein, solange beide Ordner eingebunden 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 Abruf des neuen Images mit anschließendem Neuaufbau des Projekts lässt die Daten unberührt.

Kann ich MariaDB durch MySQL ersetzen?

Ja. Alle WORDPRESS_DB_*-Variablen funktionieren identisch mit dem offiziellen MySQL-Image (mysql:8.0). Auf dem NAS ist MariaDB üblich, weil Synology es auch als eigenes DSM-Paket anbietet.

Muss ich phpMyAdmin installieren, um die Datenbank zu verwalten?

Nein. Per SSH verwalten Sie die Datenbank direkt: docker exec -it wordpress-db mariadb -u root -p. phpMyAdmin oder Adminer lassen sich bei Bedarf als zusätzlicher Container ergänzen.

Wie debugge ich WordPress-Fehler im Container?

Setzen Sie WORDPRESS_DEBUG: "1". Für eine Logdatei ergänzen Sie in WORDPRESS_CONFIG_EXTRA define('WP_DEBUG_LOG', true);. Das Log liegt dann unter /volume1/docker/wordpress/html/wp-content/debug.log. Details zeigt 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 binden Sie Passwörter als Docker Secrets ein statt im Klartext in der compose.yaml. Für einen Testaufbau ist Klartext vertretbar, für den Dauerbetrieb nicht.

Fazit

In etwa 30 Minuten steht WordPress auf dem Synology NAS: Daten auf eigenem Speicher, HTTPS über den DSM-Reverse-Proxy. Gegenüber Shared Hosting gewinnen Sie Flexibilität, etwa eine parallele Staging-Instanz für Tests von Themes und Plugins. Bedenken Sie, dass die Website dann von der Verfügbarkeit Ihres NAS und Ihres Internetanschlusses abhängt und die Ordner html und db in Ihre NAS-Datensicherung gehören. Für Besucherstatistiken ohne Datenweitergabe an Dritte eignet sich Matomo auf dem Synology NAS.

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