# Buildkite vs Dagger ## Dagger runs the same checks on your laptop and in CI. > Buildkite vs Dagger, compared by capability: pipeline model, where work runs, test intelligence, caching, local runs, coding agents, governance and cost, including where Dagger is the better choice, and how to run Dagger inside Buildkite. Buildkite is CI that keeps up however much you ship. ## Summary Dagger is a programmable engine. Checks run in containers the same way on a laptop, on your servers or on Dagger Cloud, defined by official modules or code in Go, Python, TypeScript and other languages. Its engine reuses any operation whose inputs haven't changed, and with the 1.0 beta in October 2026, its official modules find your tests and report each one separately. If checks that pass locally and fail in CI are your problem, Dagger is aimed directly at it, and Dagger runs inside Buildkite. Buildkite is the CI orchestration platform for AI. Every frontier lab runs their CI on Buildkite. It’s a different purchase from an engine: agents run on your infrastructure or ours, on Linux, macOS and Windows, on x86 and Arm; pipeline steps are generated at runtime in the language you already use; and test intelligence, caching and registries sit in the same system. An engine is a layer; Buildkite is the stack. Buildkite supports GitHub, GitLab, Bitbucket, [Origin](https://buildkite.com/docs/pipelines/source-control/origin), [Entire](https://buildkite.com/docs/pipelines/source-control/entire), Pierre Computer Co’s [code.storage](https://buildkite.com/docs/pipelines/source-control/code-storage), or your own Git server. Origin and Entire run CI on Buildkite, and Pierre Computer Co built code.storage on Buildkite CI. - **Choose Buildkite:** when CI has to keep up across every team, OS and machine you run, with signed pipelines, SCIM and audit log exports when governance asks for them. - **Choose Dagger:** when the problem is drift between local and CI on Linux containers, and you want one set of checks that your laptop, your coding agents and your CI all run the same way. ## The short version ### What Buildkite is built for - Run on your infrastructure, Buildkite’s, or both - Build on Linux, macOS and Windows, on x86 and Arm, including your own Macs and GPUs - Generate pipeline steps at runtime, in the language you already use - Keep test intelligence, caching and registries in the same system - A first-party MCP server and agent skills, so coding agents drive your pipelines ### What Dagger is good at - The same checks on a laptop, a server or in CI, in containers - Per-operation caching, with no cache keys to maintain - Official modules that find your tests, run them and report each one - dagger check -i, a shell in the exact state where a command failed - An open-source engine, Apache 2.0, free to run anywhere there’s a Linux container runtime ## Feature comparison By capability, not bias. Where Dagger is the better choice, this page says so. | Capability | Buildkite | Dagger | | --- | --- | --- | | What it is | A CI platform: orchestration, test intelligence, caching, registries and governance in one system. | An open-source engine, Apache 2.0, that runs pipelines and checks in containers, plus Dagger Cloud for managed engines, traces and Cloud Checks. Dagger 1.0 entered beta in October 2026. | | Pipeline model | Static YAML, or steps generated at runtime by a program in any language that writes YAML or JSON: Bash, Python, Ruby, Node.js, Go, C# or PHP. The Buildkite SDK gives typed, unit-testable pipelines in JavaScript and TypeScript, Python, Go, Ruby and C#. | Official modules for common tools such as Go, pytest, ESLint and Playwright, or custom modules written with Dagger’s SDKs (Go, Python, TypeScript and others) or Dang, its own language. Tools without an official module need a custom one. | | Where work runs | Agents on your infrastructure, on-prem or any cloud, or Buildkite-hosted. Self-hosted execution keeps the checkout and the compute on your infrastructure. Mix both in one pipeline using separate queues. | Wherever the engine runs: your machine, your servers, Kubernetes, or Dagger’s Cloud Engines. Cloud Checks run on Dagger-managed engines; connecting your own machines to Dagger Cloud is listed as coming soon. | | Architectures and OS | Linux, macOS and Windows, on x86 and Arm, plus GPU, on your own hardware. Hosted Linux and Mac M4 agents, with Windows in private preview. | Work runs in Linux containers: Dagger needs a Linux container runtime, running natively on Linux and through Docker Desktop or similar on macOS and Windows. Xcode and native Windows builds need a macOS or Windows host. arm64 Cloud Engines are listed as coming soon. | | Scale and concurrency | Free: 10 concurrent jobs · Pro: up to 250 concurrent agents · Enterprise: unlimited self-hosted agents. 168,911 concurrent Buildkite agents on 21 October 2026; no customer passed 100,000 before May 2026. | Add engines, or use Cloud Engines. Dagger’s self-hosting guide notes that “a new engine adds compute, but its cache is empty”. Test splitting across engines is listed as coming soon. | | Test intelligence | Per-test results from collectors for RSpec, Jest, pytest, Go, Swift, Android and more, or any JUnit XML. Splitting by timing on every plan; flaky detection and test state management from Pro, with automatic quarantine on Enterprise; ownership mapped to teams through a TESTOWNERS file. The test client retries only the failed tests (documented for RSpec and Jest) and, on supported frameworks, mutes or skips quarantined ones. | Official modules report each test separately, and you can rerun one failed test, for example dagger check --go-test=TestGet. Test splitting and “smart checks” that run only what a change affects are listed as coming soon. Dagger’s own comparison names flaky-test quarantine as a reason to choose Buildkite. | | Caching | Key-based caching, generally available since 22 October 2026, restores the exact entry a job asks for, on hosted agents and on self-hosted agents with your own S3-compatible store, and buildkite-agent cache exec skips a whole command when its result is already cached. Persistent agents keep the working directory and git mirror warm. Hosted compute adds cache and git mirror volumes (NVMe on Linux) and Linux container cache volumes (best-effort by design), plus remote Docker builders with layer caching on Enterprise. | Every operation is cached in the engine and reused when its inputs haven’t changed, with no cache keys. The cache lives with the engine, which is why Dagger recommends persistent engines; Cloud Engines add a distributed cache. A real strength, and it works inside Buildkite. | | Local runs | bk preflight, experimental, snapshots uncommitted changes to a temporary branch, runs them on your real CI agents, reports failures as they happen and cleans up. It runs on CI, not on your laptop. | dagger check runs checks on your machine without pushing, and dagger check -i opens a shell where a command failed. Dagger leads here. | | Coding agents | An open-source MCP server (remote with OAuth sign-in, a read-only variant, a token endpoint for headless agents, or run locally) so agents read builds, logs and failed tests, trigger runs and wait on them. Official agent skills cover pipelines, migration, preflight and the CLI, and preflight is designed for agents to iterate against. | Coding agents use the same checks and containers as your CI, and dagger shell opens any container a workspace provides. Dagger 0.21 can also expose a module as an MCP server. | | Artifacts and registries | Package registries for npm, Maven, Gradle, PyPI, NuGet, RubyGems, deb, RPM, Alpine, Helm, Terraform modules, Hugging Face models, OCI images and generic files, plus artifact storage. | No package registry. Pipelines publish images and artifacts to the registries you already run. | | Source control | GitHub, GitLab, Bitbucket, Origin, Entire, code.storage, or your own Git server. The Entire and code.storage integrations are in preview. | dagger check works with any Git host. Cloud Checks require a GitHub repository. | | Governance and access | SOC 2 Type II on every plan. SSO and signed pipelines from Pro; SCIM, custom SAML, audit log exports and private log storage on Enterprise. | SOC 2 on every Dagger Cloud plan, access control on Scale and SSO on Enterprise (pricing). Self-hosted engines reached over tcp:// have no authentication, per Dagger’s self-hosting guide. | | Reliability commitment | 99.95% platform uptime and 99.5% hosted-agent uptime on Enterprise, in a published SLA. | No uptime SLA listed on Dagger’s pricing page; Enterprise offers custom terms and 24/7 premium support. | | Pricing model | Free: $0 · Pro: $30 per active user/month, 10 self-hosted agents included, $3.50 per agent/month after · Enterprise: custom. Your own compute isn’t metered; hosted Linux from $0.004 per vCPU-minute (pricing). | The open-source engine is free. Dagger Cloud is $20/month Starter for one user, $200/month Scale for unlimited users, or Enterprise custom, and you pay the plan price or your usage, whichever is higher. Usage is CPU, memory and data in and out, with repeat work at a fifth of the rate (pricing). | ## Your Dagger checks already run on Buildkite Dagger runs anywhere its CLI and a Linux container runtime do. In Dagger’s own words, “any CI system that can run the Dagger CLI can run dagger check”. Buildkite is one of them. Keep your modules, and let Buildkite own scheduling, fan-out, retries, test intelligence and governance around them. **How it fits together:** - A command step installs the Dagger CLI and runs dagger check on a self-hosted Linux agent with a container runtime. There’s no plugin to install. - Keep the engine warm. Dagger’s self-hosting guide says each new machine starts with an empty cache, and advises against running engines on a pool of ephemeral machines. Long-lived Buildkite agents keep the engine and its cache on the same machine between builds. On Kubernetes, Dagger’s Helm chart runs one engine per node, which CI jobs on that node reach over a unix socket. - Fan out with dynamic pipelines. A generator step can split checks into separate steps, so each gets its own job, queue and retry rule. - If your tests write JUnit XML, export it from the container and upload it to test intelligence for flaky detection, quarantine and ownership. - Keep Dagger Cloud traces if you use them, by setting DAGGER_CLOUD_TOKEN as a Buildkite secret. **Or move CI to Buildkite and keep Dagger where it helps:** - Keep Dagger for local parity, and run the same modules in Buildkite pipelines. - Move off Cloud Checks onto a platform built for scale: dynamic pipelines, test intelligence, registries and governance, on infrastructure you choose, from any Git host. - Move incrementally. Run both, cut across pipeline by pipeline, and keep the checks your team already trusts. Low regret either way: the Buildkite agent is open source under MIT, the Dagger engine is open source under Apache 2.0, the compute is yours, and the pipelines are code you own. [Try it free →](https://buildkite.com/pricing/) [Read the docs →](https://buildkite.com/docs/agent/self-hosted) ## Where the difference actually shows up Dagger optimises the check. Buildkite optimises the system the checks run in. Both are legitimate; they answer different questions. - **The work stops being Linux.** Dagger runs work in Linux containers, so the moment CI includes iOS, macOS or Windows builds, that work needs a host of its own. On Buildkite, an agent is a binary: it runs on your Macs, your GPU boxes and your Windows fleet, under one control plane. - **The pipeline is already code.** Dagger’s case is pipelines as code instead of YAML. Buildkite pipelines can be code too: a program generates steps at runtime, and the Buildkite SDK makes them typed and unit-testable. The difference is what that code controls. On Buildkite it decides which jobs run, on which machines, in what order, for every team in the organisation. - **The volume stops being one team’s.** Caching makes repeat work cheap; it doesn’t schedule new work. When coding agents multiply the changes every team builds and tests, what matters is whether CI keeps up. The six AI labs on Buildkite ran 15X more CI jobs in September 2026 than in September 2025. Buildkite asks for deliberate setup up front, and gives you a system you extend rather than replace when the work changes shape. ## What a caching claim is actually measuring Per-operation caching is a real advantage. How much it saves depends on three things, and only one of them is the engine. - **Where the engine lives.** Dagger’s cache lives with the engine. Its self-hosting guide is direct about it: “Do not run engines on a pool of ephemeral machines. Each new machine starts with an empty cache.” On ephemeral CI runners, every job starts cold unless the engine persists or runs on Cloud Engines. - **How much work actually repeats.** On Dagger Cloud, repeat work (the same inputs as an operation in the last 30 days) is billed at a fifth of the rate, whether or not it’s served from cache. The operations a change actually touches, from your team or its coding agents, are new work at the full rate; the rest of the run bills as repeat work. - **What else changed.** Caching is usually the single largest lever in a slow pipeline, and it almost always gets redesigned during a migration. A faster run after a cache redesign is a fact about the cache. The only comparison worth acting on is the same workload, on the same class of hardware, with the same cache strategy. On Buildkite you don’t have to choose: persistent agents keep a Dagger engine warm, and you get its cache with Buildkite’s orchestration around it. ## Built to fit your environment Figures below combine Buildkite platform data with results from customer case studies. - **168,911**: concurrent Buildkite agents on 21 October 2026. No customer passed 100,000 before May 2026 - **15X**: more CI jobs across the six AI labs on Buildkite in September 2026 than in September 2025 - **[3hrs→55min](https://buildkite.com/resources/case-studies/elastic/)**: Elastic cut Kibana pull request CI by 70%; [Shopify cut build times by 75%](https://buildkite.com/resources/case-studies/shopify/) - **[47%](https://buildkite.com/resources/case-studies/reddit/)**: lower p90 mobile build times at Reddit (33% at p50), with queue times around five seconds ## Cost breakdown The Dagger engine is free; Dagger Cloud meters CPU, memory and data, with the plan price as a monthly floor. Buildkite prices the platform per active user, with compute on top, and doesn’t meter compute you run yourself. **Free:** - Up to 5 users, 10 concurrent jobs - 2,000 Linux vCPU-minutes and 250k test executions per month - 50GB artifact storage, 250GB downloads, 30-day retention - Dynamic pipelines and test splitting included - Community support **Pro:** - $30 per active user per month, up to 50 users - Up to 250 concurrent agents, 10 included, $3.50 per agent/month after - 4,000 Linux vCPU-minutes included, plus M4 Mac agents and larger machine sizes - 1M test executions per month, then $15 per additional million - Test state management and flaky detection - SSO and signed pipelines - Priority email support **Enterprise:** - Unlimited users on a 30-user minimum - Unlimited self-hosted agents, custom limits and retention - Automatic quarantine of flaky tests - 99.95% uptime commitment - Enterprise support Hosted agents: Linux $0.004 per vCPU-minute (a 2 vCPU Small agent is $0.008 a minute) and Mac M4 $0.02 per vCPU-minute, metered to the second. Free and Pro start with a 30-day all-access trial. No credit card needed. [View pricing →](https://buildkite.com/pricing/) **Dagger prices the plan as a floor and meters the work:** - The engine is free. It’s open source under Apache 2.0, and costs nothing to run on your own machines - Dagger Cloud plans: $20/month Starter for one user, $200/month Scale for unlimited users, or Enterprise custom. You pay the plan price or your usage, whichever is higher - New work: 0.5¢ per CPU-minute and 0.5¢ per GB-minute of memory, with data in at 2.5¢ per GB and out at 10¢ per GB - Repeat work: an operation with the same inputs as one in the last 30 days costs a fifth of those rates See Dagger pricing ↗ If most of your CI repeats and it all runs in Linux containers, Dagger’s model rewards that directly. Buildkite’s case is different: per-user and per-agent pricing, and compute on your own infrastructure that isn’t metered, including the machines your Dagger engines run on. Buildkite plan figures read from [buildkite.com/pricing](https://buildkite.com/pricing/) on 28 October 2026. Dagger plan prices and rates: dagger.io/pricing, read the same day. ## Where your builds run Buildkite makes flexible, persistent execution the default. Buildkite: self-hosted agents make outbound HTTPS connections only, with no inbound ports to open, and self-hosted execution keeps the checkout and the compute on your infrastructure (architecture). Keep agents warm between runs with a local git mirror, or make them ephemeral. Your call, per queue. Or use Buildkite-hosted agents. Dagger: the engine runs wherever you put it (a laptop, your servers, Kubernetes, or Dagger’s Cloud Engines) and the CLI reaches it over a unix socket, Kubernetes or TCP, or on Cloud Engines (self-hosting guide). Cloud Checks run on Dagger-managed Cloud Engines; connecting your own machines to Dagger Cloud is listed as coming soon. The difference is what triggers the work. Dagger’s engine can run with no external service at all, but on its own it doesn’t start on a push; Cloud Checks or a CI system does that. Buildkite’s control plane is SaaS, with agents that connect outbound only. If CI has to run with no external service, self-hosted Dagger behind your own trigger fits that and Buildkite doesn’t. ## Who answers when something breaks (and what customers say about it) When delivery is strategic, support matters as much as features. Buildkite gives you direct access to the people who built it, not a tiered helpdesk. [G2](https://www.g2.com/sellers/buildkite) and PeerSpot customers called it fast, responsive, and knowledgeable. - **[4.7 / 5 31 reviews · 22 October 2026](https://www.g2.com/products/buildkite/reviews)**: G2 rating, where reviewers cite responsive, knowledgeable support ## The honest trade-off **If your pain is checks that pass locally and fail in CI, Dagger is aimed at exactly that.** - One set of checks runs on a laptop, a server, for your coding agents and in CI, in the same containers. - dagger check -i drops you into the exact state where a command failed, without pushing a commit. Buildkite’s closest answer, preflight, is experimental and runs on CI agents. - Per-operation caching, with no keys to maintain. Come to Buildkite when the problem is CI rather than the checks: when work spans macOS, iOS, Windows or GPU, when volume from every team and its coding agents has to keep up, when flaky tests need quarantine and owners rather than another rerun, or when access control needs SCIM, audit log exports and signed pipelines. And keep Dagger for the checks if your team likes them. ## Choose Dagger if… - Drift between local and CI is the specific, measurable problem. - Your CI is Linux containers, and staying there suits you. - You want to debug a failed check interactively, on your own machine, before you push. - You’re on GitHub and want checks on every push with no CI workflow file, on managed Cloud Engines. - You want an open-source engine you can run entirely on your own machines. ## It depends on your situation The decision usually comes down to four things. | Capability | Lean Buildkite | Lean Dagger | | --- | --- | --- | | Your actual problem | CI has become a system: volume, fan-out, test intelligence and governance across teams. | Checks that behave differently on a laptop and in CI. | | Architectures and hardware | iOS and macOS on your own Macs, Windows, GPU: one control plane over all of it. | Linux containers, which is what Dagger runs. | | Whose infrastructure | Any infrastructure, on-prem or any cloud, agent outbound-only, or Buildkite-hosted. Your choice, on any plan. | Your own engines, or Dagger’s Cloud Engines for Cloud Checks. | | Governance and access | SOC 2 Type II with a public trust site, SSO and signed pipelines from Pro, SCIM and audit log exports on Enterprise, and a published SLA. | SOC 2 on every Dagger Cloud plan and SSO on Enterprise, enough for many teams. | ## Frequently asked questions ### Is Buildkite a Dagger alternative? Partly. Both run checks, but Dagger’s centre of gravity is the engine: the same containers on a laptop and in CI. Buildkite is the platform around the jobs (orchestration, test intelligence, caching, registries and governance) on compute you choose. Many teams don’t need to pick: Dagger runs inside Buildkite. ### Can I run Dagger on Buildkite? Yes. Install the Dagger CLI in a command step on a Linux agent with a container runtime, and run dagger check. Keep agents long-lived so the engine’s cache stays warm, in line with Dagger’s own self-hosting guide, which advises against ephemeral engines. ### Isn’t a Buildkite pipeline a lot of YAML? It is if you write it that way. Buildkite steps don’t have to be a static document: a pipeline can be generated at runtime by a program in Bash, Python, Ruby, Node.js, Go, C# or PHP, and the Buildkite SDK adds typed, unit-testable pipelines in JavaScript and TypeScript, Python, Go, Ruby and C#. Teams that treat it as static YAML get static YAML, and at monorepo scale that sprawls. The architecture supports the other approach; adopting it is a deliberate choice. ### Can Buildkite rerun just the failed tests? Yes. The test client runs your test command, then retries only the failed tests up to a count you set; its docs cover this for RSpec and Jest. Test intelligence records every test, so a flaky one can be quarantined (automatically on Enterprise, manually or by API on Pro) and, on supported frameworks, muted or skipped rather than rerun forever, with ownership mapped to teams. Steps can also retry automatically. ### Can I run Buildkite checks locally before I push? Not on your laptop. bk preflight, which is experimental, snapshots your uncommitted changes to a temporary branch, runs them on your real CI agents, reports failures as they happen and cleans up afterwards. It’s designed for coding agents to iterate against. If laptop-local runs matter most, use Dagger for those and Buildkite for CI. ### How do coding agents work with Buildkite? Through a first-party, open-source MCP server: remote with OAuth sign-in, a read-only variant, a token endpoint for headless agents, or run locally. Agents read builds, logs and failed tests, trigger runs and wait on them. Official agent skills teach agents pipelines, migration, preflight and the CLI. And the volume holds: the six AI labs on Buildkite ran 15X more CI jobs in September 2026 than in September 2025. ### Where does my code run? With Dagger, wherever the engine runs: your machine, your servers or Kubernetes, or Dagger’s Cloud Engines for Cloud Checks. With Buildkite, wherever you choose on any plan: self-hosted agents connect outbound-only and self-hosted execution keeps the checkout and the compute on your infrastructure, or use Buildkite-hosted agents. ## Related resources ### Docs - [Dynamic pipelines](https://buildkite.com/docs/pipelines/configure/dynamic-pipelines) - [Buildkite SDK](https://buildkite.com/docs/pipelines/configure/dynamic-pipelines/sdk) - [Test splitting, quarantine and ownership](https://buildkite.com/docs/pipelines/configure/tests) - [MCP server](https://buildkite.com/docs/apis/mcp-server) ### Guides & comparisons - [Buildkite vs Depot](https://buildkite.com/resources/comparison/buildkite-vs-depot/) - [Buildkite vs Blacksmith](https://buildkite.com/resources/comparison/buildkite-vs-blacksmith/) - [Pricing](https://buildkite.com/pricing/) - [Customer stories](https://buildkite.com/resources/case-studies/)