Lerd: Eine rootless, Podman-native PHP-Entwicklungsumgebung für Linux

PHP-Entwicklung unter Linux ist seit Jahren ein gelöstes Problem – nur eben nicht elegant gelöst. Wer auf macOS arbeitet, greift zu Laravel Herd: zero config, automatische .test-Domains, One-Click-HTTPS, Per-Site-PHP-Versionen, ein nativer Desktop-Stack. Unter Linux existiert dieser Komfort schlicht nicht. Stattdessen jongliert man mit einer systemweiten PHP-FPM-Installation, manuellen Nginx-vHosts, /etc/hosts-Einträgen – oder man weicht auf Docker-basierte Per-Projekt-Stacks wie Laravel Sail, DDEV oder Lando aus, die jeweils einen eigenen Container-Stack pro Repository hochfahren.

Lerd geht einen anderen Weg. Es bringt das Herd-Modell – eine geteilte, projektübergreifende Infrastruktur – nach Linux (und mittlerweile auch macOS), setzt dabei aber konsequent auf rootless Podman statt nativer Binaries oder eines Docker-Daemons. Dieser Beitrag schaut sich die Architektur und die für Entwicklerteams relevanten Details genauer an.

Das Architekturmodell: shared infrastructure statt per-project stacks

Der zentrale Designentscheid von Lerd ist die geteilte Infrastruktur. Statt für jedes Projekt einen kompletten Stack aus Webserver, PHP-Runtime und Services hochzufahren, läuft genau ein Nginx, ein Pool von PHP-FPM-Containern und eine Instanz jedes Services (MySQL, Redis, etc.) für sämtliche Sites gemeinsam.

Der praktische Unterschied ist erheblich, gerade wenn man parallel an vielen Projekten arbeitet. Die Dokumentation beziffert den RAM-Verbrauch bei fünf gleichzeitig laufenden Projekten auf rund 200 MB – gegenüber etwa 1–2 GB bei Laravel Sail (fünf vollständige Stacks) oder 500 MB–1 GB bei DDEV (fünf App-Container plus Proxy).

Der zweite, oft unterschätzte Vorteil: Lerd erfordert keine Änderungen an den Projektdateien. Bei Sail, DDEV oder Lando muss eine docker-compose.yml, .ddev/config.yaml bzw. .lando.yml ins Repository committet werden. Lerd funktioniert per lerd link auch mit Legacy-Code oder fremden Client-Repos, an denen man nichts ändern darf oder will. Eine optionale .lerd.yaml für reproduzierbares Setup ist möglich, aber nicht erforderlich.

Rootless Podman + systemd user services

Der gesamte Stack läuft als rootless Podman-Container, gesteuert über systemd user services – also unter dem eigenen Benutzeraccount, ohne Root, ohne Docker-Daemon im Hintergrund. Wo verfügbar, arbeitet Lerd dual-stack über IPv4 und IPv6.

Das hat sicherheits- und betriebstechnische Konsequenzen, die in einem Team-Kontext zählen:

Kein privilegierter Daemon, der als root läuft und Angriffsfläche bietet.
Keine Manipulation des System-PHP oder System-Webservers – der Host bleibt sauber.
Lebenszyklus-Management über bekannte systemd-Mechanismen (lerd autostart enable koppelt den Start an den Login).

Die Befehle für den Tagesbetrieb sind entsprechend schlank:

lerd start          # DNS, Nginx, PHP-FPM, Services, Worker und UI hochfahren
lerd stop           # Container und Worker stoppen (UI und Watcher laufen weiter)
lerd quit           # vollständiges Herunterfahren inkl. UI, Watcher und Tray
lerd autostart enable
lerd status         # Health-Snapshot

.test-Domains und TLS ohne sudo

Eine Site einzubinden ist ein einzelner Befehl. lerd link verknüpft das aktuelle Verzeichnis, erkennt das Framework automatisch und richtet das Routing ein:

cd my-laravel-project
lerd link           # → https://my-laravel-project.test

Die .test-Domains werden über einen dnsmasq-Container aufgelöst – ohne Eingriff in den System-Resolver. Wer das nicht möchte, kann den von Lerd verwalteten DNS-Teil komplett umgehen und stattdessen *.localhost nutzen: kein dnsmasq, keine Resolver-Tweaks, kein sudo für den DNS-Anteil.

TLS funktioniert über mkcert, das ein systemweit vertrauenswürdiges Zertifikat ausstellt:

