Shopware Docker: Setup, Vergleich, Produktion

Was ist Shopware Docker?

Shopware Docker ist die containerisierte Variante des Shopware-Shopsystems, bei der die gesamte Anwendung inklusive PHP, Webserver und Datenbank in isolierten Docker-Containern läuft. Reproduzierbar, portabel und unabhängig vom Host-System. Jeder Container verhält sich identisch, egal ob auf dem Laptop eines Entwicklers, einem Staging-Server oder in der Produktionsumgebung.

Der Unterschied zu klassischen Server-Setups: Bei Docker beschreibt eine einzige Konfigurationsdatei (docker-compose.yml) die gesamte Infrastruktur. PHP-Version, Datenbankserver, Webserver, Caching. Alles versioniert, alles wiederholbar. Bei einem klassischen LAMP-Stack dagegen konfiguriert jeder Admin den Server manuell. Abweichungen zwischen Entwicklung und Produktion sind die Regel, nicht die Ausnahme.

Shopware 6 eignet sich besonders gut für Docker, weil das Framework auf Symfony basiert und alle Abhängigkeiten über Composer verwaltet. Laut dem Docker State of Application Development Report 2025 nutzen Stand 2025 bereits 92% aller IT-Fachkräfte Docker in ihren Workflows. Scott Johnston, CEO von Docker, fasst es so zusammen: "Docker has evolved from a developer tool to the backbone of modern application delivery." Im Shopware-Ökosystem hat sich Docker seit der Veröffentlichung des offiziellen Docker Images auf GitHub (Version 0.3.0, Februar 2025) als Standard-Deployment-Methode etabliert.

Wann lohnt sich Docker für Shopware?

Docker lohnt sich für Shopware-Shops ab dem Moment, wo mehrere Entwickler parallel arbeiten, identische Entwicklungs- und Produktionsumgebungen nötig sind oder schnelle Skalierung bei Traffic-Spitzen gefordert wird. Für einen einzelnen Shop ohne eigenes Dev-Team ist klassisches Managed Hosting oft die bessere Wahl.

Drei typische Szenarien, in denen Docker den Unterschied macht. Erstens: Eine Agentur betreut acht Shopware-Projekte gleichzeitig. Ohne Docker installiert jeder Shopware Entwickler PHP, MySQL und Elasticsearch manuell. Mit Docker klont er das Repository, tippt `docker compose up` und arbeitet nach 2 Minuten in einer identischen Umgebung. Zweitens: Ein Shop mit saisonalen Spitzen (Black Friday, Weihnachten) skaliert per Docker Swarm oder Kubernetes horizontal, statt den Server dauerhaft überzudimensionieren. Drittens: CI/CD-Pipelines brauchen reproduzierbare Build-Umgebungen. Docker liefert das ab Werk.

Ich halte Docker für überdimensioniert, wenn ein Shop unter 1.000 Bestellungen pro Monat verarbeitet und kein eigenes Entwicklerteam hat. In dem Fall spart Shopware Managed Hosting Zeit und Nerven. Für alles darüber ist Docker die technisch überlegene Lösung.

Docker-Optionen im Vergleich

Für Shopware gibt es drei gängige Docker-Ansätze: das offizielle Shopware Docker Image (produktionsoptimiert), Dockware (entwicklungsorientiert mit vorinstallierten Tools) und individuelle Docker-Compose-Setups auf Basis des Flex-Templates. Jeder Ansatz hat ein klar definiertes Einsatzgebiet.

Meine Empfehlung: Nutze Dockware für lokale Entwicklung und Testing. Schneller Einstieg, alle Tools vorinstalliert, Shopware läuft nach einem einzigen Befehl. Für Produktion und Staging das offizielle Image. Es läuft ohne Root-Rechte, basiert auf Alpine (kleiner Footprint) und ist für Production-Workloads konzipiert.

Shopware Docker einrichten - Schritt für Schritt

Die Einrichtung von Shopware mit dem offiziellen Docker Image dauert unter 10 Minuten: Docker installieren, docker-compose.yml erstellen, Container starten und Shopware über den Browser konfigurieren. Die folgende Anleitung nutzt Dockware für den schnellen Einstieg und das offizielle Image für produktionsnahe Setups.

Voraussetzungen

Shopware 6.7 (Stand Mai 2026) setzt PHP 8.2, 8.3 oder 8.4 voraus. Für Docker brauchst du Docker Engine 24+ oder Docker Desktop (macOS/Windows). Laut Shopware Systemanforderungen sind mindestens 4 GB RAM für den Docker-Host empfohlen, 8 GB für komfortables Arbeiten mit Xdebug und Elasticsearch. Dazu MySQL 8.0+ oder MariaDB 10.11+ als Datenbankserver, die im Container mitlaufen. Details zu Hardware und PHP-Extensions findest du im Shopware Server Anforderungen Guide.

Quick-Start mit Dockware (Entwicklung)

Für lokale Entwicklung ist Dockware der schnellste Weg. Ein Befehl, Shopware läuft. Erstelle eine Datei `docker-compose.yml` in deinem Projektordner:

# Shopware 6.6 Entwicklungsumgebung mit Dockware
# Stand: Mai 2026 | PHP 8.3 | Xdebug aktiv
services:
  shopware:
    image: dockware/dev:6.6.10.1
    container_name: shopware-dev
    ports:
      - "80:80"        # Storefront
      - "8888:8888"    # Adminer (DB-Zugriff)
      - "9998:9998"    # Mailcatcher
      - "9999:9999"    # Xdebug
    volumes:
      - ./src:/var/www/html/custom/plugins
    environment:
      - XDEBUG_ENABLED=1
      - PHP_VERSION=8.3
    networks:
      - shopware-net

networks:
  shopware-net:

Starte die Umgebung mit `docker compose up -d`. Nach 30-60 Sekunden erreichst du den Shop unter `http://localhost` und den Admin unter `http://localhost/admin` (Login: admin / shopware). Plugins legst du im `./src`-Verzeichnis ab. Änderungen sind sofort im Container sichtbar.

Produktionsnahes Setup mit dem offiziellen Image

Für Staging und Produktion nutzt du das offizielle shopware/docker Image. Anders als Dockware enthält es kein vorinstalliertes Shopware. Du kopierst dein Projekt in das Image und baust ein eigenes Docker Image. Hier die Referenz-Konfiguration laut offizieller Shopware Docker-Dokumentation:

# Shopware 6 Produktion | Offizielles Image mit Caddy
# Stand: Mai 2026
services:
  shopware:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: shopware-prod
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: mysql://shopware:${DB_PASSWORD}@db:3306/shopware
      APP_URL: https://mein-shop.de
      APP_SECRET: ${APP_SECRET}
      APP_ENV: prod
      SHOPWARE_HTTP_CACHE_ENABLED: 1
      SHOPWARE_HTTP_DEFAULT_TTL: 7200
    volumes:
      - shopware-media:/var/www/html/public/media
      - shopware-theme:/var/www/html/public/theme
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000"]
      interval: 30s
      timeout: 5s
      retries: 3

  db:
    image: mysql:8.0
    container_name: shopware-db
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
      MYSQL_DATABASE: shopware
      MYSQL_USER: shopware
      MYSQL_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

volumes:
  shopware-media:
  shopware-theme:
  db-data:

Eine vollständige Anleitung zur Shopware Installation inklusive aller Methoden (Composer, Git, Docker) findest du in unserem separaten Guide.

Docker in der Entwicklung

Docker vereinfacht die Shopware-Entwicklung erheblich: Jeder Entwickler arbeitet in einer identischen Umgebung, Plugin-Tests laufen isoliert, und die Einrichtung neuer Teammitglieder reduziert sich von Stunden auf Minuten. In unseren Projekten haben wir das Onboarding neuer Entwickler von durchschnittlich 4 Stunden auf unter 15 Minuten gesenkt, seit wir Docker-basierte Setups nutzen.

Plugin-Entwicklung mit Volume-Mounts. Dockware mountet das `custom/plugins`-Verzeichnis direkt vom Host. Jede Dateiänderung ist sofort im Container wirksam, ohne Rebuild. Für das Admin-Frontend (Vue.js) startest du den Watcher mit `./psh.phar administration:watch`, für die Storefront mit `./psh.phar storefront:hot-proxy`. Änderungen am SCSS oder JavaScript erscheinen nach 1-2 Sekunden im Browser.

Mehrere Shopware-Versionen parallel. Du testest ein Plugin gleichzeitig auf Shopware 6.5, 6.6 und 6.7? Mit Docker startest du drei Container mit unterschiedlichen Image-Tags. Kein Umkonfigurieren, kein Versionschaos. Die Shopware API bleibt über Versionen hinweg stabil, aber Minor-Unterschiede in Twig-Templates und Admin-Komponenten erfordern paralleles Testing.

CI/CD-Integration. Docker-Container sind die Grundlage für automatisierte Build- und Test-Pipelines. GitHub Actions, GitLab CI und Bitbucket Pipelines unterstützen Docker nativ. Dein Pipeline-Skript baut das Image, führt PHPUnit-Tests aus und deployt bei Erfolg auf Staging. Kein "bei mir läuft's" mehr. Wer Shopware Headless oder Shopware Frontends einsetzt, profitiert besonders: Frontend und Backend laufen in separaten Containern und lassen sich unabhängig deployen.

Docker in Produktion

Shopware Docker in Produktion erfordert SSL-Terminierung, persistente Volumes für Medien und Datenbank, Health-Checks und eine Strategie für Zero-Downtime-Deployments. Das offizielle Shopware Docker Image ist dafür optimiert: Es läuft ohne Root-Rechte, nutzt Caddy oder Nginx als Webserver und basiert auf Alpine Linux (Image-Größe unter 100 MB).

Laut Shopware-Dokumentation unterstützt das offizielle Image Environment-Variablen für alle relevanten Konfigurationen: `DATABASE_URL`, `APP_URL`, `APP_SECRET`, `SHOPWARE_HTTP_CACHE_ENABLED`. Das bedeutet: Keine Konfigurationsdateien im Image, alles über Umgebungsvariablen steuerbar. Für Shopware Updates baust du ein neues Image mit der aktualisierten Codebasis und rollst es per Rolling Update aus.

Produktions-Checkliste

Skalierung wird bei Docker horizontal gelöst. Statt einen größeren Server zu kaufen, startest du weitere Container hinter einem Load Balancer. Docker Swarm reicht für die meisten Shopware-Shops aus. Kubernetes lohnt sich ab ca. 50.000 Seitenaufrufen pro Tag oder wenn du bereits Kubernetes-Infrastruktur betreibst. Laut Mordor Intelligence wächst der Container-Markt mit 21,67% CAGR auf voraussichtlich 16,32 Mrd. USD bis 2030. Die Richtung ist klar.

Zum Thema Shopware Performance Optimierung: In Docker-Setups bringt Redis als Session- und Cache-Backend den größten Performance-Gewinn. Ein separater Redis-Container reduziert die Antwortzeiten des Shops um 30-50% gegenüber File-basiertem Caching. Wer einen Shopware Relaunch plant, sollte Docker von Anfang an als Deployment-Methode einplanen.

Docker vs. Shopware Cloud

Shopware Cloud ist die Managed-Alternative zu Docker: Kein Server-Management nötig, dafür weniger Kontrolle über PHP-Konfiguration, Extensions und individuelle Anpassungen. Docker bietet maximale Flexibilität bei höherem Betriebsaufwand.

