WordPress mit Docker und Composer installieren: modernes Entwicklungssetup für 2026

Die WordPress-Entwicklung ist über FTP-Uploads und Shared-Hosting-Panels hinausgewachsen. Im Jahr 2026 behandeln professionelle Teams WordPress wie jedes andere Softwareprojekt, mit versionierten Abhängigkeiten, containerisierten Umgebungen und automatisierten Deployment-Prozesse. Wenn Sie immer noch Dateien direkt auf einem Live-Server bearbeiten, wird diese Anleitung Ihre Arbeitsweise verändern.

Dieses Tutorial behandelt zwei komplementäre Ansätze für die moderne WordPress-Entwicklung: Docker Compose für reproduzierbare Serverumgebungen und Composer mit Bedrock für die Abhaengigkeitsverwaltung. Sie erhalten vollständige, kopierfertige Konfigurationsdateien, Xdebug-Setup für professionelles PHP-Debugging und einen Deployment-Workflow, der Ihren Code sicher von der lokalen Maschine in die Produktion bringt.

#Warum Docker für die WordPress-Entwicklung

Der klassische Ansatz, eine ZIP-Datei von wordpress.org herunterzuladen und per FTP hochzuladen, schafft mehrere Probleme, die sich mit der Zeit verstärken:

• Umgebungsabweichung - Ihr lokales MAMP- oder XAMPP-Setup stimmt nie genau mit dem Produktionsserver überein, was zu “funktioniert auf meinem Rechner”-Fehlern führt.
• Kein Abhaengigkeits-Tracking - Plugins und Themes werden manuell heruntergeladen und aktualisiert, was es unmöglich macht, genau dieselbe Site auf einer anderen Maschine zu reproduzieren.
• Keine Versionskontrolle für den Core - WordPress-Core-Dateien liegen in Ihrem Repository (oder schlimmer, werden gar nicht getrackt) und vermischen Anwendungscode mit Framework-Code.
• Manuelle Deployments - Das Kopieren von Dateien per FTP ist fehleranfällig und bietet keinen Rollback-Mechanismus.

Docker und Composer lösen jedes dieser Probleme systematisch.

#WordPress mit Docker Compose einrichten

Docker Compose lässt Sie Ihren gesamten Server-Stack in einer einzigen YAML-Datei definieren. Jeder Entwickler im Team erhält genau dieselbe PHP-Version, MySQL-Version und Serverkonfiguration, indem er einen einzigen Befehl ausführt.

#Voraussetzungen

Installieren Sie Docker Desktop für Ihr Betriebssystem. Docker Desktop enthält sowohl die Docker-Engine als auch das docker compose CLI-Plugin. Überprüfen Sie die Installation:

docker --version
docker compose version

#Projektstruktur

Erstellen Sie ein sauberes Projektverzeichnis:

mkdir wordpress-docker && cd wordpress-docker
mkdir -p wp-content/themes wp-content/plugins wp-content/uploads

#Die vollständige docker-compose.yml

Erstellen Sie eine docker-compose.yml-Datei in Ihrem Projektstammverzeichnis:

services:
  db:
    image: mysql:8.0
    container_name: wp_mysql
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: ${DB_NAME:-wordpress}
      MYSQL_USER: ${DB_USER:-wpuser}
      MYSQL_PASSWORD: ${DB_PASSWORD:-wppassword}
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    volumes:
      - db_data:/var/lib/mysql
    ports:
      - "3306:3306"
    networks:
      - wp_network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  wordpress:
    image: wordpress:7.1-php8.3-apache
    container_name: wp_app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME:-wordpress}
      WORDPRESS_DB_USER: ${DB_USER:-wpuser}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-wppassword}
      WORDPRESS_DEBUG: ${WP_DEBUG:-1}
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_DEBUG_LOG', true);
        define('WP_DEBUG_DISPLAY', false);
        define('SCRIPT_DEBUG', true);
        define('DISALLOW_FILE_EDIT', true);
    volumes:
      - ./wp-content/themes:/var/www/html/wp-content/themes
      - ./wp-content/plugins:/var/www/html/wp-content/plugins
      - ./wp-content/uploads:/var/www/html/wp-content/uploads
      - ./php-custom.ini:/usr/local/etc/php/conf.d/custom.ini
    ports:
      - "8080:80"
    networks:
      - wp_network

  phpmyadmin:
    image: phpmyadmin:5
    container_name: wp_phpmyadmin
    restart: unless-stopped
    depends_on:
      - db
    environment:
      PMA_HOST: db
      PMA_PORT: 3306
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    ports:
      - "8081:80"
    networks:
      - wp_network

  mailhog:
    image: mailhog/mailhog:latest
    container_name: wp_mailhog
    ports:
      - "1025:1025"
      - "8025:8025"
    networks:
      - wp_network

