Dagger : la stack logicielle qui veut remplacer les scripts de votre CI

Dagger est un moteur open source créé par Solomon Hykes, Andrea Luzzardi et Sam Alba, trois anciens de Docker. Il remplace les fichiers YAML et les scripts shell des pipelines d'intégration continue par des fonctions écrites en Go, Python, TypeScript, Java, PHP ou Rust, exécutées dans des conteneurs par un moteur qui met en cache chaque opération et trace chaque exécution. Lancé publiquement le 30 mars 2022 avec 20 millions de dollars levés auprès de Redpoint Ventures¹, le projet en est à la version 0.21.9, publiée le 26 août 2026². Le 15 septembre 2026, Hykes a annoncé la 1.0 pour bientôt³.

D'où vient Dagger

Solomon Hykes quitte Docker en 2018, cinq ans après y avoir lancé le conteneur qui porte le nom de l'entreprise. Il retrouve Andrea Luzzardi et Sam Alba, avec qui il a travaillé près de dix ans, et les trois démarrent Dagger en 2019 ; Hykes décrira plus tard le projet comme un bricolage des confinements devenu startup⁴. 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 vrai code. En octobre 2022, l'équipe publie un SDK Go sous le titre « Your CI pipelines should be code », suivi en novembre des SDK Python et Node.js et d'une API GraphQL commune ; le SDK CUE est abandonné en décembre 2023⁵. Dagger Cloud, premier produit commercial, ouvre en accès anticipé le 26 septembre 2023. Dagger Functions, en février 2024, transforme chaque tâche de pipeline en fonction réutilisable, et le Daggerverse, un mois plus tard, les indexe. Le dépôt GitHub passe les 10 000 étoiles le 29 mars 2024 ; l'entreprise obtient sa certification SOC 2 Type II en mai 2024⁶. En 2025 arrivent les SDK Java et PHP, un shell interactif, un type LLM natif et un outil pour faire tourner des agents de code en parallèle dans des conteneurs. En 2026, l'équipe remplace le cœur du moteur, ajoute un lockfile et lance des moteurs managés dans son cloud².

Ce que Dagger remplace concrètement

Un pipeline classique combine deux couches : un fichier YAML propre à la plateforme (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) et une pile de scripts shell qu'il appelle. Hykes décrit le résultat depuis 2022 : personne ne peut exécuter le pipeline sur son poste, on pousse un commit vers une boîte noire et on attend de savoir si on s'est trompé, et la personne désignée « DevOps » passe ses journées à coller des outils entre eux⁷.

Avec Dagger, vous écrivez des fonctions dans votre langage. Chaque fonction est une tâche : compiler, tester, publier une image, déployer. Le code construit des conteneurs par appels d'API et le moteur les exécute.

import dagger
from dagger import dag, function, object_type

@object_type
class MonApp:
    @function
    async def test(self, source: dagger.Directory) -> str:
        return await (
            dag.container()
            .from_("python:3.12")
            .with_directory("/src", source)
            .with_workdir("/src")
            .with_exec(["pip", "install", "-e", "."])
            .with_exec(["pytest"])
            .stdout()
        )

La commande dagger call test --source=. exécute cette fonction sur le poste du développeur. La même commande, placée dans le YAML de la plateforme de CI, remplace la pile de scripts. La plateforme se réduit à un déclencheur ; la logique vit dans le dépôt, versionnée, testable et réutilisable d'un projet à l'autre.

Moteur, graphe, cache, traces

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. Il 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, publiée le 1^er octobre 2025, le moteur démarre avec Docker, Podman, nerdctl, Finch ou l'outil container d'Apple⁸.

La version 0.21 du 22 mai 2026 marque le plus gros changement depuis l'origine du projet. Sous le nom de code Theseus, l'équipe a retiré BuildKit, le solveur hérité de Docker qui exécutait les opérations de conteneurs, et l'a remplacé, opération par opération pendant plus d'un an, par son propre moteur. 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 .dagger/lock, un lockfile qui fige les tags d'images, les branches Git et les téléchargements HTTP à leurs valeurs résolues : le pipeline se reproduit à l'identique ou échoue avec un message clair. Un mode --lock=frozen refuse toute dépendance non verrouillée².

Les verbes standard : check, generate, up

Trois commandes structurent un dépôt « daggerisé ». dagger check, arrivé en novembre 2025, lance toutes les vérifications d'un projet, en local, en CI ou depuis un agent, avec un filtre par motif et un mode --failfast ajouté en avril 2026 pour renvoyer la première erreur à un agent sans attendre la fin de la suite. dagger generate, en 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, en avril 2026, démarre tous les services d'un workspace en parallèle, avec tunnels de ports et health checks².

Les fonctions se partagent sous forme de modules. Le Daggerverse en indexe les versions publiques ; Dagger Cloud propose un catalogue privé par organisation. Une refonte, Modules v2, est en développement : un fichier dagger.toml à la racine du projet déclare les modules utilisés, un lockfile fige leurs versions, et un objet Workspace typé donne aux modules une vue de la structure du projet².

Dagger et les agents de code

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 n'importe quelle étape de pipeline⁹. Le 14 juin 2025, elle publie Container Use, qui fait tourner plusieurs agents de code en parallèle, chacun dans son conteneur et sa branche Git¹⁰. En août 2025 suit « Evals as Code », qui applique les mécanismes de cache et de traces aux évaluations de modèles¹¹.

