Warum ich DDEV nicht zum Entwickeln nutze

Viele Leute schwören auf DDEV, besonders in der TYPO3-Community. Ich nicht. Und jedes Mal, wenn ich das laut sage, fragt jemand nach dem Warum — hier ist die lange Antwort.

Das hier ist kein "DDEV ist schlecht"-Artikel. Es ist ein "DDEV löst ein Problem, das ich gar nicht gelöst haben will"-Artikel. Das ist ein Unterschied, und am Ende kommt der Teil, in dem DDEV wirklich die richtige Wahl ist.

Erst mal: Was ist DDEV überhaupt?

Falls du wegen der Vor- und Nachteile hier gelandet bist, kennst du es vielleicht noch nicht im Detail, deshalb kurz: DDEV ist eine lokale Entwicklungsumgebung für PHP-Projekte. Du wechselst in einen Projektordner, rufst ddev config und ddev start auf, und zwei Minuten später hast du einen laufenden Webserver, PHP, eine Datenbank, einen Mailcatcher und eine URL mit gültigem Zertifikat. TYPO3, Drupal, WordPress, Symfony und Laravel kennt es out of the box — für die üblichen Setups konfigurierst du also gar nichts.

Das ist der komplette Pitch, und es ist ein guter Pitch. Genau da fangen meine Probleme aber auch an.

1. DDEV biegt Docker in eine Form, für die es nicht gedacht war

Ein Docker-Container sollte einen Service laufen lassen. Einen. Das ist die ganze Idee dahinter: kleine, austauschbare Einheiten, die du einzeln neu starten, ersetzen und skalieren kannst.

DDEV packt den kompletten Web-Stack in einen einzigen ddev-webserver-Container. nginx, PHP-FPM, Node, Composer, den Mailcatcher, das CLI-Tooling — alles in eine Kiste. Es gibt einen separaten Datenbank-Container und einen gemeinsamen Router, es ist also nicht buchstäblich ein Container für alles. Aber der Teil, in dem du jeden Tag arbeitest, ist ein fetter Container.

Warum das in der Praxis zählt? Weil du in dem Moment, in dem du etwas brauchst, das nicht in der Kiste ist, an einem Container herumflickst, der dir nicht gehört. Andere Node-Version als die mitgelieferte? Eine eigene PHP-Extension? Eine zweite PHP-Version für ein Altprojekt? Dann schreibst du Konfigurationsdateien, die das Dockerfile von jemand anderem neu generieren — und debuggst das statt deiner Anwendung.

Jede Abstraktion ist eine Wette darauf, dass du das, was darunter liegt, nie brauchen wirst. Die Wette wird irgendwann fällig.

2. Du kannst DDEV auf deinen Server schieben — verlassen solltest du dich nicht darauf

Das habe ich früher pauschal behauptet: DDEV ist rein lokal, Ende der Geschichte. Das stimmt so nicht mehr, also korrigiere ich mich. DDEV dokumentiert inzwischen ein experimentelles "Hosting with DDEV"-Setup: DDEV auf einem öffentlichen Linux-Server installieren, DNS darauf zeigen lassen, im Production-Modus starten — und du hast eine Live-Seite inklusive Let's-Encrypt-Zertifikaten und gehärteten Images.

Lies aber die Warnungen auf dieser Seite, denn DDEV verkauft das nicht schöner, als es ist. Dort steht unmissverständlich, dass es kein Ersatz für skalierbares, gemanagtes Hosting ist, dass niemand weiß, wie viel Traffic so ein Setup verträgt, und dass hinter diesem Hosting-Ansatz kein Security-Team steht. Gedacht ist es für Seiten mit wenig Traffic, für Staging-Kisten und Sonderfälle — nicht für das, wovon dein Geschäft abhängt.

Der Einwand wird damit kleiner, aber er verschwindet nicht. Für alles, was mir wirklich wichtig ist, werde ich DDEV nicht in Produktion laufen lassen. Also bleiben Entwicklung und Produktion zwei verschiedene Stacks — und damit fehlt mir die Garantie, die mir am meisten wert ist: dass die Umgebung, in der ich getestet habe, die Umgebung ist, in der mein Code läuft.

Mit einfachem Docker bekommst du diese Garantie geschenkt, weil du das Entwicklungs-Image auf Basis des Produktions-Images baust:

FROM serie3/prodphp:8.2

RUN pecl install xdebug && docker-php-ext-enable xdebug
COPY dev.ini /usr/local/etc/php/conf.d/

Gleicher PHP-Build, gleiche Extensions, gleiche INI-Defaults wie auf dem Server — plus Xdebug und was das lokale Arbeiten sonst erträglich macht. Wenn sich jetzt etwas in Produktion anders verhält, ist der Unterschied echt und es lohnt sich, ihm nachzugehen, statt Rauschen aus zwei unabhängigen Umgebungen zu sein.