volumes:
  db_data:

networks:
  wp_network:
    driver: bridge

Diese Konfiguration bietet Ihnen vier Services:

• MySQL 8.0 mit Health-Check, damit WordPress auf die Bereitschaft der Datenbank wartet, bevor es startet.
• WordPress 7.1 auf PHP 8.3 mit Apache, wobei nur Ihre eigenen Themes, Plugins und Uploads gemountet werden.
• phpMyAdmin für die visuelle Datenbankverwaltung unter http://localhost:8081.
• MailHog zum Abfangen ausgehender E-Mails während der Entwicklung unter http://localhost:8025.

#Umgebungsvariablen mit .env

Erstellen Sie eine .env-Datei im Projektstammverzeichnis:

# Datenbank
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_ROOT_PASSWORD=secure_root_password_2026

# WordPress
WP_DEBUG=1

# Website
SITE_URL=http://localhost:8080

Docker Compose liest automatisch .env-Dateien aus dem Projektverzeichnis. Fügen Sie .env sofort zu Ihrer .gitignore hinzu und committen Sie stattdessen eine .env.example-Vorlage.

#Datenbankpasswörter in Compose-Secrets ablegen

Die .env-Datei oben übergibt Passwörter als Umgebungsvariablen. Die Docker-Dokumentation zu Secrets in Compose weist darauf hin, dass Umgebungsvariablen oft für jeden Prozess im Container sichtbar sind und beim Debuggen in Logs landen können. Ein Compose-Secret wird als Datei unter /run/secrets/<secret_name> eingebunden, und nur die Services, die es aufführen, können es lesen.

Das offizielle WordPress-Image auf Docker Hub liest solche Dateien, wenn Sie an einen Variablennamen _FILE anhängen. Die Dokumentation nennt dafür Datenbank-Host, Benutzer, Passwort und Name, die acht Authentifizierungsschlüssel und Salts, WORDPRESS_TABLE_PREFIX und WORDPRESS_DEBUG. Das MySQL-Image folgt derselben Konvention:

services:
  db:
    environment:
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
    secrets:
      - db_password
      - db_root_password

  wordpress:
    environment:
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt
  db_root_password:
    file: ./secrets/db_root_password.txt

Die _FILE-Variable ersetzt die einfache Variable im selben Service, entfernen Sie also MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD und WORDPRESS_DB_PASSWORD aus diesen Services. Das Verzeichnis secrets/ gehört wie .env nicht ins Git-Repository. Docker nennt eine Grenze: Compose-Secrets funktionieren nur in Linux-Containern, weil jedes Secret als einzelne Datei per Bind-Mount eingebunden wird.

#Benutzerdefinierte PHP-Konfiguration

Erstellen Sie php-custom.ini für entwicklungsfreundliche PHP-Einstellungen:

upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 512M
max_execution_time = 300
max_input_vars = 3000
display_errors = On
error_reporting = E_ALL

#Umgebung starten

docker compose up -d

Öffnen Sie http://localhost:8080 und schließen Sie die WordPress-Installation ab. Ihre Themes- und Plugins-Verzeichnisse werden vom Host-System gemountet, sodass alle Änderungen in Ihrem Editor sofort in der laufenden WordPress-Instanz erscheinen.

