Dagger 1.0 Beta: CI for Coding Agents, Pricing and Migration

Dagger released its 1.0 beta on October 23, 2026, adding official modules, test-level CI, remote execution and direct GitHub integration. It targets the feedback loop around coding agents: checking a change, understanding a failure and trying again without repeatedly rebuilding the same context.

The useful question is how much work an agent has to repeat after a failed test. Faster code generation helps less when every small correction starts another slow, opaque CI run.

What changed in Dagger 1.0 beta

The release announcement introduces maintained modules for tools including Go, pytest, ESLint and Playwright. These read existing project configuration rather than requiring every team to write its own integration.

Workspaces provide a repository-level place to configure those modules. Pipelines run as a graph of sandboxed functions, locally or on a remote engine. Dagger Cloud can also receive GitHub events and report checks directly, without a GitHub Actions workflow for those checks.

This is a beta, not the stable 1.0 release. Dagger is asking users to test compatibility against their own repositories. Treat the announcement as an invitation to evaluate a new CI workflow, rather than a reason to replace a working production setup overnight.

Why individual tests matter for coding agents

Dagger's checking documentation describes a useful level of control. dagger check runs workspace checks in parallel and returns a non-zero exit status when any fails. Filters can select checks by module, package or individual test.

You can list discovered checks with dagger check -l --all, then rerun a narrower selection. By default, all checks run so the results expose multiple failures; --fail-fast stops the remaining work after the first failure.

There is a configuration detail worth checking: a module can appear in the list even when it discovers no matching items. Expanding the list helps reveal that absence. A tool that reports success cannot validate tests it never found.

For an agent fixing a database test, a specific test result gives it a smaller problem to investigate than a general failed-job status. The practical evaluation is whether it can reproduce the failure, make a focused change and validate that change without losing the surrounding checks.

Dagger Cloud pricing

The pricing page bills measured resource usage, with lower rates for repeat operations. Dollar amounts below convert the published cent-based rates.

Resource	New work	Repeat work
CPU	$0.005 per CPU-minute	$0.001 per CPU-minute
Memory	$0.005 per GB-minute	$0.001 per GB-minute
Pipeline inputs	$0.025 per GB	$0.005 per GB
Pipeline outputs	$0.10 per GB	$0.02 per GB

Repeat work means an operation with the same inputs as one run in the previous 30 days. The reduced rate applies even when that operation is not actually served from cache. Idle capacity is not billed.

Starter has a $20 monthly minimum for one user. Scale has a $200 minimum with unlimited users; Enterprise pricing is custom. The bill is the higher of the plan price and usage, not both added together.

The fivefold rate reduction applies to qualifying repeat work. It does not promise that a whole CI bill will fall by that amount. Compare a representative workload, including memory and data movement, rather than multiplying a previous runner bill by a headline discount.

Migrating from Dagger 0.x

The migration guide separates CLI changes from configuration migration. Start with a clean working tree and check the commands your scripts actually use.

dagger.json splits into dagger.toml for the workspace and dagger-module.toml for the module manifest. Preview changes with dagger workspace migrate --no-apply. The guide uses dagger workspace migrate -y to apply them, followed by dagger generate -y and committing the generated files.

Some familiar commands change meaning. dagger shell now opens a container or directory terminal, while dagger init creates a workspace. dagger develop is removed. A configuration file loading successfully is therefore not enough to establish script compatibility.

For a beta trial, keep the existing CI path available while comparing results on the same changes. The meaningful outcome is a shorter path from failure to a verified fix, with no loss of coverage. That is where infrastructure for coding agents has to earn its place.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product launches and engineering decisions into clear stories that developers and founders read and share.

Book a 30-minute call.