CI that keeps up
alternativesby Kyle Penfound

What are the alternatives to GitHub Actions, from faster runners to portable pipelines?

The alternatives to GitHub Actions change one of three layers of CI. Runner vendors such as Blacksmith, Depot, Namespace, WarpBuild, and RunsOn keep GitHub Actions and run its jobs on faster or cheaper machines. Other CI platforms, such as Buildkite, CircleCI, and Depot CI, replace GitHub Actions as the system that starts and schedules jobs. Dagger moves the build and test logic out of the CI configuration and into code that runs the same on a laptop and in CI. Its Cloud Checks run that code after every push and pull request, with no workflow file and no runners to manage.

Three layers that the alternatives change

Each kind of alternative changes a different layer of your CI, so each one fixes a different problem.

  • Runner vendors keep GitHub Actions as the orchestrator and run your jobs on their machines. Blacksmith, Depot, Namespace, and WarpBuild host the runners. RunsOn starts them in your own AWS account. To move a job, you change its runs-on: label.
  • Other CI platforms replace GitHub Actions as the system that triggers and schedules jobs. Buildkite and CircleCI have their own pipeline formats. Depot CI runs GitHub Actions YAML on its own orchestrator.
  • A portable pipeline moves the build and test logic into code that runs the same on a laptop and in CI. Dagger works at this layer. Cloud Checks run that code on Dagger’s servers, so Dagger replaces both the workflow files and the runners.

Criteria to compare GitHub Actions alternatives

Compare the alternatives on the problem that you want to fix. These criteria separate them:

  • Price per minute, and how each vendor counts a minute. GitHub rounds each job up to a whole minute (runner pricing). Depot tracks usage by the second. Namespace bills in “unit minutes”, which it weights by machine size.
  • Speed. Speed comes from the CPU, the speed of cache transfers, and whether a cache stays available between jobs.
  • Migration effort. A label change takes minutes. A move to a new pipeline format takes much longer.
  • Lock-in. Lock-in is the vendor-specific actions, labels, and config files that you must remove to leave.
  • Local reproduction. This is whether a developer or a coding agent can run the same checks before a push.
  • Who operates the infrastructure. The vendor operates the machines, or you operate them in your own cloud account.

Runner vendors that replace GitHub-hosted runners

Blacksmith, Depot, Namespace, WarpBuild, and RunsOn run your current workflow files on their runners. You move a job to one of them with a change to its runs-on: label. The baseline is GitHub’s own price. A GitHub-hosted Linux x64 runner with 2 cores costs $0.006 a minute. The 4-core runner costs $0.012 a minute, and it is a larger runner for organizations on the Team or Enterprise Cloud plan.

The table sums up the next two sections. It shows list prices for Linux x64 runners, from each vendor’s pricing page. Prices change, so follow the links in those sections before you decide.

Runner Linux x64 price per minute Example runs-on: label Where the machines run
GitHub-hosted $0.006 for 2 cores ubuntu-latest GitHub
Blacksmith $0.004 for 2 vCPU blacksmith-2vcpu-ubuntu-2404 Blacksmith
Depot $0.006 for 2 vCPU depot-ubuntu-24.04 Depot, or your AWS account on the Business plan
Namespace $0.002 prepaid or $0.003 overage, for 2 vCPU and 4 GB namespace-profile-<name> Namespace’s own hardware
WarpBuild $0.004 for 2 vCPU and 8 GB, or $0.002 plus your cloud bill on BYOC warp-ubuntu-latest-x64-2x WarpBuild, or your AWS, GCP, or Azure account on BYOC
RunsOn About $0.0009 for 2 vCPU, paid to AWS at spot prices, plus a license runs-on=${{ github.run_id }}/family=m8+r8/cpu=4 Your AWS account

Hosted runners: Blacksmith, Depot, Namespace, and WarpBuild

Blacksmith, Depot, Namespace, and WarpBuild host the runners, so you have no machines to operate. Each one focuses on a different part of the job.

  • Blacksmith sells faster hardware and a colocated cache. A 2 vCPU Linux runner costs $0.004 a minute, and the first 3,000 minutes each month are free (pricing). To move a job, replace a label such as ubuntu-latest with blacksmith-2vcpu-ubuntu-2404, or let the migration wizard do it. On Blacksmith, official and popular third-party cache actions, such as actions/cache, use the colocated cache automatically. Blacksmith’s own Docker actions add layer caching, which costs $0.50 per GB a month (Docker builds). Blacksmith works with GitHub organizations, not personal repositories (quickstart).
  • Depot runners cost $0.006 a minute for 2 vCPU. Plans cost $20 or $200 a month and include 2,000 or 20,000 minutes (pricing). Depot tracks usage by the second and bills whole minutes at the end of the month. A job selects a runner with a label such as depot-ubuntu-24.04. The runners use Depot’s distributed cache, and if you also use Depot container builds, the BuildKit builder runs next to the runner (docs). On the Business plan, Depot can deploy the runners in your own AWS account.
  • Namespace runs on hardware that it deploys and manages itself (compute). A Linux runner with 2 vCPU and 4 GB costs $0.002 a minute prepaid, or $0.003 as overage. One unit minute is 1 vCPU and 2 GB of memory for one minute, times a platform multiplier. The Team plan costs $100 a month and includes 100,000 unit minutes (pricing). You choose a machine shape in a runner profile, and the workflow selects the profile with a label such as namespace-profile-<name>. Namespace also offers Cache Volumes, remote Docker builders, and macOS runners on Apple Silicon (docs).
  • WarpBuild hosts runners for Linux, Windows, and macOS, and a job selects one with a label such as warp-ubuntu-latest-x64-2x (cloud runners). A Linux runner with 2 vCPU and 8 GB costs $0.004 a minute (pricing). On the hosted Ubuntu runners, a job can boot from a VM snapshot that an earlier run saved (snapshot runners).