En janvier 2026, Hykes recentre la documentation sur la livraison logicielle et retire le tutoriel « construire un agent », qu'il juge source de confusion¹². Le message de 2026 est ailleurs : la page d'accueil de dagger.io propose un prompt à coller dans son agent de code pour installer Dagger sur un dépôt, faire tourner les vérifications en local, observer le cache, puis brancher Cloud Checks¹³. Dagger se présente comme la couche d'exécution que les agents appellent ; la construction d'agents passe au second plan.

L'offre cloud et le 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. Le plan individuel est gratuit, le plan équipe coûte 50 dollars par mois jusqu'à dix utilisateurs, et le plan entreprise (SSO, déploiement mono-tenant, support 24/7) se négocie¹⁴.

Deux services en accès anticipé changent la portée du produit. Cloud Engines, annoncé en mars 2026, exécute les pipelines sur des moteurs managés, avec cache distribué : dagger --cloud envoie le calcul dans le cloud tout en gardant secrets, fichiers et terminal locaux. 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 ce que Hykes appelle « la stack logicielle manquante de la CI », et c'est l'arrière-plan de son texte du 15 septembre 2026, que nous analysons dans l'article compagnon « Solomon Hykes annonce le grand goulot d'étranglement de la CI en 2026 ».

Ce qu'il faut savoir avant d'adopter

Tout s'exécute dans des conteneurs : chaque poste et chaque runner a besoin d'un runtime, et les projets qui dépendent d'un accès direct à la machine demandent une adaptation. L'API reste en 0.x et le changelog annonce des dépréciations à chaque version : la prochaine remplace GitRef.commit par GitRef.commitSHA². 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, lui, reste celui de votre équipe.

Hykes lui-même situe 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'a pas besoin de Dagger.

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 vu Dagger publier un guide de migration pour ses utilisateurs en avril 2025¹⁶.

Les cas publiés donnent des ordres de grandeur, tous déclarés par l'éditeur ou ses clients : Airbyte annonçait en octobre 2023 des pipelines deux fois plus rapides pour une facture réduite de 75 %¹⁷ ; Puzzle, Craft CMS, Safespring et Lunar ont documenté leurs migrations. Le changelog annonce la prochaine version pour septembre 2026 et Hykes promet la 1.0 dans la foulée. Quatre ans et demi après la 0.2, le pari se mesurera au nombre d'équipes qui débranchent leur plateforme de CI comme Dagger l'a fait pour la sienne.

Sources

1. Dagger, « Introducing Dagger: a new way to create CI/CD pipelines » et « Announcing our $20M Series A from Redpoint Ventures », 30 mars 2022. dagger.io ; dagger.io
2. Dagger, changelog (versions 0.19 à 0.21.9, Project Theseus, lockfile, check/generate/up, Modules v2, Cloud Engines, Cloud Checks), relevé le 16 septembre 2026. dagger.io/changelog
3. Solomon Hykes, « The Great CI Bottleneck of 2026 », 15 septembre 2026. LinkedIn ; X
4. Heavybit, The Kubelist Podcast ep. 37, « Dagger with Solomon Hykes », 28 juin 2023 (heavybit.com) ; Open Source Ready ep. 17, « AI Native Software Factories with Solomon Hykes » (heavybit.com).
5. Dagger, « Your CI pipelines should be code: introducing the Dagger Go SDK », 25 octobre 2022 (dagger.io) ; « Introducing the Dagger GraphQL API », 17 novembre 2022 (dagger.io) ; « Ending Support for the Dagger CUE SDK », 18 décembre 2023 (dagger.io).
6. Dagger, « Dagger Cloud Early Access », 26 septembre 2023 ; « Introducing Dagger Functions », 28 février 2024 ; « Introducing the Daggerverse », 12 mars 2024 ; « To 10K Stars and Beyond! », 29 mars 2024 ; « Dagger Successfully Completed SOC 2 Audit », 24 mai 2024. dagger.io
7. « Solomon Hykes: Dagger Brings the Promise of Docker to CI/CD », The New Stack, 2022. thenewstack.io
8. Dagger, « Dagger 0.19: performance, new APIs, build-an-agent! », 1^er octobre 2025. dagger.io
9. Dagger, « Agents in your Software Factory: Introducing the LLM Primitive in Dagger », 23 avril 2025. dagger.io
10. Dagger, « Containing Agent Chaos: Run Coding Agents in Parallel without Destroying Everything », 14 juin 2025. dagger.io
11. Dagger, « Evals as Code: CI for LLMs with Dagger », 4 août 2025. dagger.io
12. GitHub, dagger/dagger, PR #11670 « Docs: refocus », 12 janvier 2026. github.com
13. Dagger, page d'accueil, relevée le 16 septembre 2026. dagger.io
14. Dagger, page tarifs, relevée le 16 septembre 2026. dagger.io/pricing
15. Dagger, « Dagger ❤️ Depot », 15 janvier 2025. dagger.io
16. Dagger, « A Soft Landing for Earthly Users », 16 avril 2025. dagger.io
17. Dagger, « Dagger Cloud: Going 100% Faster, Spending 75% Less », 25 octobre 2023 (chiffres déclarés par Airbyte). dagger.io