Dagu: Workflow-Orchestrierung als YAML-Datei neben dem Skript
Self-hostable workflow orchestrator for teams whose main work isn't orchestration. Declarative YAML over your scripts, SSH commands, containers, etc; keep workflows separate from business logic. One binary, no database, runs on limited H/W resources. Alternative to Airflow / Cron / Job Scheduler.
Auf einen Blick
- Was ist das?
- Dagu ist ein selbst gehosteter Workflow-Orchestrator in Go, der Abläufe als deklaratives YAML beschreibt und als einzelne Binärdatei ohne externe Datenbank läuft. Für Teams, deren eigentliche Arbeit nicht die Orchestrierung ist, ist das ein bewusster Verzicht auf Plattformbetrieb, aber auch ein Verzicht auf Funktionen, die große Systeme mitbringen.
- Für wen ist es gedacht?
- Dagu passt zu kleinen und mittleren Teams, die vorhandene Skripte mit Zeitplan, Wiederholungen und Protokollansicht versehen wollen, ohne eine Plattform zu betreiben, und zu Umgebungen ohne externe Dienste. Wer verteilte, dauerhaft laufende Geschäftslogik mit SDK-Anbindung braucht, sollte bei Temporal bleiben, und wer bereits Airflow mit ausgebildetem Betriebsteam fährt, hat wenig Grund zu wechseln.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Dagu adressiert und für wen
Die Ausgangslage beschreibt das README selbst: Skripte und Container funktionieren bereits, es fehlen Zeitplan, Abhängigkeiten, Wiederholungen und eine Stelle, an der Protokolle einsehbar sind. Genau an dieser Lücke setzt Dagu an. Die Zielgruppe sind nach eigener Darstellung Teams, deren Hauptarbeit nicht Orchestrierung ist: Betrieb, Datenverarbeitung, Medienkonvertierung, Infrastrukturautomatisierung, Edge- und IoT-Szenarien. Auch Support-Automatisierung wird genannt, bei der Nicht-Entwickler Abläufe selbst starten.
Die Abgrenzung im README ist ungewöhnlich offen formuliert. Cron wird als Ausführungswerkzeug beschrieben, dem Abhängigkeiten, Wiederholungen und Historie fehlen. Airflow orchestriert, verlangt aber den Betrieb einer Plattform aus Scheduler, Metadatenbank, Workern und Python-Umgebung, wobei Jobs als Framework-Code neu geschrieben werden. Temporal bietet durable Execution, zieht die Geschäftslogik aber in sein SDK. Der Satz aus dem README, dass man nur einige Jobs planen wollte und nun ein zweites System betreibt, trifft die Entscheidungssituation recht genau. Wer diese Beschreibung auf die eigene Lage nicht anwenden kann, ist vermutlich nicht die Zielgruppe.
Ein Binary, Dateien als Zustandsspeicher
Der zentrale Mechanismus ist die Trennung von Struktur und Ausführung. Reihenfolge, Abhängigkeiten, Wiederholungen, Zeitpläne und menschliche Aufgaben stehen in einer YAML-Datei, die neben den Skripten liegt. Die Skripte selbst importieren nichts aus Dagu. Wird die YAML-Datei gelöscht, laufen sie unverändert weiter. Das ist die eigentliche Designentscheidung des Projekts und der Grund, warum sich Dagu ohne Änderung an bestehender Automatisierung einführen lässt.
Der Motor ist ein einzelner Prozess. Das README stellt ihn einem herkömmlichen Aufbau mit Web-Server, Scheduler, Workern, PostgreSQL, Redis oder RabbitMQ und Python-Laufzeit gegenüber, der dort mit mehr als sechs zu betreuenden Diensten beziffert wird. Dagu speichert seinen Zustand stattdessen in lokalen Dateien. Diese dateibasierte Ablage erklärt auch, warum Worker schwere Konvertierungen ohne zentrale Datenbank parallel ausführen können, wie es im Anwendungsfall Medienkonvertierung beschrieben wird. Der Preis dieser Entscheidung wird im README nicht ausgeführt: Wo kein Datenbankserver steht, gibt es auch keine zentrale Abfrageschicht, und die Konsistenz hängt an der Dateiablage des jeweiligen Rechners. Wer viele Worker über mehrere Maschinen verteilt, sollte klären, wie sich dieser Zustand verhält, bevor daraus ein Produktivsystem wird.
Was als Schritt ausgeführt werden kann
Dagu führt laut README Shell-Befehle, Docker-Container, Kubernetes-Jobs und entfernte Kommandos über SSH aus, ohne dass diese angepasst werden müssen. Weitere Ziele laufen über die sogenannten Dagu Actions. Schritte lassen sich zu wiederverwendbaren Sub-DAGs zusammensetzen und parallel ausführen, mit Nebenläufigkeitsgrenzen. Zeitpläne nutzen Cron-Syntax und berücksichtigen Zeitzonen, Überlappungsrichtlinien und Aufholfenster. Protokolle, Ausführungshistorie, Wiederholungen, Benachrichtigungen und Webhook-Auslöser liegen an einer Stelle.
Für den Betrieb relevant sind die Steuerungsmittel, die das README unter Lastkontrolle nennt: Warteschlangen, Nebenläufigkeitsgrenzen und Ressourcengrenzen legen fest, wie viele Läufe gleichzeitig stattfinden und wo sie laufen. Das ist die Antwort auf die naheliegende Frage, was passiert, wenn ein Zeitplan viele Läufe gleichzeitig auslöst. Wichtiger als die Angabe, dass eine einzelne Maschine Tausende Läufe pro Tag schafft, ist der Zusatz im README, dass die tatsächliche Kapazität von CPU, Speicher, Platten und Form des Workflows abhängt. Diese Angabe ist ehrlich, aber sie ist keine Planungsgrundlage. Wer Dimensionierung braucht, muss selbst messen.
Ein weiteres Element ist der eingebaute MCP-Server. Er dient laut README dazu, Workflows und Läufe zu inspizieren, Wiki-Seiten zu pflegen, Änderungen anzuwenden und Läufe zu steuern. Das positioniert Dagu auch für agentische Abläufe, ohne dass daraus eine Aussage über Reifegrad oder Grenzen dieses Teils ableitbar wäre.
Installation und erster Start
Das README listet mehrere Wege. Auf macOS und Linux installiert ein Skript von raw.githubusercontent.com, unter Homebrew genügt `brew install dagu`, über npm läuft `npm install -g --ignore-scripts=false @dagucloud/dagu`, unter Windows ein PowerShell-Skript. Für Container gibt das README folgendes Beispiel:
docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 ghcr.io/dagucloud/dagu:latest dagu start-all
Der Unterbefehl `dagu start-all` startet demnach Web-Oberfläche und Scheduler zusammen. Der Hinweis im README, dass dieser Befehl den Docker-Daemon des Hosts nicht freigibt, markiert eine praktische Grenze: Workflows, die Docker-Schritte ausführen, brauchen zusätzlich Zugriff auf den Daemon, etwa über einen eingebundenen Socket. Wer diesen Schritt überspringt, wird beim ersten Container-Workflow einen Fehler sehen und nicht sofort wissen, wo er herkommt.
Für Kubernetes existiert ein Helm-Chart, das an der Versionsnummer `helm-dagu-2.0.4` erkennbar ist. Eine API ist dokumentiert, die Spezifikation liegt unter `api/v1/api.yaml` und ist über den Swagger-Editor aufrufbar. Eine Demo-Instanz mit den Zugangsdaten `demouser` wird im README verlinkt. Alles Weitere zur Konfiguration steht laut README in der Dokumentation unter docs.dagu.sh, nicht im Repository-Auszug. Wer Dagu bewertet, sollte diesen Teil zuerst lesen, weil er hier nicht belegt werden kann.
Grenzen, die man vorher kennen sollte
Die erste Einschränkung ist die Zustandsablage in Dateien. Sie ist der Grund für den geringen Betriebsaufwand, aber sie skaliert anders als ein Datenbankserver. Das README nennt Worker, die Ausführung über Maschinen verteilen, ohne zu beschreiben, wie der dateibasierte Zustand zwischen ihnen abgeglichen wird. Diese Frage bleibt offen und ist die wichtigste vor einem Einsatz mit mehreren Knoten.
Die zweite Einschränkung betrifft die Art der Abläufe. Dagu ergänzt vorhandene Automatisierung um Abhängigkeiten, Wiederholungen und Historie. Es ist kein Ersatz für dauerhaft laufende Prozesse mit SDK-Anbindung, und das README beansprucht das auch nicht. Wer Geschäftslogik in einem Programmiermodell mit garantierter Wiederaufnahme nach Abstürzen braucht, wird mit YAML über Skripten nicht glücklich.
Die dritte Einschränkung ist die Lizenz. Dagu steht unter GPL-3.0. Für den internen Betrieb ist das in der Regel unkritisch. Wer Dagu jedoch zusammen mit eigener Software ausliefern will, muss die Bedingungen der GPL-3.0 prüfen, insbesondere die Frage, ob eine abgeleitete Gesamtverteilung entsteht. Das ist keine Rechtsberatung, sondern ein Hinweis darauf, dass dieser Punkt vor einer Produktentscheidung mit der Rechtsabteilung zu klären ist.
Viertens: Die Angaben zur Leistungsfähigkeit bleiben qualitativ. Das README nennt Größenordnungen, aber keine Messungen unter definierten Bedingungen. Wer belastbare Zahlen braucht, bekommt sie hier nicht.
Abgrenzung zu Airflow und Temporal
Der Unterschied zu Airflow liegt nicht im Funktionsumfang, sondern im Betriebsmodell. Airflow verlangt nach der Darstellung im README einen Scheduler, eine Metadatenbank, Worker und eine Python-Umgebung, und die Jobs werden als `@dag`- und `@task`-Code geschrieben. Dagu setzt dagegen auf Konfiguration: Die Ablaufstruktur liegt in YAML, die Ausführung erfolgt in einem Prozess, und die Skripte bleiben unverändert. Für Teams ohne Plattformbetrieb ist das der entscheidende Unterschied. Für Teams, die Airflow bereits mit ausgebildetem Betrieb betreiben, fällt dieser Vorteil weg, während die geringere Funktionsbreite bleibt.
Temporal verfolgt einen anderen Ansatz. Es bietet durable Execution, verlangt aber, dass die Geschäftslogik in sein SDK und sein Programmiermodell wandert. Dagu tut das Gegenteil: Es lässt die Logik in den Skripten und beschreibt nur deren Anordnung. Wer Wiederaufnahme nach Prozessabbrüchen auf Ebene einzelner Logikschritte braucht, ist bei Temporal besser aufgehoben. Wer lediglich möchte, dass ein fehlgeschlagener Lauf wiederholt und protokolliert wird, kommt mit Dagu aus.
Gegenüber Cron ist der Unterschied am deutlichsten: Cron kennt weder Abhängigkeiten zwischen Schritten noch Wiederholungen oder Historie. Dagu setzt genau dort an und lässt die Befehle selbst unangetastet.
Pflegeaufwand und Aktualisierung
Die Release-Historie im Repository zeigt einen kurzen Takt: v2.16.2 am 2. September 2026, v2.16.3 und das Helm-Chart helm-dagu-2.0.4 am 9. September 2026. Das spricht für aktive Pflege, bedeutet aber auch, dass die Hauptversion groß genug ist, um Breaking Changes in Nebenversionen nicht auszuschließen. Wer Dagu produktiv einsetzt, sollte die Release Notes vor jedem Sprung lesen, statt automatisch zu aktualisieren.
Der Aufwand für Aktualisierungen ist strukturell gering, weil keine Datenbank migriert werden muss und das Zustandsformat in Dateien liegt. Das ist ein realer Vorteil gegenüber Systemen mit Schemamigrationen. Es verlagert die Sorgfalt allerdings auf die Frage, ob sich das Format der Dateien zwischen Versionen ändert. Dazu macht der vorliegende Auszug keine Angabe. Wer auf Nummer sicher gehen will, sichert das Verzeichnis `~/.dagu` vor einem Update, weil dort im Docker-Beispiel der Zustand liegt.
Das Helm-Chart trägt eine eigene Versionsnummer und wird getrennt vom Binary veröffentlicht. Beide Linien müssen beim Betrieb im Cluster zusammenpassen. Das ist ein zusätzlicher Punkt auf der Prüfliste, den reine Binärinstallationen nicht haben.
Redaktionelles Fazit
Dagu passt zu kleinen und mittleren Teams, die vorhandene Skripte mit Zeitplan, Wiederholungen und Protokollansicht versehen wollen, ohne eine Plattform zu betreiben, und zu Umgebungen ohne externe Dienste. Wer verteilte, dauerhaft laufende Geschäftslogik mit SDK-Anbindung braucht, sollte bei Temporal bleiben, und wer bereits Airflow mit ausgebildetem Betriebsteam fährt, hat wenig Grund zu wechseln. Vor der Einführung ist zu prüfen, ob die GPL-3.0-Lizenz zum eigenen Verteilungsmodell passt, wie sich die Dateiablage unter Last verhält und ob die im Repository dokumentierten Aktionen für die eigenen Ziele ausreichen. Der erste konkrete Schritt ist ein `dagu start-all` gegen ein Verzeichnis mit einem einzigen YAML-Workflow.
Community-Notizen