A hosted runner vendor gives the quickest result when your workflows work and the problem is the bill or the wait time.

Runners in your own cloud account: RunsOn and WarpBuild BYOC

RunsOn and the WarpBuild BYOC plan put the runners in a cloud account that you manage. They cost less per minute. In exchange, someone on your team installs them and looks after the cloud side.

  • RunsOn installs as one CloudFormation stack in your AWS account. Jobs run on EC2 spot instances by default, and AWS bills you for the compute directly. Your code stays in your VPC (RunsOn). A job selects a runner with a label such as runs-on=${{ github.run_id }}/family=m8+r8/cpu=4. A 2 vCPU runner costs about $0.0009 a minute at spot prices, as a 7-day average in us-east-1. The license starts at €300 a year, and it is free for open-source projects, non-profits, and personal non-commercial use (pricing).
  • WarpBuild BYOC runs WarpBuild runners in your own AWS, GCP, or Azure account. WarpBuild charges $0.002 per runner minute for Linux, and your cloud provider bills the machines (BYOC).

Lock-in with a runner vendor

Lock-in with a runner vendor comes from vendor-specific actions and settings, not from the label change. If a workflow changes only runs-on:, it can move to another vendor, or back to GitHub-hosted runners, with a change to that one line. Some speedups need vendor actions, and you must replace each one to leave:

  • Blacksmith’s Docker layer caching uses useblacksmith/setup-docker-builder and useblacksmith/build-push-action in place of the Docker actions.
  • Namespace’s Git mirror checkouts and framework caches use namespacelabs/nscloud-checkout-action and namespacelabs/nscloud-cache-action.
  • RunsOn labels carry their own settings, such as family=, cpu=, and extras=s3-cache.

A runner change can also break required status checks. Branch protection rules require status checks by name. When rules require specific checks, GitHub asks for job names that are unique across workflows (protected branches). If the name: of a required job contains the runner label, such as through ${{ matrix.os }}, a new label renames the check. No check reports under the old name, so GitHub blocks the pull request with “Waiting for status to be reported” (troubleshooting required status checks). Keep runner labels out of the names of required jobs.

With every runner vendor, the pipeline logic stays in GitHub Actions YAML.

Other CI platforms that replace GitHub Actions

A move to another CI platform replaces the orchestrator. On Buildkite or CircleCI, you rewrite your pipeline in their format.

  • Buildkite runs pipelines on agents. You can host the agents yourself or use Buildkite’s hosted agents. Its dynamic pipelines generate steps at build time, and it includes test splitting. The Pro plan costs $30 per active user per month. The Free plan covers up to 5 users (pricing). How does Dagger compare to Buildkite? compares the two.
  • CircleCI bills in credits, which pay for compute, active users, and premium features. The Free plan includes up to 6,000 build minutes and 5 active users. Every plan includes test splitting and test selection, with a monthly allowance for test selection (pricing).
  • Depot CI runs GitHub Actions YAML on Depot’s own orchestrator and compute. Its migrate wizard, depot ci migrate, copies your workflows into a .depot/ directory. Your .github/ workflows also continue to run on GitHub until you turn them off. You can run a workflow against your local working tree, with uncommitted changes. You can also connect over SSH to the sandbox of a job (docs).

A new platform makes sense when you want a feature that GitHub Actions does not have. Examples are CircleCI’s test selection and Depot CI’s runs from your working tree. On each of these platforms, a CI configuration format still holds the pipeline.

Dagger: a portable pipeline that runs locally and in CI

Dagger moves the build and test logic out of the CI configuration, so the CI only has to start it. In the words of the Dagger docs, after you move a pipeline to Dagger, “your pipeline logic is decoupled from its environment”. You can start it before or after a push, on your laptop or in Dagger’s cloud. These parts do the work:

  • Modules supply the checks. A Dagger module is a reusable, typed API for automation, such as functions that test or lint a project. Official modules cover tools such as Go, golangci-lint, Jest, Vitest, Playwright, ESLint, Pytest, and Helm. For anything else, you write a module in Dang, Dagger’s native language for modules, or with an SDK such as Go, TypeScript, or Python.
  • Checks validate the project. A check is a module function for a test, a linter, a scan, or a policy. dagger check runs every check in the workspace in parallel. The docs say that its results are “identical on your laptop, in CI, and in the cloud”.
  • The Dagger Engine runs each pipeline as a graph of steps. It caches each step automatically and traces each run from start to end (introduction).
  • Cloud Checks run dagger check on Cloud Engines, the Dagger engines that Dagger Cloud hosts and manages, after each push and pull request.