#WP-CLI-Container mit dem Image wordpress:cli hinzufügen

Die Apache-Variante des WordPress-Images enthält keinen wp-Befehl, deshalb laufen die WP-CLI-Aufrufe in dieser Anleitung über einen eigenen Service wpcli. Docker Hub veröffentlicht dafür eine cli-Variante desselben Images, als wordpress:cli und mit fester PHP-Version wie wordpress:cli-php8.3. Fügen Sie sie unter services: ein:

  wpcli:
    image: wordpress:cli-php8.3
    user: "33:33"
    profiles: ["tools"]
    depends_on:
      - db
      - wordpress
    volumes_from:
      - wordpress
    environment:
      HOME: /tmp
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME:-wordpress}
      WORDPRESS_DB_USER: ${DB_USER:-wpuser}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-wppassword}
    networks:
      - wp_network

Die Zeile user erklärt die Image-Dokumentation. Die cli-Varianten basieren auf Alpine, wo www-data die UID 82 hat, während die Debian-basierten WordPress-Images als UID 33 laufen. Ohne user: "33:33" gehören Dateien, die WP-CLI anlegt, einem Benutzer, den der Webserver nicht kennt. Dieselbe Dokumentation empfiehlt HOME=/tmp für Befehle, die nach ~/.wp-cli schreiben wollen. volumes_from bindet die Dateien des Service wordpress ein, und mit den Datenbankvariablen kann die gemeinsame wp-config.php die Verbindung aufbauen.

Der Eintrag profiles verhindert, dass docker compose up -d den Container startet. Laut Compose-Dokumentation zu Profilen läuft ein ausdrücklich angesprochener Service unabhängig davon, ob sein Profil aktiv ist, daher funktioniert docker compose run --rm wpcli wp plugin list ohne weitere Flags. Einen breiteren Überblick über Container in der WordPress-Arbeit gibt unser Leitfaden zu Docker für die WordPress-Entwicklung.

#Nützliche Docker-Befehle für den Arbeitsalltag

# Logs aller Container anzeigen
docker compose logs -f

# Nur WordPress-Logs anzeigen
docker compose logs -f wordpress

# Shell im WordPress-Container öffnen
docker compose exec wordpress bash

# WP-CLI-Befehle im Container ausfuehren
docker compose run --rm wpcli wp plugin list

# Alle Container stoppen (Daten bleiben erhalten)
docker compose stop

# Container stoppen und entfernen (Volume-Daten bleiben erhalten)
docker compose down

# Vollstaendiger Reset inklusive Datenbank
docker compose down -v

#WordPress mit Composer und Bedrock verwalten

Während Docker die Serverumgebung verwaltet, strukturiert Bedrock von Roots WordPress selbst in eine ordnungsgemaess Composer-verwaltete Anwendung um. Bedrock behandelt den WordPress-Core als Abhängigkeit, nicht als Projektstammverzeichnis, was alles an der Verwaltung und dem Deployment von WordPress verändert.

#Was ist Bedrock und wozu dient es

Standard-WordPress vermischt Anwendungscode (Ihr Theme, Plugins) mit Framework-Code (wp-admin, wp-includes) im selben Verzeichnis. Bedrock trennt diese Belange:

project-root/
  config/              # Umgebungsspezifische Konfiguration
    application.php
    environments/
      development.php
      staging.php
      production.php
  web/                 # Document Root (öffentlich)
    app/               # wp-content-Aequivalent
      themes/
      plugins/
      uploads/
    wp/                # WordPress-Core (Composer-verwaltet)
    wp-config.php      # Minimaler Loader
  vendor/              # Composer-Abhaengigkeiten
  .env                 # Umgebungsvariablen
  composer.json        # Abhaengigkeitsmanifest

Der WordPress-Core befindet sich in web/wp/ und wird nie modifiziert. Ihr eigener Code befindet sich in web/app/. Das vendor/-Verzeichnis und web/wp/ werden beide gitignored, da Composer sie aus composer.json neu erstellt.

#Bedrock installieren