3. DDEV gibt dir HTTPS auf dem Laptop

Moment, das ist doch gut? Ja und nein.

HTTPS ist offensichtlich gut. Ich finde nur, du solltest es auf deinem Laptop nicht brauchen. Jede Software, die ich schreibe, ist unabhängig von ihrer Umgebung. Es ist ihr egal, ob der Traffic verschlüsselt ist, auf welcher Domain sie läuft (meistens jedenfalls — manchmal zählt es wirklich) und wo die Datenbank steht. Wenn meine Anwendung nur über TLS funktioniert, ist das ein Designproblem in der Anwendung, und ein lokales Zertifikat versteckt es, statt es zu lösen.

Eine sichere Umgebung aufzusetzen ist Aufgabe der DevOps-Seite. Software zu bauen, der das egal ist, ist meine.

Es gibt eine ehrliche Ausnahme, und die trifft mich regelmäßig: OAuth-Callbacks. Meta, TikTok und LinkedIn leiten nicht auf localhost um. Dafür nehme ich einen Tunnel, kein lokales Zertifikat — aber das ist ein eigener Artikel.

4. Es ist ein Werkzeug mehr, das gelernt und konfiguriert werden will

Jedes Werkzeug im Stack kostet Overhead. Nicht nur Installationszeit, sondern Platz im Kopf. Ein weiteres Konfigurationsformat, eine weitere CLI, ein weiterer Satz Issues, die du durchsuchst, wenn etwas kaputt ist, eine weitere Sache, die du der nächsten Person erklärst, die ins Team kommt.

Und DDEV läuft sowieso auf Docker. Die Wahl ist also nicht "DDEV oder etwas Kompliziertes", sondern "DDEV plus Docker" oder "nur Docker". Ich weiß, was ich lieber im Kopf habe.

Es gibt hier auch ein Karriere-Argument, und das meine ich ernst: Docker-Wissen nimmst du in jeden Job mit, den du je haben wirst. DDEV-Wissen nimmst du in PHP-Läden mit, die schon DDEV nutzen. Im Vorstellungsgespräch klingt "ich konfiguriere meine Umgebungen selbst, mit Docker und docker-compose" deutlich anders als "wir machen ddev start".

Was nutze ich denn nun?

Einfaches Docker mit docker-compose. Ein typisches Projekt von mir hat drei oder vier Services, und die ganze Datei passt auf einen Bildschirm:

services:
  db:
    build:
      context: ./env/base/DB/
    ports:
      - "3306:3306"

  php:
    build:
      context: ./env/dev/Php
    volumes:
      - ./community:/var/www/site/
    environment:
      - PHP_IDE_CONFIG=serverName=myproject
    links:
      - "db:database"

  web:
    image: serie3/prodweb:20.4
    volumes:
      - ./community:/var/www/site/
    links:
      - "db:database"
      - "php:php"
    ports:
      - "80:80"

Das war's. Drei Services, jeder macht eine Sache. Das web-Image ist dasselbe, das auf dem Server läuft. Das php-Image ist das Produktions-Image mit angeschraubtem Xdebug. PHP_IDE_CONFIG ist das, was PhpStorm die Breakpoints wieder auf meine Dateien mappen lässt.

Das erste Mal aufsetzen kostet einen Nachmittag. Ins nächste Projekt kopieren kostet fünf Minuten.

Wann DDEV die richtige Wahl ist

DDEV kann wirklich nützlich sein — ich will es nur nicht in meinem Stack haben.

Wenn du ein Team onboardest, in dem die Hälfte noch nie Docker angefasst hat, macht DDEV alle heute produktiv statt nächste Woche. Wenn du fünfzehn kleine Kundenseiten betreust, von denen jede zwanzig Minuten im Jahr laufen muss, ist das vorkonfigurierte Setup mehr wert als die Kontrolle, die du aufgibst. Wenn du neu in PHP bist und die Umgebung das ist, was dich vom Programmieren abhält: nimm DDEV und schreib den Code.

Wenn du aber in eine Senior-Rolle hineinwachsen willst, lerne irgendwann, deine Umgebung selbst zu bauen. Nicht weil DDEV-Nutzer ihr Handwerk nicht beherrschen — viele tun das —, sondern weil an dem Tag, an dem die Abstraktion leckt, jemand verstehen muss, was darunter liegt. Das kannst genauso gut du sein.

Mein komplettes lokales PHP-Setup schreibe ich demnächst Schritt für Schritt auf. Dieses Blog hat keinen Abonnieren-Button, also folg mir auf LinkedIn — da poste ich jedes Mal, wenn etwas Neues online geht.