Measured against the criteria above, Dagger compares like this:

  • Price per minute. Dagger Cloud does not bill per runner minute. It bills the CPU, memory, and data that your pipeline uses (see the pricing section below).
  • Speed. The engine caches each step, and runs a step again only when its inputs change.
  • Migration effort. A move to Dagger takes more work than a label change, because your checks run through Dagger modules. Official modules cover common tools. For other tools, find a module in the module registry with dagger module search. Or wrap the command you already run in a short module of your own.
  • Lock-in. The checks live in modules in your repository, not in CI configuration. They run on a laptop, on your own engine, or on Dagger Cloud.
  • Local reproduction. Developers and agents run the same dagger check before a push that Cloud Checks run after it. When a check fails in CI, you run the same check on your laptop.
  • Who operates the infrastructure. Dagger Cloud operates the Cloud Engines. The open-source engine also runs on your machine or your own server (dagger.io).

Move from GitHub Actions to Dagger

To move to Dagger, set up Dagger in the repository, run the checks locally, and then turn on Cloud Checks.

  1. Install the Dagger CLI.

  2. From the project root, run these commands:

    dagger init
dagger module recommend
dagger check -l
dagger check

dagger init creates dagger.toml, or uses the file if it exists. That file holds the workspace configuration for everyone who uses the repository. dagger module recommend finds modules that match the project and asks which ones to install. When Dagger installs a module, it also writes dagger.lock, which pins the images and Git refs that the workspace uses. Commit both files. dagger check -l lists the checks, and dagger check runs them.

In a small Go project, dagger module recommend installed the official Go module, dagger.io/go. Then dagger check printed this summary:

== CHECKS ==  ✔ 2 passed
✔ dag://?check=go/packages/generate/stale 0.6s OK
✔ dag://?check=test&go-package=. 0.9s OK
  == TESTS ==
    ✔ example.com/greet  1 passed

    ✔ 1 passed

The Quickstart covers module settings and generators.

Then turn on Cloud Checks. The repository must be on GitHub, and its Git origin remote must point to it. From the project root, run:

dagger cloud checks on

In an interactive terminal, the command offers to sign you in to Dagger Cloud. It also offers to connect the GitHub account or organization that owns the repository. After that, every push and pull request runs the same checks on Cloud Engines, with no workflow file (Cloud Checks). dagger workspace activity lists the runs.

Keep your current workflows until Cloud Checks cover the same checks. Compare the results, and then turn off the workflows. How do I migrate from GitHub Actions to Dagger? covers that process.

Dagger Cloud pricing compared with per-minute runners

Dagger Cloud bills for the CPU, memory, and data that your pipeline uses, not for runner minutes. New work costs 0.5¢ per CPU-minute and 0.5¢ per GB-minute of memory. Repeat work is 5× cheaper. An operation is repeat work if it has the same inputs as an operation that you ran in the last 30 days. Plans start at $20 a month, and you pay the plan price or your usage, whichever is higher (pricing).

A runner vendor bills a machine size for each minute of a job, whatever the job uses of that machine. Dagger Cloud does not bill for idle capacity. Because the units differ, compare the two with your own usage. The pricing page has a calculator that estimates a monthly Dagger Cloud bill from your usage. Can Dagger lower CI costs? explains how Dagger lowers CI costs.

How to choose a GitHub Actions alternative

Choose by what is wrong with your CI today.

  • The bill or the wait time is too high, and the workflows work. Move to a runner vendor. Choose Blacksmith, Namespace, or WarpBuild for hosted runners with nothing to operate. Choose Depot if container builds take most of the time. Choose RunsOn if you are on AWS and can manage the account. Choose WarpBuild’s BYOC plan for AWS, GCP, or Azure.
  • You want a feature that a specific platform offers. Choose Buildkite to manage a fleet of agents on your own infrastructure. Choose CircleCI for its built-in test selection. Choose Depot CI to keep your GitHub Actions YAML on a different orchestrator.
  • CI failures do not reproduce locally, or the YAML and the runners take too much work. Move the pipeline into Dagger and run it with Cloud Checks.

Bottom line: Runner vendors such as Blacksmith, Depot, Namespace, WarpBuild, and RunsOn make GitHub Actions cheaper or faster, often with a one-line label change. Other CI platforms make sense when you need a feature that they offer, but most of them mean a rewrite of the pipeline. Dagger moves the pipeline into code that runs the same on a laptop and in Cloud Checks, with no workflow files or runners to manage.