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.

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.

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

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.

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.

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.