Dagger 1.0 beta

TLDR: Dagger is third-generation CI, after Jenkins and GitHub Actions. It is built to match the speed and scale of coding agents without wasting compute or tokens. After five years of v0, Dagger 1.0 is in beta. We need your help testing it before we call it stable. If you tried Dagger before, we’ve been cooking!

Try it now

Why Dagger?

Coding agents can only ship as fast as their CI, and CI is falling behind. In the Great CI bottleneck of 2026, I argued that buying bigger machines won’t fix this: the problem is the CI platform itself.

When you peel off the layers of proprietary YAML and jargon, CI today boils down to running shell scripts on a server, and reading the logs. In the Jenkins days, the server was in a closet. Now, second-generation CI like GitHub Actions uses ephemeral VMs. Either way, with such a primitive execution and data model, waste is everywhere, and it gets worse as you scale:

• The only way to scale is more VMs or bigger VMs, so you over-allocate to absorb peaks, and compute sits idle.
• Shell scripts can’t tell what changed, so your VMs re-compute the same artifacts over and over.
• CI scripts don’t run the same way in the dev environment, if at all, so agents “push and pray”, and burn tokens on every round-trip.
• CI logs are huge, unstructured, and lack context. They don’t tell you which tests failed, how much CPU or memory they used, what environment they ran in (including service dependencies), and how it was built from which inputs. So agents burn tokens reconstructing all that context from text, again and again.

To eliminate this waste, we introduce Dagger, a third-generation CI platform, built to match the speed and scale of coding agents and give them the guardrails and context they need.

Dagger runs every code change — whether machine-generated or handwritten — through the same build and test pipelines, before or after push.

Engineers at Typesafe, Fastly, Nvidia, Fidelity, Nine Entertainment and many others use Dagger to accelerate their feedback loop at scale, without wasting compute or tokens.

How it works

1. Dagger detects your toolchains and recommends official modules for them. You can also write your own.

2. Modules read your native configuration, eliminating proprietary YAML and config drift. They discover your project as typed artifacts: source code, containers, binaries, generated files, and even tests.
3. You select artifacts with typed filters, and use them to automate your feedback loop. For example, use test results as a pre-merge or post-merge gate, run a preview environment, or inspect intermediate results in an interactive shell.
4. Dagger computes artifacts lazily, as an incremental DAG of sandboxed functions, on your machine or on a shared remote engine.

5. Dagger is vertically integrated: sandbox, scheduler, container runtime, build cache and tracing share one execution and data model. This enables it to keep up with coding agents by achieving levels of compute and token efficiency that are out of reach for second-generation CI, where each component is a silo.

What’s new in 1.0

Five years is a long time to stay at 0.x. We spent them practicing “pain-driven development” with our community on Discord, and iterating furiously: from CUE to SDKs, then modules, deep OpenTelemetry tracing, a terminal UI, and finally the replacement of BuildKit. This year we’ve focused on speed, ease of adoption, and offering a complete CI platform. With this work largely done, we have arrived at a stable architecture that meets our bar for “1.0”. We will keep iterating, but on top of this stable foundation.

Here are the highlights. See our changelog for more.

Official modules

The Dagger team now maintains a catalog of official modules. Each module integrates Dagger with a common tool, for example Go, pytest, ESLint or Playwright. Install a module, and you can use its checks immediately. You do not need to write a module yourself. More

Workspaces

Dagger 1.0 introduces workspaces. A workspace is a context in which you configure and run Dagger, usually one Git repository. One simple configuration file, dagger.toml, specifies the modules to load, and other settings. Modules get a new API to access their workspace dynamically. They can load files on demand, find your projects and read their native configuration. More

Much faster

Dagger 1.0 is much faster. We attacked speed from many angles: container execution, file operations, cache persistence, long-tail profiling, SDK codegen, lazy loading. One tester’s reaction: “Wow, 1.0.0 is so snappy.”

• Parallel containers: 1,000 containers at the same time: from 35–61 s to 16–17 s.
• Many files: collect 300 files: from 11.8 s to 1.1 s.

More

Test-native CI

Dagger 1.0 sees each of your tests, not only the job that runs them. Official modules find your tests, run the tests that you select, and report each test separately. When a test fails, you see which test, and you run only that test again. You do not need to change your tests. More

Or you can browse the results interactively:

Self-orchestrating tests

Integration tests need real dependencies, such as a database or an API server. Today a CI job or a docker-compose file sets them up, outside the test, and differently in development and in CI. Dagger adds a new option: a test can call Dagger modules to set up its own dependencies, so that it runs the same way everywhere. More

Dev shells

dagger shell opens a shell in any container that your workspace provides, such as a dev environment, a build container or the container that your tests run in. dagger check -i opens a shell in the exact state where a command failed. Your shell, your CI and your coding agents can share one environment. More

Remote execution

Run any pipeline on a remote engine, on your own infrastructure or on Dagger Cloud. Dagger streams local files, secrets, network tunnels and your terminal as needed, so you can run many agents without melting your machine. Execution is fully sandboxed, so developers, agents and CI can safely pool compute and cache. More

Native GitHub integration

Dagger Cloud can receive events directly from GitHub, run checks on each push, and report status back. This replaces GitHub Actions for your checks: you do not need a CI workflow file, or any other third-party service. To start, run dagger cloud checks on in your repository. More

Transparent usage pricing

Dagger Cloud has a new pricing model: it bills each pipeline’s exact resource usage. Idle capacity is free. Operations that could be served from cache cost 5× less, whether or not they actually are. More

Compatibility

Dagger 1.0 has some breaking changes. The core engine and API remain the same, but many CLI commands have changed. dagger.json is replaced by two files: dagger.toml for workspace configuration, and dagger-module.toml for the module manifest. Some SDKs may require small adjustments in module code. Backwards compatibility or automated migration covers most of these changes, with a few exceptions. See the migration guide.

This is where we need your help the most. We can’t test against your private repositories, so please try 1.0 on a local checkout of your projects, and tell us on Discord what breaks.

Thank you!

This release would not be possible without the constant support and relentless testing of the Dagger community. To all of you, fellow Daggernauts, I say: thank you.

We encourage you to join our Discord and say hi!