Dagger 1.0 beta pitches CI that coding agents can run locally, with dagger.toml replacing dagger.json

Dagger, the CI engine from Docker founder Solomon Hykes, is in 1.0 beta after five years at version 0.x. Hykes calls it “third-generation CI, after Jenkins and GitHub Actions,” built “to match the speed and scale of coding agents without wasting compute or tokens.” It is a beta, and the post asks users to test it before Dagger calls it stable.

The pitch

Hykes argues that coding agents “can only ship as fast as their CI.” In his telling, today’s CI is shell scripts on a server plus logs, so agents “push and pray” and then spend tokens rebuilding context from long, unstructured logs. Dagger’s answer is to run the same pipelines on your machine and in CI, cache what has not changed, and report results as structured data instead of text.

The post even opens with a prompt to paste into your coding agent, asking it to set up Dagger on the repo, run checks locally twice to show the cache, then configure Dagger Cloud.

What is new in 1.0

• Official modules. The Dagger team now maintains modules for common tools, with Go, pytest, ESLint and Playwright as examples. Install one and its checks work without writing a module.
• Workspaces. One dagger.toml per workspace, usually a Git repository, lists the modules to load. Modules can read your project’s native configuration.
• Test-native CI. Official modules find and report each test separately, so a failure names the test and you rerun only that one.
• Self-orchestrating tests. A test can call Dagger modules to start its own database or API server, so it runs the same way in development and in CI.
• Dev shells. dagger shell opens a shell in any container the workspace provides. dagger check -i opens one in the exact state where a command failed.
• Remote execution. Pipelines can run on a remote engine, on your own infrastructure or on Dagger Cloud, with local files, secrets and your terminal streamed as needed.
• GitHub checks without a workflow file. Dagger Cloud can take events from GitHub, run checks on each push and report status back. You turn it on with dagger cloud checks on.

Dagger’s own speed figures: 1,000 parallel containers went from 35 to 61 seconds down to 16 to 17 seconds, and collecting 300 files went from 11.8 seconds to 1.1 seconds. Those are Dagger’s measurements, not ours.

Pricing

Dagger Cloud now bills each pipeline’s exact resource use. Idle capacity is free, and operations that could be served from cache cost five times less, “whether or not they actually are.”

Before you upgrade

The post says 1.0 has breaking changes. The engine and API are the same, but “many CLI commands have changed,” and dagger.json is replaced by two files, dagger.toml for the workspace and dagger-module.toml for each module manifest. Some SDK modules may need small code changes. Dagger says backward compatibility or automated migration covers most of this “with a few exceptions,” and points to a migration guide. Since the team cannot test your private repositories, it asks you to try 1.0 on a local checkout and report what breaks on its Discord.