Dagger vs. Earthly: Portable CI/CD Pipelines im Vergleich 2026

"Es funktioniert auf meinem Rechner" ist das alte Problem der Softwareentwicklung. "Es funktioniert nur in GitLab CI" ist das neue Problem vieler DevOps-Teams. Pipeline-Definitionen sind tief in CI-Plattform-spezifische YAML-Formate eingebettet, reproduzierbare lokale Builds sind schwierig, und der Wechsel zu einem anderen CI-System bedeutet, alles neu zu schreiben.

Dagger und Earthly gehen dieses Problem von unterschiedlichen Seiten an: Beide schaffen eine portable Abstraktionsschicht über CI-Systemen, die lokale und cloud-basierte Ausführung vereinheitlicht. Dieser Vergleich zeigt, welches Tool für welchen Einsatzfall besser geeignet ist.

Was ist Earthly?

Earthly ist ein Build-Tool, das Dockerfile-Syntax mit Makefile-ähnlicher Taskverkettung kombiniert. Die Konfiguration erfolgt in einem Earthfile, der ähnlich wie ein Dockerfile strukturiert ist, aber auch Abhängigkeiten zwischen Targets und externe Imports unterstützt.

Earthly läuft lokal via Docker und in jedem CI-System als normaler Schritt. Das Ergebnis: derselbe Earthfile funktioniert auf dem Entwickler-Laptop genauso wie in GitHub Actions oder GitLab CI.

Earthly Grundstruktur

# Earthfile
VERSION 0.8
FROM alpine:3.20

# Build-Stage
build:
    COPY src/ ./
    RUN go build -o app ./cmd/server
    SAVE ARTIFACT app /app AS LOCAL ./dist/app

# Test-Stage  
test:
    FROM +build
    RUN go test ./...

# Docker Image bauen
docker:
    COPY +build/app /app
    ENTRYPOINT ["/app"]
    SAVE IMAGE --push registry.example.com/myapp:latest

# CI-Integration (alle Stages zusammen)
ci:
    BUILD +test
    BUILD +docker

# Lokal ausführen
earthly +test        # Nur Tests
earthly +docker      # Image bauen
earthly +ci          # Kompletter CI-Lauf

Earthly-Features

  • Caching: Layer-basiertes Caching wie Docker, aber für gesamte Build-Stages
  • Remote-Caching: Geteilter Cache via Registry (OCI) oder Earthly-Cloud
  • Monorepo-Support: Abhängigkeiten zwischen Projekten innerhalb eines Repos
  • Secrets: Via RUN --secret VAR=+secrets/VAR direkt aus Secret-Store
  • Earthly Satellites: Managed Remote-Build-Runner in Earthly-Cloud

Was ist Dagger?

Dagger ist eine Platform für programmatische CI/CD-Pipelines. Statt YAML-Konfiguration werden Pipelines in echten Programmiersprachen definiert: Go, Python, TypeScript oder Java. Dagger läuft auf einer container-basierten Runtime (BuildKit) und bietet eine SDK-Abstraktion für CI-Aktionen.

Der zentrale Unterschied zu Earthly: Dagger ist keine Domain-Specific Language – es ist echte Programmierlogik mit Schleifen, Bedingungen und Modulen.

Dagger-Pipeline in TypeScript

import { dag, Container, Directory, object, func } from "@dagger.io/dagger"

@object()
class MyPipeline {
  @func()
  async build(source: Directory): Promise<Container> {
    return dag
      .container()
      .from("golang:1.22-alpine")
      .withDirectory("/src", source)
      .withWorkdir("/src")
      .withExec(["go", "build", "-o", "/app", "./cmd/server"])
  }

  @func()
  async test(source: Directory): Promise<string> {
    return dag
      .container()
      .from("golang:1.22-alpine")
      .withDirectory("/src", source)
      .withWorkdir("/src")
      .withExec(["go", "test", "./..."])
      .stdout()
  }

  @func()
  async publish(source: Directory, tag: string): Promise<string> {
    const built = await this.build(source)
    return dag
      .container()
      .from("alpine:3.20")
      .withFile("/app", built.file("/app"))
      .withEntrypoint(["/app"])
      .publish(`registry.example.com/myapp:${tag}`)
  }
}

# Lokal ausführen
dagger call test --source=.
dagger call publish --source=. --tag=v1.2.3

Dagger-Features

  • SDK-Support: Go, Python, TypeScript, Java, PHP – mehr in Entwicklung
  • Dagger Modules: Wiederverwendbare Pipeline-Komponenten (ähnlich npm-Pakete)
  • DAG-Ausführung: Automatische Parallelisierung unabhängiger Schritte
  • Dagger Cloud: Remote-Caching, Visualisierung, observability
  • Terminal-API: Interaktives Debugging von Pipeline-Schritten
  • LLM-Integration: KI-gestützte Pipeline-Generierung (experimentell)

Dagger vs. Earthly: Direkter Vergleich

