{"slug": "dagger-1-0-beta", "title": "Dagger 1.0 Beta", "summary": "Dagger released the beta of Dagger 1.0, a third-generation CI platform it says is built to match the speed and scale of coding agents, after five years of development on v0. Dagger positions the platform against Jenkins and GitHub Actions, arguing that second-generation CI wastes compute by over-allocating VMs, re-computing unchanged artifacts, and forcing agents to burn tokens reconstructing context from unstructured logs. The company said engineers at Typesafe, Fastly, Nvidia, Fidelity and Nine Entertainment use Dagger, and it is asking users to test the beta before it declares the release stable.", "body_md": "# Dagger 1.0 beta\n\n*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!*\n\n## Try it now\n\nSet up Dagger CI on this repo. Run my checks locally, then run them again so I can see the cache. Once that works, configure Dagger Cloud to run them automatically after I push. Then explain to me how this can \"accelerate my feedback loop at scale, without wasting compute or tokens\", and how to use it.\n\n## Why Dagger?\n\nCoding agents can only ship as fast as their CI, and CI is falling behind. In [the Great CI bottleneck of 2026](https://dagger.io/blog/the-great-ci-bottleneck-of-2026/), I argued that buying bigger machines won’t fix this: the problem is the CI platform itself.\n\nWhen 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:\n\n- The only way to scale is more VMs or bigger VMs, so you over-allocate to absorb peaks, and compute sits idle.\n- Shell scripts can’t tell what changed, so your VMs re-compute the same artifacts over and over.\n- 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.\n- 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.\n\nTo 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.\n\nDagger runs every code change — whether machine-generated or handwritten — through the same build and test pipelines, before or after push.\n\nEngineers at Typesafe, Fastly, Nvidia, Fidelity, Nine Entertainment and many others use Dagger to accelerate their feedback loop at scale, without wasting compute or tokens.\n\n## How it works\n\n1. Dagger detects your toolchains and recommends [official modules](https://docs.dagger.io/reference/modules) for them. You can also write your own.\n\n1. 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.\n2. 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.\n3. Dagger computes artifacts lazily, as an incremental DAG of sandboxed functions, on your machine or on a shared remote engine.\n\n1. 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.\n\n## What’s new in 1.0\n\nFive years is a long time to stay at 0.x. We spent them practicing “pain-driven development” with our community [on Discord](https://discord.com/invite/dagger-io), and iterating furiously: from CUE to SDKs, then modules, deep OpenTelemetry tracing, a terminal UI, and finally [the replacement of BuildKit](https://dagger.io/changelog/theseus). 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.\n\nHere are the highlights. See [our changelog](https://dagger.io/changelog) for more.\n\n### Official modules\n\nThe 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](https://dagger.io/changelog/official-modules)\n\n### Workspaces\n\nDagger 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](https://dagger.io/changelog/workspaces)\n\n### Much faster\n\nDagger 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.”\n\n- Parallel containers: 1,000 containers at the same time: from 35–61 s to 16–17 s.\n- Many files: collect 300 files: from 11.8 s to 1.1 s.\n\n### Test-native CI\n\nDagger 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](https://dagger.io/changelog/test-native-ci)\n\nOr you can browse the results interactively:\n\n### Self-orchestrating tests\n\nIntegration 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](https://dagger.io/changelog/self-orchestrating-tests)\n\n### Dev shells\n\n`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](https://dagger.io/changelog/dev-shells)\n\n### Remote execution\n\nRun any pipeline on a remote engine, on your own infrastructure or on [Dagger Cloud](https://dagger.io/changelog/cloud-engines). 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](https://dagger.io/changelog/remote-execution)\n\n### Native GitHub integration\n\nDagger 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](https://dagger.io/changelog/cloud-checks)\n\n### Transparent usage pricing\n\nDagger 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](https://dagger.io/pricing) \n\n## Compatibility\n\nDagger 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](https://docs.dagger.io/config/migrate-dagger-json).\n\nThis 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](https://discord.com/invite/dagger-io) what breaks.\n\n## Thank you!\n\nThis 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.\n\nWe encourage you to [join our Discord](https://discord.com/invite/dagger-io) and say hi!\n\nSet up Dagger CI on this repo. Run my checks locally, then run them again so I can see the cache. Once that works, configure Dagger Cloud to run them automatically after I push. Then explain to me how this can \"accelerate my feedback loop at scale, without wasting compute or tokens\", and how to use it.", "url": "https://wpnews.pro/news/dagger-1-0-beta", "canonical_source": "https://dagger.io/blog/dagger-10-beta/", "published_at": "2026-10-23 16:04:06+00:00", "updated_at": "2026-10-23 16:13:47.885326+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure", "mlops"], "entities": ["Dagger", "Jenkins", "GitHub Actions", "Typesafe", "Fastly", "Nvidia", "Fidelity", "Nine Entertainment"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/dagger-1-0-beta", "markdown": "https://wpnews.pro/news/dagger-1-0-beta.md", "text": "https://wpnews.pro/news/dagger-1-0-beta.txt", "jsonld": "https://wpnews.pro/news/dagger-1-0-beta.jsonld"}}