The Pulse
Dagger Puts Its 1.0 CI Platform Into Beta
Dagger announced its 1.0 beta on October 23, 2026, after five years of development at version 0.x. The release adds official modules, test-level reporting, remote execution and direct GitHub checks, with Dagger asking users to test the beta
AI.info Team · Written with AI · fact-checked ·
“Coding agents can only ship as fast as their CI, and CI is falling behind.”
Solomon Hykes
Dagger announced its 1.0 beta on October 23, pitching the release as a new generation of continuous integration built for software teams using coding agents. The company says the platform can run the same build and test pipelines locally, before a code push, or afterward—so an agent can get feedback without relying on a separate, differently configured CI environment.
The launch follows five years of development in the 0.x series. Dagger is asking users to test the beta on their own repositories before it declares the release stable. The company says it cannot test against customers’ private codebases and directs testers to report problems through its Discord community.
Dagger shifts CI from jobs to individual tests
The release’s main technical change is how it represents work. Dagger describes pipelines as sandboxed functions that produce typed artifacts, including source code, containers, binaries and tests. The engine computes those artifacts lazily in an incremental dependency graph, locally or on a shared remote engine; Dagger says the sandbox, scheduler, container runtime, cache and tracing all use the same execution and data model.
That structure supports several features aimed at shortening the loop between a code change and useful feedback. Official modules connect Dagger to tools such as Go, pytest, ESLint and Playwright, and can find and run selected tests. Instead of reporting only the status of a larger CI job, Dagger says the beta reports each test separately, allowing a developer or agent to rerun a failed test on its own.
Workspaces provide a place to configure Dagger, usually within a Git repository. A dagger.toml file specifies modules and other settings, while modules can inspect project files and native configuration. Dagger also adds self-orchestrating integration tests: a test can use modules to start dependencies such as a database or API server, rather than relying on a separate setup that may differ between a developer’s machine and CI.
The speed claims come with specific benchmarks
Dagger’s announcement reports two performance comparisons. It says running 1,000 containers in parallel fell from 35–61 seconds to 16–17 seconds. Collecting 300 files fell from 11.8 seconds to 1.1 seconds. The post does not describe those figures as an independent benchmark; they are Dagger’s own results, presented as evidence of the performance work behind 1.0.
The company also adds interactive development shells. dagger shell opens a shell in a container supplied by a workspace, while dagger check -i opens one at the state where a command failed. The aim is to let developers, CI and coding agents inspect the same environment rather than reconstructing it from a long job log.
GitHub checks and a new billing model
Dagger Cloud can now receive GitHub events, run checks on pushes and return status without a GitHub Actions workflow file or another third-party service. Users can enable the integration with dagger cloud checks on. For remote execution, Dagger says it can run pipelines on a company’s infrastructure or in Dagger Cloud, streaming files, secrets, network tunnels and terminal access as needed.
Dagger Cloud’s new pricing charges for each pipeline’s resource usage, according to the company. Idle capacity is free, and operations that could be served from cache cost five times less, whether or not the cache actually supplies them. The announcement does not give example bills or a price per unit of usage, so teams evaluating the change will need to compare their own pipeline patterns against the service’s pricing details.
Beta status means migration work remains
Dagger says 1.0 keeps the core engine and API but changes many CLI commands. The older dagger.json configuration is replaced by dagger.toml for the workspace and dagger-module.toml for the module manifest. The company says backward compatibility or automated migration handles most cases, though some SDK code may need small adjustments and a few exceptions remain.
The beta therefore asks users to test more than the headline performance improvements: they will need to check module behavior, migration results, test reporting and remote execution in their own projects. Dagger’s stated milestone is a stable architecture for 1.0; the release is still a beta, and its own announcement makes testing against real repositories the remaining step before stability.