lerd secure

Die automatische Framework-Erkennung deckt Laravel (first-class), Symfony, WordPress, Drupal, CakePHP, Statamic, CodeIgniter und Tempest ab. Weitere Definitionen lassen sich aus einem Community-Repository nachinstallieren:

lerd framework search
lerd framework install symfony          # erkennt die Version aus composer.lock
lerd framework install drupal@11        # explizite Version

Runtime-Isolation: PHP, Node und FrankenPHP pro Site

Lerd liefert PHP 8.1 bis 8.5 als geteilte FPM-Container, plus einen eingefrorenen 7.4 / 8.0 Legacy-Tier für Projekte, die noch auf altem Stack gehostet werden. Der Versionswechsel pro Site geschieht ohne FPM-Neustart:

lerd isolate 8.4

Für JavaScript-Toolchains gibt es Node-Isolation pro Projekt (Node 22, 24), optional auch bun als JS-Runtime – sowohl auf dem Host als auch, opt-in, im Container.

Interessant für performance-sensitive Setups: Lerd bietet FrankenPHP als alternative Runtime pro Site an, inklusive Worker-Modus für Laravel Octane und Symfony Runtime:

lerd runtime frankenphp --worker

Damit lässt sich pro Projekt zwischen klassischem shared PHP-FPM und einem persistenten Worker-Prozess umschalten – ohne den ganzen Stack umzubauen.

Built-in Observability: Profiler, Debug-Stream, Worker-Self-Heal

Hier wird Lerd für die tägliche Arbeit interessant, denn diese Dinge muss man sich sonst selbst zusammenbauen.

SPX Flame-Graph Profiler. Per One-Click-Toggle wird jeder PHP-FPM-Request zu einem Flame Graph, der in einer same-origin Profiler-Ansicht im Dashboard landet. Kein FPM-Neustart, keine Code-Änderungen, keine separate Extension-Konfiguration.

Debug-Fenster für jeden dump() / dd(). Lerd fängt jeden Dump-Aufruf ab und streamt ihn ins Dashboard, ins TUI und in den MCP-Stream – scoped pro Site und pro Worktree-Branch. Mitgeschnitten werden außerdem SQL-Queries (inklusive N+1-Erkennung), Mails, Events, Jobs und ausgehende HTTP-Requests. Die eigentliche HTTP-Response bleibt dabei sauber, der Output landet im Debugger statt im Markup.

In-Browser Tinker REPL. Eine PHP-REPL pro Site mit Autovervollständigung für die eigenen Models, Composer-Helper und Built-ins, Live-Syntaxprüfung und einem aufklappbaren Baum für dump()-Output. Funktioniert mit Laravel, Symfony und jedem Composer-Projekt.

Worker Self-Heal. Queue-, Schedule-, Horizon- und Reverb-Worker sowie der Stripe-Listener laufen als systemd user services, werden überwacht und lassen sich per Klick neu starten:

lerd worker start queue
lerd worker start schedule

Xdebug ist über lerd xdebug:on oder den Tray-Toggle pro Site schaltbar.

Das Dashboard: CLI, TUI, Web-UI und Tray

Lerd setzt nicht auf eine einzige Oberfläche, sondern spiegelt den Zustand über mehrere Surfaces:

ein Web-UI unter 127.0.0.1:7073, das sich als PWA unter lerd.localhost installieren lässt – darüber PHP-Versionen wechseln, Services togglen, Live-Logs tailen und Tinker ausführen
ein btop-artiges TUI plus System-Tray-Integration
die volle CLI

Alle vier Oberflächen greifen auf denselben Zustand zu – der Debug-Stream und die Logs erscheinen also unabhängig davon, wo man gerade arbeitet.

MCP-Server: KI-Assistenten steuern die Umgebung

Ein zunehmend relevanter Aspekt für Teams, die mit KI-gestützten Editoren arbeiten: Lerd bringt einen eingebauten MCP-Server (Model Context Protocol) mit elf gruppierten Tools mit. Damit können Assistenten wie Claude Code, Cursor, Codex CLI, Gemini CLI, Copilot, Junie, Antigravity oder Windsurf direkt mit der Umgebung interagieren – Projekte scaffolden, PHP-Versionen wechseln, Migrationen ausführen, Logs in den Chat streamen.

lerd mcp:enable-global

Die exponierten Tools entsprechen den CLI-Operationen, etwa site.link (lerd link), site.php (lerd isolate 8.4), service.start für Services oder logs.fetch für den Dump- und Query-Stream zurück in den Chat.

