CI that keeps up
explainerby Kyle Penfound

Which development tools can Dagger replace or consolidate?

Dagger can replace your CI platform, your hosted runners, and your test splitter for the work that its checks do. It can also replace Testcontainers, because your test code can call Dagger to start its services. It covers part of what CI observability tools and build caches do. Keep your source control, your test frameworks, your secret managers, and your production systems. Dagger can replace several tools because one engine schedules, runs, caches, and traces the work.

Why one engine can replace several tools

A typical CI stack uses a different tool for each part of a run. One tool schedules jobs, another hosts runners, another splits tests, and another stores caches and traces. Each tool knows only its own part.

Dagger does these parts in one engine. Its sandbox, scheduler, container runtime, build cache, and tracing share one execution and data model (dagger.io). The work is a set of checks. A check is a command that verifies your project and passes or fails, such as a test run or a linter (Checking your code). The same checks run on your machine, on your servers, and in Dagger Cloud.

What Dagger replaces, and what it covers in part

Category Example tools With Dagger
CI platform GitHub Actions, CircleCI, Buildkite Replace, for the work of your checks
Hosted runners Blacksmith, Namespace Replace, with Cloud Engines
Test splitting Knapsack Pro, bktec Replace
CI observability Datadog CI Visibility In part, for runs in Dagger
Build caches Depot, cache services In part, for work in Dagger
Test services Testcontainers, Docker Compose Replace
Registries between jobs Docker Hub, ECR, GHCR Not needed between steps
Remote dev environments GitHub Codespaces, Gitpod, Coder, Daytona In part, for shells

Each row is a choice for your team. A tool that does more than the row says, such as dashboards for code that does not run in Dagger, stays.

CI platform and runners

Cloud Checks run your checks on Dagger Cloud after each push and pull request, with no workflow file (Cloud Checks). They run on Cloud Engines, which Dagger Cloud runs for you, with scale-out and a distributed cache (Cloud Engines). For the work that your checks do, you need no CI platform and no hosted runners. Cloud Checks need a GitHub repository.

Test splitting and test results

Dagger sees each test, not only the job that runs it (test-native CI). It splits large test suites across engines, and balances the parts with the measured cost of each test (test splitting). Dagger Cloud shows each test from the trace, with its status, logs, and duration (test-aware CI).

That covers the CI data of the runs in Dagger. An observability tool such as Datadog also covers systems outside Dagger, so keep it where your team uses that data.

Build caches and artifacts between steps

The Dagger engine caches the result of each operation (Introduction). When the inputs of an operation do not change, the engine uses the cached result. Work that runs in Dagger needs no separate cache service. Build caches for work outside Dagger stay.

Steps in Dagger pass containers, files, and services to each other in the engine. A module can take the output of another module as a setting (module wiring). So you do not push an image to a registry only for the next job to pull it. Keep your registry for the images that you publish.

Test services

Dagger replaces Testcontainers. Your test code calls Dagger through a client to start a database or another service, and then tests against it (self-orchestrating tests). You run the tests with your usual test command, under dagger api with-session, and not inside a Dagger module. Dagger publishes a client library for Go, TypeScript, Python, PHP, Java, Elixir, Rust, and .NET (Client libraries). How do I run integration tests against real databases and Kafka without mocks? shows a Go test that starts its own Postgres this way.

The only external dependency of the test is then Dagger, so the test runs the same way on your machine and in CI. Dagger also replaces Docker Compose for services that run next to the tests. dagger start starts the services of your workspace and opens their ports on your machine (Running services).

Remote dev environments

dagger shell opens a shell in a container of your project, and dagger check -i opens one where a command failed (dev shells). Dagger can also run your work on a remote engine, on your servers or on Dagger Cloud (remote execution). That covers a shell in the same environment as CI. It does not replace an editor in the browser or a persistent workspace, so keep a remote dev environment if your team uses those.

What to keep

  • Source control and code review, such as GitHub. Cloud Checks report to GitHub as checks on each pull request.
  • Your test frameworks. Official modules run them with no change to your tests.
  • Your secret managers. Dagger reads secrets from HashiCorp Vault, 1Password, AWS Secrets Manager, and other providers (Secrets).
  • Your production systems, such as your deploy targets and your registry for published images.

Bottom line: Dagger can replace your CI platform, hosted runners, and test splitter for the work that its checks do, and Testcontainers through its clients. It covers part of CI observability, build caches, and remote dev shells. Keep the tools that do more than that, and keep your source control, tests, and secret managers.