Dagu : un moteur de workflows qui refuse d'envoyer vos scripts dans un framework

Le problème visé : des scripts qui marchent, une orchestration qui manque

Le README pose la question sans détour : l'orchestration n'est pas le métier principal de l'équipe visée. Vous avez des scripts shell, des conteneurs Docker, des commandes SSH qui tournent déjà. Ce qui manque, c'est un ordre d'exécution, une reprise sur erreur, un historique consultable. Le projet cible explicitement les équipes d'exploitation et d'automatisation interne, pas les plateformes de données à grande échelle.

Le README écarte trois options avec un argument précis pour chacune. cron exécute mais n'offre ni dépendances, ni reprises, ni historique. Airflow orchestre, mais impose d'exploiter une plateforme complète (planificateur, base de métadonnées, workers, environnement Python) et de réécrire les traitements en code de framework avec les décorateurs @dag et @task. Temporal apporte l'exécution durable, mais déplace la logique métier dans son SDK. La phrase qui résume la position du projet : vous vouliez planifier des tâches, et vous exploitez maintenant un second système.

C'est un argument de coût d'exploitation, pas de performance. Il faut le lire comme tel : Dagu ne prétend pas mieux ordonnancer qu'Airflow, il prétend qu'on peut s'en passer pour un volume modéré.

Un seul processus, un fichier YAML, et l'état sur disque

Le mécanisme tient en une phrase du README : la structure du workflow est de la configuration, pas du code. L'ordre, les dépendances, les reprises, les planifications et les tâches humaines vivent dans un fichier YAML posé à côté des scripts. Le moteur qui les exécute est un processus unique, lancé par dagu start-all, qui regroupe serveur web, planificateur et exécution dans le même binaire.

Le README donne un schéma comparatif volontairement brutal : une pile d'orchestration classique aligne serveur web, planificateur, workers, PostgreSQL, Redis ou RabbitMQ et un runtime Python, soit plus de six services à administrer. En face, une seule case : dagu start-all. L'état est stocké dans des fichiers locaux, ce qui explique l'absence de base externe et permet aux workers de se répartir l'exécution sans coordination par un courtier de messages.

Ce choix a une conséquence directe sur l'intégration. Les scripts n'importent rien. Le README l'affirme : supprimez le YAML, les scripts s'exécutent exactement comme avant. C'est la propriété la plus intéressante du projet, parce qu'elle rend l'adoption réversible. Un DAG peut appeler des commandes shell, des conteneurs Docker, des Jobs Kubernetes ou des commandes distantes en SSH via ce que le projet nomme les Dagu Actions. Les sous-DAG permettent de composer des blocs réutilisables, et des contrôles de concurrence encadrent l'exécution parallèle.

Installation : cinq canaux, un volume à monter

Le README documente cinq voies d'installation. Le script d'installation pour macOS et Linux s'exécute via curl piped vers bash depuis scripts/installer.sh. Homebrew fournit brew install dagu. npm fournit npm install -g --ignore-scripts=false @dagucloud/dagu, avec l'option --ignore-scripts=false explicitement présente, ce qui indique que le paquet a besoin d'exécuter un script de post-installation. Windows passe par PowerShell avec irm vers scripts/installer.ps1.

Le déploiement conteneurisé est celui qui expose le plus clairement le modèle de stockage : docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 ghcr.io/dagucloud/dagu:latest dagu start-all. Le répertoire /var/lib/dagu est le point de montage à retenir, c'est là que vivent l'état et l'historique. Le README signale aussi une limite de cette commande : elle n'expose pas le démon Docker de l'hôte, ce qui veut dire que les étapes qui lancent des conteneurs ne fonctionneront pas telles quelles dans ce mode sans configuration supplémentaire du socket.

Un chart Helm existe sous le nom helm-dagu, publié séparément du binaire avec sa propre numérotation (helm-dagu-2.0.4 face à v2.16.3). Cette séparation des versions est un détail d'exploitation à connaître : mettre à jour le chart et mettre à jour l'image sont deux opérations distinctes.

Planification, reprises et tâches humaines : ce que le YAML porte

Le README liste les capacités de planification sans ambiguïté : syntaxe cron, fuseaux horaires, politiques de chevauchement et fenêtres de rattrapage. La politique de chevauchement mérite l'attention de quiconque vient de cron, où deux exécutions d'un même traitement peuvent se superposer sans que rien ne l'empêche. Les fenêtres de rattrapage traitent le cas classique du serveur éteint pendant l'heure prévue.

Les tâches humaines sont annoncées comme une fonctionnalité de premier plan, avec la mention human-in-the-loop dans les topics du dépôt. Le README les cite aux côtés des reprises et de l'historique comme ce que Dagu ajoute autour de l'automatisation existante. La documentation ne détaille pas dans le README le fonctionnement exact de ces étapes, il faut se référer à docs.dagu.sh pour savoir comment une exécution se met en attente d'une validation.

Le projet embarque aussi un serveur MCP, décrit comme permettant d'inspecter les workflows et les exécutions, de tenir des pages de Wiki, d'appliquer des modifications et de contrôler les exécutions. C'est cohérent avec les topics agentic-workflows et mcp-gateway du dépôt, et cela signifie qu'un agent peut piloter l'orchestrateur. Pour une équipe d'exploitation, cela ouvre une surface d'autorisation supplémentaire qu'il faut traiter comme telle.