Services und polyglotte Setups

Lerd bündelt die gängigen Services als rootless Container und kostenlos: MySQL, PostgreSQL, Redis, Meilisearch, RustFS (S3-kompatibel), Mailpit, Stripe Mock und Reverb. Sie lassen sich pro Workspace über CLI, Dashboard oder MCP an- und abschalten.

Für alles darüber hinaus genügt ein Containerfile.lerd im Projekt, um beliebige Runtimes – Node, Python, Go, Ruby, Rails – neben den PHP-Sites laufen zu lassen. Non-PHP-Projekte sind damit first-class statt nachträglich angeflanscht.

Wie ordnet sich Lerd gegenüber den Alternativen ein?

Lerd ist kein Allzweck-Werkzeug, das alles besser macht – es trifft eine bewusste Designentscheidung (shared infrastructure, Podman-only) und ist in einigen Achsen damit enger gefasst als die Konkurrenz.

vs. Laravel Herd: Lerd ist im Geist am nächsten – derselbe Zero-Config-Shared-Stack-Ansatz, aber Open Source (MIT) und auf Linux verfügbar, wo Herd schlicht keinen Build hat. Herd nutzt native Binaries und ist dadurch performanter; Lerd handelt sich durch Podman einen kleinen Overhead ein (auf macOS via Podman Machine etwas mehr), bietet dafür aber rootless Isolation, einen vollständig offenen Stack und Features wie den Datenbank-Inspector oder Log-Viewer ohne Pro-Subscription.

vs. Laravel Sail / DDEV / Lando: Diese fahren jeweils einen eigenen Stack pro Projekt hoch, mit per-project Service-Isolation und Konfiguration im Repo. Das ist die richtige Wahl, wenn ein Team plattformübergreifend arbeitet, projektspezifische Service-Versionen braucht oder die Infrastruktur bewusst ins Repository committen will. Lerd ist die richtige Wahl, wenn man an vielen Projekten gleichzeitig arbeitet, keinen separaten Stack pro Repo will, Projektdateien nicht anfassen kann und einen leichtgewichtigen, geteilten Stack mit sofortigem .test-Routing bevorzugt. Für den Umzug von Sail gibt es sogar lerd sail import, das Datenbank und S3/MinIO-Storage in einem Befehl übernimmt.

Eine grobe Heuristik: Wer per-project isolation und infrastructure-as-code im Repo als harte Anforderung hat, ist bei DDEV/Sail/Lando besser aufgehoben. Wer den Herd-Workflow auf Linux und einen leichten, geteilten Stack über viele Repos will, ist bei Lerd richtig.

Installation

Die Installation erfolgt über ein einzeiliges Script. lerd install startet beim ersten Lauf bereits alles, sodass man direkt lerd link ausführen kann:

curl -fsSL https://raw.githubusercontent.com/geodro/lerd/main/install.sh | bash

Lerd läuft first-class auf Arch, Ubuntu, Fedora und Debian (systemd vorausgesetzt) sowie auf macOS via Homebrew. Windows-Support existiert über WSL2, befindet sich aber noch in der Beta.

Fazit

Lerd schließt eine konkrete Lücke im Linux-PHP-Ökosystem: den Komfort von Herd, aber Open Source, ohne macOS-Lock-in, ohne Docker-Daemon und ohne Root. Der rootless-Podman-Ansatz über systemd user units ist sauber umgesetzt, und der geringe Ressourcen-Footprint macht ihn besonders attraktiv für Setups mit vielen parallelen Projekten.

Bemerkenswert ist die Tiefe des Feature-Sets für ein Projekt dieser Größe: SPX-Profiling, ein per-Branch gescopter Debug-Stream mit N+1-Erkennung, FrankenPHP/Octane-Worker, Worker-Self-Heal und eine vollwertige MCP-Integration sind Dinge, die man in vergleichbaren Tools meist selbst zusammenbauen muss. Für PHP-Teams unter Linux, die bisher mit einer handgestrickten DDEV- oder Compose-Lösung arbeiten, lohnt sich ein ernsthafter Blick.

Das Projekt ist MIT-lizenziert und stammt von George Dumitrescu.

GitHub: github.com/geodro/lerd
Dokumentation: lerd.sh
Lizenz: MIT

Die rootless PHP-Entwicklungsumgebung, die Linux gefehlt hat