composer create-project roots/bedrock my-wordpress-project
cd my-wordpress-project

#Die composer.json-Struktur

Bedrock’s composer.json verwaltet WordPress-Core, Plugins und Themes als Pakete:

{
  "name": "your-agency/client-project",
  "type": "project",
  "license": "MIT",
  "description": "WordPress project managed with Bedrock and Composer",
  "require": {
    "php": ">=8.3",
    "composer/installers": "^2.3",
    "vlucas/phpdotenv": "^5.6",
    "oscarotero/env": "^2.1",
    "roots/bedrock-autoloader": "^1.0",
    "roots/bedrock-disallow-indexing": "^2.0",
    "roots/wordpress": "7.1.*",
    "roots/wp-config": "1.0.0",
    "wpackagist-plugin/wordpress-seo": "^23.0",
    "wpackagist-plugin/wp-super-cache": "^1.12",
    "wpackagist-plugin/wordfence": "^7.11"
  },
  "require-dev": {
    "squizlabs/php_codesniffer": "^3.10",
    "roave/security-advisories": "dev-latest"
  },
  "config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "allow-plugins": {
      "composer/installers": true,
      "roots/wordpress-core-installer": true
    }
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": [
        "wpackagist-plugin/*",
        "wpackagist-theme/*"
      ]
    }
  ],
  "extra": {
    "installer-paths": {
      "web/app/mu-plugins/{$name}/": [
        "type:wordpress-muplugin"
      ],
      "web/app/plugins/{$name}/": [
        "type:wordpress-plugin"
      ],
      "web/app/themes/{$name}/": [
        "type:wordpress-theme"
      ]
    },
    "wordpress-install-dir": "web/wp"
  }
}

Die entscheidende Erkenntnis: WordPress Packagist spiegelt das gesamte WordPress.org-Plugin- und Theme-Repository als Composer-Pakete wider. Ein Plugin hinzuzufügen ist so einfach wie:

composer require wpackagist-plugin/advanced-custom-fields

Das Entfernen ist genauso sauber:

composer remove wpackagist-plugin/advanced-custom-fields

#composer.lock committen und mit composer install deployen

composer.json enthält Versionsbereiche wie ^23.0, composer.lock hält die exakten Versionen fest, die Composer aufgelöst hat. Die Composer-Dokumentation zur Grundnutzung empfiehlt, die Lock-Datei ins Projekt-Repository zu committen, weil dann jeder, der das Projekt aufsetzt, dieselben Abhängigkeitsversionen verwendet. Liegt eine Lock-Datei vor, installiert composer install genau das, was darin steht. composer update ist der Befehl, der neuere passende Versionen holt und die Lock-Datei neu schreibt.

In einem WordPress-Projekt führen Sie composer update lokal aus, oder composer update wpackagist-plugin/wordpress-seo für ein einzelnes Plugin, testen das Ergebnis in Docker, committen die geänderte composer.lock und lassen die Pipeline composer install ausführen, wie im GitHub-Actions-Beispiel unten. Ein Plugin-Update wird so zu einem Diff, den man prüfen kann, statt zu einem Klick in wp-admin auf der Live-Seite.

Die WPackagist-Seite gibt an, dass der Dienst das Subversion-Repository von WordPress.org stündlich durchsucht und Tags auf Versionen abbildet, ein neues Plugin-Release kann dort also bis zu eine Stunde später erscheinen. Für Plugins wird außerdem trunk als Entwicklungsversion (dev-trunk) angeboten, die unveröffentlichten Code verfolgt und nicht in eine Produktions-Lock-Datei gehört. Dieselbe Seite vermerkt, dass WPackagist inzwischen von WP Engine betreut wird.

#Bedrock-Umgebungskonfiguration

Bedrock verwendet .env-Dateien anstelle von hartkodierten Werten in wp-config.php:

# .env-Datei für Bedrock
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_HOST=db:3306
DB_PREFIX=wp_

WP_ENV=development
WP_HOME=http://localhost:8080
WP_SITEURL=${WP_HOME}/wp

