DDEV aus Entwicklersicht: Erfahrungen aus der täglichen Praxis
tl;dr: Ich würde auf DDEV nicht mehr verzichten wollen und kann es jedem Web-Entwickler ans Herz legen sich das einmal anzuschauen.
Als Fullstack Developer kenne ich den Kampf mit verschiedenen Entwicklungsumgebungen nur zu gut. Wir sind eine Agentur, die täglich mit unterschiedlichsten Kundenprojekten und Technologien arbeitet. Jedes Projekt hat seine eigenen Anforderungen, andere PHP Versionen, spezifische Node Versionen, und natürlich wollen alle Teammitglieder die gleiche konsistente Umgebung haben.
Das Problem mit traditionellen Setups
Vor DDEV hatte jedes Projekt seine eigene Mischung aus lokal installiertem PHP (via Homebrew oder Laravel Herd auf dem Mac), XAMPP, MAMP, individuellen Docker Compose Konfigurationen oder anderen Lösungen. Das führte zu klassischen Agentur Problemen:
- „Bei mir läuft es aber lokal!“
- Stundenlanges Einrichten neuer Projekte
- Inkompatible Versionen zwischen Entwicklern
- Unterschiede zwischen lokaler und Produktivumgebung
Besonders das „lokal gehts aber“-Problem war ein ständiger Begleiter. Neue Teammitglieder benötigten oft mehrere Stunden, um ein Projekt lokal zum Laufen zu bringen.
Warum DDEV für Agenturen ideal ist
Schnelle Projektinitialisierung
Mit zwei einfachen Befehlen lässt sich ein neues Projekt aufsetzen:
ddev config
ddev startDas ist besonders wertvoll, wenn wir zwischen verschiedenen Systemen wie Laravel, TYPO3 oder Next.js wechseln müssen. DDEV bietet vordefinierte Konfigurationen für zahlreiche gängige Systeme: backdrop, cakephp, craftcms, drupal, generic, laravel, magento, php, shopware6, silverstripe, symfony, typo3, wordpress und viele mehr. Für einfache PHP Umgebungen ohne Framework reicht die Standard Konfiguration aus.
SSL und HTTPS von Haus aus
Ein oft unterschätzter Vorteil: DDEV generiert automatisch gültige SSL Zertifikate für alle lokalen Domains. Kein manuelles Zertifikate erstellen, keine Browser Warnungen, keine Konfiguration. Das funktioniert sofort:
# Beispiel aus einer .ddev/config.yaml
name: demo-projekt
type: php
docroot: public
webserver_type: nginxDDEV richtet automatisch HTTPS ein. In unserem Beispiel wäre es https://demo-projekt.ddev.site. Perfekt für Projekte, die zwingend eine sichere Umgebung benötigen, etwa bei OAuth2 Integrationen oder Payment Tests.
Produktivsystem Abbildung
Die Möglichkeit, exakt die gleiche PHP Version, Datenbank und Server Konfiguration wie auf dem Live Server zu nutzen, hat unsere Deployment Probleme massiv reduziert. Wir können vorab bestimmte Server Packages updaten und prüfen, ob das System danach noch reibungslos läuft. So gibt es keine Überraschungen mehr beim Deployen.
Integrierte Developer Tools
Alle notwendigen Tools sind direkt im Container verfügbar:
- Composer für PHP-Abhängigkeiten
- Node/Yarn für Frontend-Builds
- WP-CLI für WordPress-Projekte
- MySQL/PostgreSQL als Datenbanken
- Mailpit um Mails zu empfangen und zu verwalten
- Xdebug fürs Debugging
Einfache Team-Zusammenarbeit
Die .ddev/config.yaml Datei wird in unser Versionskontrollsystem aufgenommen. Neue Teammitglieder können mit drei Befehlen arbeiten:
git clone project-url project
cd project
ddev startDas Problem „wie kann ich das lokal aufsetzen“ gehört damit der Vergangenheit an. Die Dokumentation ist im Projekt selbst enthalten.
Ihr wollt DDEV bei euch im Team etablieren?
Wir teilen unsere Erfahrungen gerne. Ob bei der Einführung, bei konkreten Projektfragen oder wenn es um die nächsten Schritte geht.
Konkrete Anwendungsfälle aus unserer Praxis
1. Multi-Domain Entwicklung
Für Kunden mit mehreren zusammenhängenden Systemen nutzen wir zusätzliche Hostnames:
additional_hostnames:
- cms.demo-projekt
- blog.demo-projekt
- api.demo-projekt
additional_fqdns:
- api-test.live-projekt.deBesonders nützlich: Wir können sogar Subdomains von Produktivsystemen einbinden, um beispielsweise Cookies für SSO-Lösungen korrekt zu testen oder Payment Provider Callbacks. In unserem Beispiel hätten wir die vier neuen Domains:
2. Redis als Cache
Die Redis-Integration erfolgt über eine zusätzliche Konfigurationsdatei. Für Laravel-Projekte, die standardmäßig Redis nutzen, erstellen wir eine docker-compose.redis.yaml:
services:
redis:
container_name: ddev-${DDEV_SITENAME}-redis
image: redis:7
restart: always
ports:
- 6382:6379
labels:
com.ddev.site-name: ${DDEV_SITENAME}
com.ddev.approot: $DDEV_APPROOT
environment:
- VIRTUAL_HOST=$DDEV_HOSTNAME
- HTTP_EXPOSE=6379
volumes: []
web:
links:
- redis:$DDEV_HOSTNAMEDiese Datei wird im .ddev Verzeichnis gespeichert und automatisch von DDEV geladen. So können wir für jedes Projekt individuelle Services ergänzen und profitieren von deutlich schnelleren Antwortzeiten durch Redis Caching.
3. Eigene DDEV Hooks für Projekte
hooks:
post-start:
- exec: "yarn install"
- exec: "yarn dev"Damit wird yarn immer installiert und direkt ein yarn dev im Container ausgeführt. Das stellt sicher, dass alle Abhängigkeiten aktuell sind und der Development-Server sofort läuft.
4. Zusätzliche Services und Ports freigeben
In einem Projekt mit Next.js haben wir durch diese .ddev/config.yaml Anpassung den Port 3000 nach außen freigegeben:
web_extra_exposed_ports:
- name: "NextJS Website Name"
container_port: 3000
http_port: 2999
https_port: 3000So können wir lokal auf Port 3000 zugreifen und den im Container laufenden Service erreichen. Diese einfache Anpassung muss nur einmal gemacht werden. Jedes Teammitglied profitiert direkt davon.
5. Debugging und Entwicklung
Xdebug funktioniert sofort ohne komplizierte Konfiguration. Mit ddev xdebug on aktivierst du es, mit ddev xdebug off deaktivierst du es (oder alternativ ddev xdebug toggle). Das spart wertvolle Zeit bei der Fehlersuche.
Damit Xdebug mit Visual Studio Code zusammenarbeitet, braucht es nur eine kleine Konfiguration. Lege dazu eine .vscode/launch.json Datei in deinem Projekt an:
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"hostname": "0.0.0.0",
"port": 9003,
"pathMappings": {
"/var/www/html": "${workspaceFolder}"
},
"preLaunchTask": "DDEV: Enable Xdebug",
"postDebugTask": "DDEV: Disable Xdebug"
}
]
}6. Datenbank-Handling
Datenbank-Sicherungen und -Wiederherstellungen sind trivial:
ddev export-db --file=backup.sql
ddev import-db --src=backup.sqlFür Kundenprojekte mit regelmäßigen Live-Daten-Imports ist das unschätzbar wertvoll.
Die Grenzen von DDEV – eine ehrliche Betrachtung
So sehr ich DDEV schätze, es gibt auch Schattenseiten, die man kennen sollte:
Abstraktionsschicht mit Wartezeit
DDEV fügt eine zusätzliche Abstraktionsschicht hinzu, die auch ausbremsen kann. Allein das Starten eines Projekts dauert meist eine Minuten wenn es viele Abhängigkeiten oder hooks enthält. Das summiert sich, wenn man täglich mehrmals zwischen Projekten wechselt.
Das Docker Port Problem
DDEV leidet unter dem typischen Docker Problem: Es dürfen keine doppelten exponierten Ports existieren. Das bedeutet: Entweder man startet nie mehrere Projekte gleichzeitig, oder man muss manuell darauf achten, dass alle Projekte unterschiedliche Ports verwenden. In der Praxis führt das oft zu "Port already in use" Fehlern.
Kein natives Next.js Template
DDEV spezialisiert sich stark auf PHP. Für Next.js gab es lange kein offizielles Template, und auch heute ist die Unterstützung für Node.js basierte Projekte nicht so ausgereift wie für PHP. Man kann es zum Laufen bringen, aber es erfordert Handarbeit.
KI Tools brauchen zusätzlichen Kontext
Wenn wir Code mit KI Assistenten wie Copilot oder Cursor schreiben, müssen wir bei jedem Projekt daran denken, den richtigen Kontext mitzugeben. Die Tools müssen wissen, dass sie Befehle mit ddev ausführen sollen: also ddev yarn statt nur yarn, ddev artisan statt php artisan.
Besonders beim Debuggen mit Cursor gibt es eine typische Hürde: Der Debug Modus sendet HTTP Requests standardmäßig an localhost. Der läuft aber auf der Host Maschine, nicht im Docker Container. Hier braucht es den Hinweis auf host.docker.internal, damit die Verbindung funktioniert.
Eine gute Abhilfe sind AGENT.md Dateien im Projekt. Darin können wir der KI einmalig erklären, wie sie mit DDEV umgehen soll. Einmal angelegt, merkt sich der Assistent diese Regeln und wendet sie automatisch an.
Ältere PHP Versionen verschwinden
DDEV pflegt nur die aktuellen PHP Versionen. Ältere Versionen wie PHP 5.6 oder 7.0 werden mit der Zeit aus den offiziellen Images entfernt. Für wartende Legacy Projekte kann das problematisch werden. Zwar lassen sich oft noch ältere Images finden, aber der offizielle Support endet irgendwann.
Ressourcen Hunger
Mehrere gleichzeitig laufende Projekte beanspruchen viel RAM. Auf einem Developer Laptop mit 16 GB stößt man schnell an Grenzen, wenn drei oder vier Projekte parallel laufen.
Quick Wins für den Agentur Alltag
Git-Integration
Mit dem Befehl ddev auth ssh wird der lokale SSH Key in den DDEV Container gepusht. Danach kann der Container von innen heraus mit diesem Key auf Systeme zugreifen, für die er berechtigt ist. Das ist besonders praktisch, wenn wir private Packages aus internen Repos installieren müssen. Der Container verhält sich dann so, als hätte er selbst den SSH Key, ohne dass wir Keys manuell kopieren oder auslagern müssen.
Custom-Commands
Im .ddev/commands/ Ordner können wir Bash Dateien anlegen, um wiederkehrende Befehle einmal zu definieren und immer wieder zu nutzen. Bei einem Kunden haben wir uns ein Datenbank Backup Script gebaut, das bestimmte Tabellen exportiert und direkt in unsere lokale DDEV Datenbank importiert. Dabei nutzt das Script den SSH Key, den wir vorher in den Container gepusht haben, damit der Ziel Server unsere Anfrage autorisiert. Einmal gebaut, spart uns dieses Custom Command jede Woche wertvolle Zeit.
Einfache Konfigurationsanpassungen
Änderungen an der Entwicklungsumgebung sind für jedes Teammitglied sofort nachvollziehbar. Wenn wir in einem extra Git Branch ein PHP Upgrade vorbereiten, ändert sich in der .ddev/config.yaml nur eine Zeile:
# vorher
php_version: "8.3"
# nachher
php_version: "8.4"Diese kleine Anpassung erspart uns den ganzen manuellen Installations und Anpassungs Kram. Jeder im Team wechselt einfach den Branch, startet DDEV neu und hat die neue PHP Version. Kein "bei mir funktioniert das nicht", keine stundenlangen Einrichtungs Sessions.
Mein Fazit
Nach rund acht Jahren intensiver DDEV Nutzung in zahlreichen Kunden und privaten Projekten kann ich klar sagen: Ich würde auf DDEV nicht mehr verzichten wollen. In jeder Agentur, in der ich gearbeitet habe, habe ich DDEV etabliert und die positiven Effekte waren spürbar.
Die Einarbeitungszeit ist minimal und amortisiert sich innerhalb kürzester Zeit. Was ich besonders schätze: Die Konfiguration ist gut dokumentiert, für jeden verständlich und einfach anzupassen. Das sorgt für Konsistenz über alle Projekte hinweg.
Für Agenturen, die mit verschiedenen CMS Systemen, unterschiedlichen Kundenanforderungen und mehreren Entwicklern arbeiten, ist DDEV ein Segen. Es standardisiert Entwicklungsprozesse, reduziert Einrichtungszeiten und sorgt für konsistente Umgebungen.
Der einzige „Fluch“ ist, dass man einmal erlebt hat, wie einfach lokale Entwicklung sein kann. Zurück zu alten Methoden möchte danach niemand mehr.
Meine Empfehlung: Gebt DDEV einen Chance. Startet entweder mit einem neuen Projekt und setzt es direkt mit DDEV auf, oder portiert ein bestehendes Projekt. Beide Wege sind gleichermaßen einfach. Die Lernkurve ist flach, der Payoff enorm. Die Zeit, die ihr in die Einrichtung investiert, holt ihr durch wegfallende "bei mir geht es" Diskussionen und schnelleres Onboarding neuer Teammitglieder vielfach wieder rein.
Alexander Frank
Systemarchitekt für Webplattformen