Kriterium Dagger Earthly
Konfigurationssprache Go, Python, TypeScript, Java Earthfile (Dockerfile-Syntax)
Lernkurve Hoch (SDK-Kenntnisse erforderlich) Niedrig (Dockerfile-Kenntnisse reichen)
Lokale Ausführung Ja (Docker erforderlich) Ja (Docker erforderlich)
Caching BuildKit-Layer-Cache Layer-Cache + Remote-Cache
CI-Integration Beliebiges CI via CLI Beliebiges CI via CLI
Monorepo-Support Gut Sehr gut
Modularisierung Dagger Modules (stark) Imports (begrenzt)
Remote-Execution Dagger Cloud Earthly Satellites
Preis Open Source + Cloud (Free-Tier) Open Source + Cloud (Free-Tier)
Debugging Interaktiver Terminal Standard Docker-Ausgabe
Reifegrad v0.12+ (produktionsreif) v0.8 (stabil)

Portabilität in der Praxis

Beide Tools erfüllen das Versprechen der CI-Portabilität. Hier ein Vergleich, wie derselbe Build in verschiedenen CI-Systemen aussieht:

Earthly in GitHub Actions

# .github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: earthly/actions-setup@v1
      - run: earthly +ci

Dagger in GitHub Actions

# .github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Dagger Pipeline
        uses: dagger/dagger-for-github@v6
        with:
          verb: call
          args: ci --source=.

Dieselben Befehle in GitLab CI

# .gitlab-ci.yml (Earthly)
ci:
  image: earthly/earthly:v0.8
  script:
    - earthly +ci

# .gitlab-ci.yml (Dagger)
ci:
  image: registry.dagger.io/engine:v0.12
  script:
    - dagger call ci --source=.

Caching-Strategien

Caching ist der Hauptvorteil beider Tools gegenüber nativen CI-Caching-Mechanismen.

Earthly Remote-Cache

# Earthfile
build:
    CACHE --persist /go/pkg/mod
    RUN go build ./...

# Mit Remote-Cache (OCI-Registry)
earthly --remote-cache=registry.example.com/cache:latest +build

Dagger Cache Volumes

// Go SDK
cacheVolume := dag.CacheVolume("go-modules")
container.WithMountedCache("/go/pkg/mod", cacheVolume)

Dagger Modules (das Paket-Ökosystem für wiederverwendbare Pipeline-Komponenten) ergänzen das Caching mit vorgebauten Cache-Strategien für gängige Sprachen.

Wann Earthly die bessere Wahl ist

Earthly eignet sich, wenn:

  • Das Team Dockerfile-Kenntnisse hat und eine flache Lernkurve wichtig ist
  • Monorepos mit vielen Targets und Abhängigkeiten verwaltet werden
  • Die Pipeline-Logik einfach und deklarativ bleiben soll
  • Teams aus der Docker-Welt kommen und denselben mentalen Rahmen beibehalten wollen
  • Remote-Caching schnell und ohne SDK-Kenntnisse eingerichtet werden soll

Wann Dagger die bessere Wahl ist

Dagger lohnt sich, wenn:

  • Komplexe Pipeline-Logik (Schleifen, Conditionals, dynamische Targets) benötigt wird
  • Teams Go, Python oder TypeScript bereits beherrschen und Pipeline-Code wie regulären Code behandeln wollen
  • Modularisierung wichtig ist: wiederverwendbare Pipeline-Bausteine über Projekte hinweg
  • Debugging kritisch ist: Dagger's interaktiver Terminal ist ein erheblicher Vorteil bei komplexen Pipelines
  • Die Organisation in Richtung Platform Engineering mit standardisierten CI-Modulen geht

Integration mit bestehender Kubernetes-Infrastruktur

Beide Tools integrieren sich gut in Kubernetes-basierte CI/CD-Pipelines:

# Dagger auf einem Kubernetes-Cluster ausführen (experimentell)
dagger call build --source=. --platform=linux/arm64

# Earthly mit Kubernetes-Build-Node
earthly --buildkit-host kube-pod://buildkitd.build-system.svc.cluster.local +build

Für GitOps-Workflows mit ArgoCD oder Flux CD sind beide Tools ideal: Sie produzieren reproduzierbare Container-Images mit deterministischen Tags.

Fazit

Earthly ist die pragmatische Wahl: schneller Einstieg, Dockerfile-vertraute Syntax, starkes Monorepo-Caching. Wer CI-YAML loswerden will, ohne eine neue Programmiersprache zu lernen, liegt mit Earthly richtig.

Dagger ist der richtige Schritt für Teams, die Pipeline-Code wie regulären Anwendungscode behandeln wollen: versioniert, getestet, modular. Die höhere Einstiegshürde zahlt sich aus, sobald Pipelines komplex werden oder über viele Projekte standardisiert werden sollen.

Beide Tools lösen das Problem der CI-Vendor-Lock-in – die Wahl hängt von der Teamexpertise und dem gewünschten Abstraktionsniveau ab.

Weiterführende Artikel

Verwandte Technologien im Techradar