# Generieren Sie diese unter https://roots.io/salts.html
AUTH_KEY='generate-unique-key-here'
SECURE_AUTH_KEY='generate-unique-key-here'
LOGGED_IN_KEY='generate-unique-key-here'
NONCE_KEY='generate-unique-key-here'
AUTH_SALT='generate-unique-salt-here'
SECURE_AUTH_SALT='generate-unique-salt-here'
LOGGED_IN_SALT='generate-unique-salt-here'
NONCE_SALT='generate-unique-salt-here'

Jede Umgebung (Entwicklung, Staging, Produktion) hat ihre eigene .env-Datei auf ihrem jeweiligen Server. Dieselbe Codebasis läuft überall, wobei das Verhalten vollständig durch Umgebungsvariablen gesteuert wird.

#Bedrock in Docker ausführen

Die wahre Stärke zeigt sich beim Betrieb von Bedrock innerhalb von Docker. Ändern Sie die docker-compose.yml, um Ihr Bedrock-Projekt anstelle des Standard-WordPress-Images zu mounten:

services:
  wordpress:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/var/www/html
    environment:
      - WP_ENV=development

Mit einem benutzerdefinierten Dockerfile:

FROM php:8.3-apache

RUN apt-get update && apt-get install -y \
    libzip-dev \
    libpng-dev \
    libjpeg-dev \
    libfreetype6-dev \
    libicu-dev \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install \
    mysqli \
    pdo_mysql \
    zip \
    gd \
    intl \
    opcache

RUN a2enmod rewrite

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

ENV APACHE_DOCUMENT_ROOT /var/www/html/web

RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' \
    /etc/apache2/sites-available/*.conf \
    /etc/apache2/apache2.conf

WORKDIR /var/www/html

Das ergibt eine vollständig containerisierte Bedrock-Umgebung, in der composer install innerhalb des Containers ausgeführt wird und das Document Root auf Bedrock’s web/-Verzeichnis zeigt.

#Xdebug-Setup für PHP-Debugging

Schrittweises Debugging ersetzt var_dump und error_log durch einen richtigen Debugger, der es Ihnen ermöglicht, die Ausführung anzuhalten, Variablen zu inspizieren und Code Zeile für Zeile durchzugehen.

#Xdebug zum Docker-Container hinzufügen

Erstellen Sie eine xdebug.ini-Datei:

[xdebug]
zend_extension=xdebug
xdebug.mode=debug,develop
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.discover_client_host=0
xdebug.log=/tmp/xdebug.log
xdebug.idekey=VSCODE

Fügen Sie die Xdebug-Installation zu Ihrem Dockerfile hinzu:

RUN pecl install xdebug-3.3.2 \
    && docker-php-ext-enable xdebug

COPY xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

#VS Code-Konfiguration

Erstellen Sie .vscode/launch.json in Ihrem Projektstammverzeichnis:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug (Docker)",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/var/www/html": "${workspaceFolder}"
      },
      "log": true
    }
  ]
}

Installieren Sie die PHP Debug-Erweiterung von Xdebug in VS Code, setzen Sie einen Breakpoint in einer beliebigen PHP-Datei, drücken Sie F5 zum Starten des Lauschens und laden Sie Ihre WordPress-Seite neu. Der Debugger hält an Ihrem Breakpoint an.

#PhpStorm-Konfiguration

PhpStorm verarbeitet Docker-Xdebug-Verbindungen nativ:

1. Gehen Sie zu Settings > PHP > Debug und überprüfen Sie, dass Port 9003 eingestellt ist.
2. Gehen Sie zu Settings > PHP > Servers, fügen Sie einen neuen Server mit localhost auf Port 8080 hinzu und konfigurieren Sie das Path-Mapping von /var/www/html zu Ihrem Projektstammverzeichnis.
3. Klicken Sie auf den Button Start Listening for PHP Debug Connections in der Symbolleiste.

#WordPress von lokal über Staging live deployen

#Datenbank-Dump für die Entwicklung anonymisieren