Die Entscheidung ist keine Frage von besser oder schlechter. Sie hängt an einer einzigen Variable: Hat dein Team die Kompetenz und die Kapazität, Docker-Infrastruktur zu betreiben? Wenn ja, bietet Docker mehr Kontrolle bei niedrigeren Kosten. Wenn nein, ist Shopware Cloud oder ein Shopware Cloud Hosting Provider der sicherere Weg. Einen detaillierten Kostenvergleich findest du im Shopware Hosting Vergleich.

Troubleshooting - Häufige Docker-Probleme

Die häufigsten Shopware-Docker-Probleme sind Dateiberechtigungen bei Volume-Mounts, langsame Performance unter macOS und fehlende PHP-Extensions. Alle lassen sich mit den richtigen Container-Konfigurationen lösen.

Permission Denied auf Volumes

Das häufigste Problem überhaupt. Der Container läuft mit User-ID 82 (www-data in Alpine), aber die Host-Dateien gehören deinem lokalen User (UID 1000). Lösung: Setze in der docker-compose.yml `user: "1000:1000"` oder führe `chown -R 82:82 ./src` auf dem Host aus. Unter Linux funktioniert auch die Zeile `DOCKER_USER=$(id -u):$(id -g)` als Environment-Variable.

Langsame Performance unter macOS

Docker auf macOS war lange ein Performance-Problem. Der Grund: Volume-Mounts über die Linux-VM erzeugen I/O-Overhead. Zwei Lösungen, Stand Q2 2026. Erstens: Nutze VirtioFS als Storage-Backend in Docker Desktop (aktivierbar unter Settings > General). Bringt 2-5x schnellere Dateizugriffe gegenüber dem alten gRPC-FUSE. Zweitens: OrbStack als Drop-in-Ersatz für Docker Desktop. Nahezu native Performance, geringerer RAM-Verbrauch. In unseren Tests lag die Seitenladezeit eines Shopware-Shops mit OrbStack bei 1,2 Sekunden, mit Docker Desktop bei 3,8 Sekunden.

MySQL Connection Refused

Der Shopware-Container startet schneller als MySQL. Ergebnis: Connection Refused. Die Lösung steht bereits im Produktions-Compose oben: `depends_on` mit `condition: service_healthy` und ein Health-Check auf dem DB-Container. So wartet Shopware, bis die Datenbank tatsächlich Verbindungen annimmt. Wer tiefer einsteigen will, findet bei einem Shopware Programmierer Unterstützung.

Elasticsearch/OpenSearch startet nicht

Elasticsearch braucht mindestens 262144 als `vm.max_map_count` auf dem Host. Prüfe mit `sysctl vm.max_map_count`. Falls der Wert zu niedrig ist: `sudo sysctl -w vm.max_map_count=262144`. Für persistente Konfiguration den Wert in `/etc/sysctl.conf` eintragen.

Häufig gestellte Fragen zu Shopware Docker

Fazit

Shopware Docker ist die richtige Wahl für Entwicklerteams und Shops mit hohen Anforderungen an Reproduzierbarkeit, Skalierung und Deployment-Automatisierung. Für kleine Shops ohne Dev-Team bleibt klassisches Managed Hosting die einfachere Option. Die Investition in ein Docker-Setup zahlt sich ab dem zweiten Projekt aus, weil die Infrastruktur wiederverwendbar ist.

Zusammengefasst: Dockware für Entwicklung, offizielles Image für Produktion. Wer beides beherrscht, hat einen vollständigen Workflow von der ersten Codezeile bis zum Live-Deployment. Den Überblick über alle Shopware Hosting Optionen findest du im Pillar-Guide.

Übrigens: Die technische Infrastruktur ist nur die halbe Miete. Was nach dem Deployment passiert, entscheidet über den Umsatz. Unsere Kunden wie Rasendoktor setzen auf einen KI-Mitarbeiter für automatisierte Produktberatung und erreichen damit einen 16x Return on Investment. Mehr Traffic bringt wenig, wenn Besucher ohne Beratung den Shop wieder verlassen. Ein KI-Produktberater ändert das.