Dagger

Origine : trois anciens de Docker

Dagger est un moteur open source qui exécute les pipelines d'intégration continue sous forme de code. Il a été créé par Solomon Hykes, Andrea Luzzardi et Sam Alba, trois anciens de Docker. Hykes quitte Docker en 2018 ; les trois, qui ont travaillé ensemble près de dix ans, démarrent le projet en 2019. Le 30 mars 2022, ils publient Dagger 0.2 (nom de code Europa) et annoncent une série A de 20 millions de dollars menée par Redpoint Ventures.

La première version s'écrivait en CUE, un langage de configuration. Les utilisateurs demandaient du code : un SDK Go sort en octobre 2022, suivi en novembre des SDK Python et Node.js et d'une API GraphQL commune ; le SDK CUE est abandonné en décembre 2023. Viennent ensuite Dagger Cloud en accès anticipé (26 septembre 2023), Dagger Functions (février 2024), le Daggerverse (mars 2024), une certification SOC 2 Type II (mai 2024), puis en 2025 les SDK Java et PHP, un shell interactif et un type LLM natif. Le 26 août 2026, le projet en est à la version 0.21.9 ; le 15 septembre 2026, Hykes annonce une 1.0 pour bientôt, première version stable après quatre ans et demi de versions 0.x.

Ce que Dagger remplace, et comment le moteur tourne

Un pipeline classique combine un fichier YAML propre à la plateforme (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) et une pile de scripts shell qu'il appelle. Personne ne peut l'exécuter sur son poste ; on pousse un commit et on attend le verdict. Avec Dagger, chaque tâche (compiler, tester, publier une image, déployer) est une fonction écrite en Go, Python, TypeScript, Java, PHP ou Rust, qui construit des conteneurs par appels d'API. La commande dagger call exécute la fonction sur le poste du développeur ; la même commande, placée dans le YAML de la plateforme, remplace la pile de scripts. La plateforme se réduit à un déclencheur, et la logique vit dans le dépôt, versionnée, testable et réutilisable d'un projet à l'autre.

La CLI envoie des requêtes GraphQL au Dagger Engine, un démon qui tourne dans un conteneur. Le moteur construit un graphe orienté acyclique des opérations (partir d'une image, monter un répertoire, exécuter une commande, exporter un fichier), exécute les branches indépendantes en parallèle, met en cache chaque nœud à partir du contenu de ses entrées et réutilise ce cache d'un run au suivant. Chaque exécution émet des traces OpenTelemetry, lisibles dans le terminal ou dans Dagger Cloud. Depuis la version 0.19 (septembre 2025), le moteur démarre avec Docker, Podman, nerdctl, Finch ou l'outil container d'Apple.

La version 0.21 du 22 mai 2026 (nom de code Theseus) retire BuildKit, le solveur hérité de Docker qui exécutait les opérations de conteneurs, remplacé opération par opération pendant plus d'un an par un moteur maison. Le nouveau cache repose sur des e-graphs, une structure issue de la recherche sur l'optimisation des compilateurs, qui suit les équivalences entre opérations pour augmenter le taux de hits. La même version introduit un lockfile, .dagger/lock, qui fige les tags d'images, les branches Git et les téléchargements HTTP à leurs valeurs résolues ; un mode --lock=frozen refuse toute dépendance non verrouillée.

Verbes standard, modules et agents de code

Trois commandes structurent un dépôt « daggerisé ». dagger check (novembre 2025) lance toutes les vérifications d'un projet, en local, en CI ou depuis un agent ; un mode --failfast, ajouté en avril 2026, renvoie la première erreur sans attendre la fin de la suite. dagger generate (février 2026) exécute les générateurs de code et de configuration, et dagger check échoue si un fichier généré a dérivé de sa source. dagger up (avril 2026) démarre les services d'un workspace en parallèle, avec tunnels de ports et health checks. Les fonctions se partagent en modules : le Daggerverse indexe les versions publiques, Dagger Cloud propose un catalogue privé par organisation, et une refonte, Modules v2 (fichier dagger.toml, lockfile, objet Workspace typé), est en développement.

Le 23 avril 2025, l'équipe ajoute un type LLM au cœur de l'API : un agent reçoit un environnement sandboxé et les fonctions Dagger comme outils, et le moteur trace chacun de ses appels comme une étape de pipeline. Le 14 juin 2025 suit Container Use, qui fait tourner plusieurs agents de code en parallèle, chacun dans son conteneur et sa branche Git, puis « Evals as Code » en août 2025, qui applique cache et traces aux évaluations de modèles. En janvier 2026, Hykes recentre la documentation sur la livraison logicielle et retire le tutoriel « construire un agent ». Depuis, Dagger se présente comme la couche d'exécution que les agents de code appellent : la page d'accueil propose un prompt à coller dans son agent pour installer Dagger sur un dépôt, lancer les vérifications en local, observer le cache, puis brancher Cloud Checks.

Offre cloud et modèle économique

Le moteur, la CLI et les SDK sont open source. Dagger Cloud vend la visibilité et l'infrastructure : traces, historique des runs, catalogue de modules. En septembre 2026, le plan individuel est gratuit, le plan équipe coûte 50 dollars par mois jusqu'à 10 utilisateurs, et le plan entreprise (SSO, déploiement mono-tenant, support 24/7) se négocie.

Deux services en accès anticipé élargissent la portée du produit. Cloud Engines (mars 2026) exécute les pipelines sur des moteurs managés avec cache distribué : dagger --cloud envoie le calcul dans le cloud en gardant secrets, fichiers et terminal en local. Cloud Checks se connecte au fournisseur Git et lance dagger check à chaque changement sur ces moteurs. L'équipe le présente comme un remplacement complet de la plateforme de CI et indique avoir débranché GitHub Actions pour sa propre CI. C'est l'arrière-plan du texte de Hykes du 15 septembre 2026 sur le goulot d'étranglement de la CI, analysé sur ce site.

Avant d'adopter

Tout s'exécute dans des conteneurs : chaque poste et chaque runner a besoin d'un runtime, et un projet qui dépend d'un accès direct à la machine demande une adaptation. L'API reste en 0.x et le changelog annonce des dépréciations à chaque version ; la 1.0 promise devrait stabiliser cette surface. La courbe d'apprentissage porte sur l'API et sur la façon de penser un pipeline comme un graphe, le langage restant celui de l'équipe. L'histoire de l'outil, son fonctionnement et ses limites sont détaillés dans un article dédié.

Hykes situe lui-même la cible : une équipe qui livre depuis un moment, qui vient d'embaucher son premier DevOps à temps plein ou dont un développeur passe la moitié de son temps sur l'outillage. Une équipe de trois personnes qui a configuré sa CI une fois et n'y touche plus n'en a pas besoin. Les cas publiés restent des chiffres d'éditeur : Airbyte annonçait en octobre 2023 des pipelines deux fois plus rapides pour une facture réduite de 75 %. Les alternatives couvrent d'autres angles :

• Bazel et Buck2 gèrent le build des monorepos avec un cache exact, Nix garantit la reproductibilité des environnements ; Hykes objecte que les deux finissent enveloppés dans des scripts shell pour couvrir le reste du pipeline.
• Depot accélère les runners GitHub Actions et s'intègre à Dagger depuis janvier 2025.
• Earthly, le concurrent le plus proche dans l'approche, a fait l'objet d'un guide de migration publié par Dagger en avril 2025.