Bei den Projekten, die wir im deutschsprachigen Raum begleiten, steht am Ende der Kette ein eigener Server oder ein spezialisierter WordPress-Hoster, seltener klassisches Shared Hosting.

Damit ist composer install auf dem Ziel möglich, und die eigentliche Frage verschiebt sich zum Datenschutz: eine Kopie der Produktionsdatenbank auf dem Entwicklungsrechner enthält personenbezogene Daten. Anonymisieren Sie den Dump im Pipeline-Schritt, nicht hinterher von Hand, sonst passiert es genau einmal nicht.

Ein professioneller Deployment-Prozess stellt sicher, dass Codeänderungen vorhersagbar von der Entwicklung zur Produktion fließen, ohne manuelles Kopieren von Dateien.

#Das Drei-Umgebungen-Modell

1. Lokal (Docker) - wo Sie Code schreiben und testen.
2. Staging - ein Server, der die Produktion für abschließende Tests spiegelt.
3. Produktion - die Live-Website.

#Git-basiertes Deployment mit GitHub Actions

Ihr Repository sollte Ihren Theme-, Plugin- und Bedrock-Konfigurationscode enthalten. Es sollte nicht den WordPress-Core, vendor/ oder uploads/ enthalten.

Beispiel .github/workflows/deploy.yml:

name: Deploy to staging

on:
  push:
    branches: [staging]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run code quality checks
        run: vendor/bin/phpcs --standard=WordPress web/app/themes/

      - name: Deploy via rsync
        uses: burnett01/[email protected]
        with:
          switches: -avz --delete --exclude='.env' --exclude='web/app/uploads/'
          path: ./
          remote_path: /var/www/staging.example.com/
          remote_host: ${{ secrets.STAGING_HOST }}
          remote_user: ${{ secrets.STAGING_USER }}
          remote_key: ${{ secrets.STAGING_SSH_KEY }}

#Datenbank- und Upload-Synchronisation

Code wird über Git deployt, aber Datenbanken und Medien-Uploads erfordern separate Behandlung:

# Produktionsdatenbank exportieren
wp db export production-backup.sql --ssh=user@production

# Auf Staging importieren
wp db import production-backup.sql --ssh=user@staging

# URLs ersetzen
wp search-replace 'https://example.com' 'https://staging.example.com' --ssh=user@staging

# Uploads von Produktion zu Staging synchronisieren
rsync -avz user@production:/var/www/html/web/app/uploads/ \
  user@staging:/var/www/html/web/app/uploads/

Für die lokale Entwicklung verwenden Sie die WP-CLI-Befehle wp db export und wp db import über Docker:

docker compose run --rm -T wpcli wp db export - > ./backups/backup.sql

#Vergleich: Docker vs Composer vs LocalWP vs MAMP

Die wichtigste Erkenntnis: Docker und Composer sind komplementär, nicht konkurrierend. Docker ersetzt MAMP/XAMPP als Serverumgebung, während Composer die manuelle Plugin-/Theme-Verwaltung ersetzt. LocalWP bleibt eine gültige Wahl für schnelles Prototyping, aber es fehlt ihm die Reproduzierbarkeit und CI/CD-Integration, die professionelle Teams benötigen.

#Performance-Tipps für Docker auf macOS

Docker auf macOS litt historisch unter langsamer Dateisystem-Performance aufgrund der Virtualisierungsschicht. Im Jahr 2026 verwendet Docker Desktop standardmäßig VirtioFS, was die I/O-Geschwindigkeit dramatisch verbessert. Wenn Sie immer noch Langsamkeit erleben:

• Überprüfen Sie, ob VirtioFS in Docker Desktop > Settings > General aktiviert ist.
• Beschränken Sie gemountete Volumes auf das Nötigste (Themes, Plugins, Uploads), nicht die gesamte WordPress-Installation.
• Verwenden Sie bei Bedarf Docker’s eingebaute Caching-Direktiven: volumes: - ./wp-content:/var/www/html/wp-content:cached.
• Weisen Sie ausreichend Ressourcen in Docker Desktop > Settings > Resources zu (mindestens 4 GB RAM und 2 CPUs).

#Lokale WordPress-Docker-Umgebung absichern

Selbst in lokalen Umgebungen sind Sicherheitsgewohnheiten wichtig, da Konfigurationen oft in die Produktion gelangen:

• Committen Sie niemals .env-Dateien in Git. Verwenden Sie .env.example als Vorlage.
• Verwenden Sie starke, einzigartige Passwörter in Ihrer .env auch lokal, damit Sie nie versehentlich schwache Zugangsdaten deployen.
• Halten Sie DISALLOW_FILE_EDIT in allen Umgebungen auf true gesetzt.
• Führen Sie regelmäßig composer audit aus, um bekannte Schwachstellen in Ihren Abhängigkeiten zu prüfen.
• Pinnen Sie spezifische Versionen in composer.json für Produktions-Deployments, anstatt lose Versionseinschraenkungen zu verwenden.

#Häufige WordPress-Docker-Fehler beheben

MySQL-Container beendet sich sofort Überprüfen Sie die Logs mit docker compose logs db. Die häufigste Ursache ist ein vorhandenes Volume mit inkompatiblen Daten. Führen Sie docker compose down -v aus, um Volumes zu entfernen und neu zu beginnen.

WordPress kann keine Verbindung zur Datenbank herstellen Überprüfen Sie, ob der WORDPRESS_DB_HOST-Wert mit dem Servicenamen in docker-compose.yml übereinstimmt (typischerweise db:3306). Stellen Sie sicher, dass der Datenbank-Container gesund ist, bevor WordPress startet, indem Sie die oben gezeigte depends_on-Bedingung verwenden.

Xdebug verbindet sich nicht Bestätigen Sie, dass host.docker.internal innerhalb des Containers korrekt aufgelöst wird. Unter Linux müssen Sie möglicherweise extra_hosts: - "host.docker.internal:host-gateway" zu Ihrer WordPress-Service-Definition hinzufügen.

Dateiberechtigungsfehler Wenn WordPress nicht in wp-content/uploads schreiben kann, passen Sie die Berechtigungen innerhalb des Containers an:

docker compose exec wordpress chown -R www-data:www-data /var/www/html/wp-content/uploads

#Weitere Tools für WordPress mit Docker

Sobald Docker und Composer laufen, sollten Sie diese Ergänzungen in Betracht ziehen, um Ihr Setup weiter zu professionalisieren:

• WP-CLI als Composer-Abhängigkeit für skriptgesteuerte WordPress-Verwaltung.
• PHPStan oder Psalm für statische Analyse Ihres Theme- und Plugin-PHP-Codes.
• GitHub Actions oder GitLab CI für automatisiertes Testen bei jedem Pull Request.
• Redis oder Memcached als zusätzlicher Docker-Service für Object Caching während der Entwicklung.
• Traefik oder Nginx Proxy für die Verwaltung mehrerer lokaler WordPress-Projekte mit benutzerdefinierten Domains anstelle von Portnummern.

Moderne WordPress-Engineering bedeutet, Ihre Website wie ein Softwareprodukt zu behandeln, mit reproduzierbaren Builds, automatisiertem Testen und sicheren Deployments. Die in dieser Anleitung behandelten Tools, Docker Compose für Umgebungen und Composer mit Bedrock für die Abhaengigkeitsverwaltung, bilden das Fundament, das jedes serioeoe WordPress-Team im Jahr 2026 braucht.

Bei wppoland.com bauen und pflegen wir WordPress-Projekte mit genau diesen Workflows. Wenn Ihr Team Hilfe bei der Modernisierung seines WordPress-Entwicklungsprozesses, der Einrichtung von CI/CD-Prozesse oder der Migration von Legacy-Setups zu containerisierten Umgebungen benötigt, steht unser Engineering-Team für Beratung und Implementierung zur Verfügung. Die Preisgestaltung ist immer individuell und hängt vom Umfang Ihres Projekts ab.