Là où Dagu n'est pas le bon outil

Le README est honnête sur le débit : une seule machine peut exécuter des milliers d'exécutions de workflow par jour, la capacité réelle dépendant du processeur, de la mémoire, du disque et de la forme du workflow. Aucun chiffre précis n'est avancé, et il n'y a pas de benchmark publié dans le matériel fourni. Il faut donc considérer cette affirmation comme un ordre de grandeur revendiqué, pas comme une mesure.

La limite structurelle est ailleurs. Un moteur dont l'état vit dans des fichiers locaux change de nature dès qu'on le fait tourner sur plusieurs nœuds : le README mentionne la répartition de l'exécution sur une flotte de workers, mais ne décrit pas dans ce document comment l'état est partagé ou répliqué entre eux. C'est la question à poser avant tout déploiement multi-machine, et le README ne permet pas d'y répondre.

Deuxième cas défavorable : une équipe dont les pipelines sont du Python que plusieurs personnes éditent, testent et versionnent comme du code applicatif. Le pari de Dagu est justement que cette logique reste dans des scripts et que seul l'ordonnancement soit décrit en YAML. Si vos traitements ont besoin de types partagés, de tests unitaires sur les transitions et d'un graphe construit dynamiquement à l'exécution, le YAML devient un obstacle plutôt qu'un gain.

Troisième cas : l'exécution durable au sens strict. Le README oppose Dagu à Temporal sur ce point et assume la différence. Dagu reprend au niveau du workflow et de l'étape, pas au niveau de chaque instruction d'un programme. Un traitement qui doit survivre à un redémarrage au milieu d'une boucle interne n'est pas le terrain de ce projet.

Airflow et Temporal : trois réponses à la même question

La différence avec Airflow n'est pas une question de fonctionnalités mais de frontière entre le code et la configuration. Airflow fait écrire les DAG en Python avec @dag et @task : le graphe est un objet de programme, évalué par le planificateur, et il faut un environnement Python cohérent entre le planificateur et les workers. Dagu place le graphe dans un fichier YAML interprété par un binaire Go. On perd l'expressivité d'un langage complet pour décrire le graphe, on gagne un déploiement qui ne dépend d'aucun runtime applicatif.

Face à Temporal, l'écart porte sur le lieu de la logique métier. Temporal demande de déplacer cette logique dans son SDK et son modèle de programmation, en échange d'une durabilité fine. Dagu laisse la logique dans les scripts et se contente d'orchestrer leur enchaînement. C'est moins puissant et beaucoup moins intrusif.

Face à cron, la comparaison est plus simple : cron n'a ni dépendances, ni reprises, ni historique, comme le rappelle le README. Dagu ajoute ces trois choses sans ajouter de service à administrer. C'est le seul des trois cas où le remplacement est direct et sans coût de réécriture.

Le point commun des trois alternatives est qu'elles déplacent quelque chose : du code vers un framework, de la logique vers un SDK, ou rien du tout vers un fichier de configuration. Dagu se situe dans le troisième cas, et c'est là qu'il faut évaluer s'il vous convient.

Licence, maintenance et coût de mise à jour

Le projet est publié sous GPL-3.0. Pour un usage interne, la question se pose surtout si vous redistribuez Dagu modifié ou si vous l'intégrez dans un produit distribué : la GPL-3.0 impose alors des obligations de publication du code source correspondant. Un déploiement interne qui se contente d'exécuter le binaire n'est pas concerné de la même manière. Ce paragraphe décrit la licence, il ne constitue pas un avis juridique ; faites trancher le cas par votre service compétent si vous redistribuez.

Le rythme de publication est soutenu : v2.16.3 datée du 9 septembre 2026, v2.16.2 une semaine plus tôt, et le chart Helm publié le même jour que la version du binaire. Des correctifs rapprochés en série 2.16.x indiquent des retouches fréquentes sur une branche stable. Pour une équipe qui épingle une version, cela signifie relire les notes de version avant chaque montée, en particulier lorsque le chart Helm et l'image avancent séparément.

Le coût de mise à jour lui-même est faible côté infrastructure : un binaire à remplacer, ou une image à retirer. Il est plus élevé côté format si le schéma YAML évolue, puisque vos DAG sont des fichiers que vous maintenez. Le dépôt n'est pas archivé et la branche par défaut est main. Le README ne donne aucune indication sur une politique de compatibilité ascendante du format YAML entre versions mineures, et c'est un point à vérifier dans la documentation avant de bâtir des dizaines de DAG dessus.

Conclusion éditoriale

Dagu convient aux petites équipes d'exploitation qui ont déjà des scripts et veulent une dépendance, une reprise et un journal sans héberger une plateforme. Il ne convient pas aux équipes dont les pipelines sont du code Python que plusieurs personnes éditent et testent en continu, ni à celles qui ont besoin d'une exécution durable au niveau de chaque instruction. Avant d'adopter, vérifiez dans la documentation la politique de conservation de l'historique, les modes de reprise après une coupure du processus, et la façon dont les identifiants SSH et les secrets Docker sont stockés dans les fichiers d'état locaux.

Sources officielles

1. dagucloud/dagu on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases