Depot Alternatives for GitHub Actions

Teams shop for a Depot alternative when their spend sits in GitHub Actions minutes rather than container builds, when they need runners inside a cloud account that Depot Managed does not cover, or when the single macOS hardware shape is not enough. This page lists the alternatives worth a real evaluation, with every vendor fact linked to the page that states it and checked on 2026-08-13.

Looking for the head to head instead? WarpBuild vs Depot has the dimension table. Migrating from Depot to WarpBuild has the label map and the rollback path.

How to Choose

Six questions separate these options faster than any feature list.

1. Where does the compute run? A vendor fleet, your own cloud account, or your own Kubernetes cluster. This decides your data residency story, your security review, and who carries the pager.
2. How many macOS shapes and Xcode versions do you need? macOS is where this category diverges most, both in machine sizes and in what each vendor publishes about image contents.
3. What shape is the bill? A monthly plan with included allowances and usage meters on top behaves differently from a purely usage based rate, especially for teams with spiky monthly minute counts.
4. What is the concurrency policy? Most vendors in this set publish no hard limits. GitHub publishes per plan caps. Read the published policy rather than a marketing line.
5. What happens to caching when you switch? Cache contents are never portable between providers. What matters is how many workflow edits the new cache costs you and whether your build tool has a documented integration.
6. How reversible is the move? If the only change is a runs-on label, a bad outcome costs you one pull request. If the move rewrites workflow files into a new directory, the exit is more expensive than the entry.

WarpBuild

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners for GitHub Actions, plus remote Docker builders. Runners are selected by a warp- label, so adoption and reversal are both a one line workflow change. Product surface beyond the fleet: snapshot runners, remote Docker builders, CI observability, an MCP server, and the Action Debugger for an SSH session into a running job.

The differences that matter against Depot specifically:

• BYOC on three clouds. Managed runners inside your own AWS, GCP, or Azure account, with a Terraform path for AWS. See BYOC.
• Two macOS sizes across three macOS versions. 6 vCPU with 22 GB and 12 vCPU with 44 GB of memory, with the Xcode version on the macOS 26 image published in cloud runners.
• Purely usage based pricing. No base subscription fee, no platform fee, and no seat fee, with $10 in free credits at signup. Rates per label are on the pricing page.
• No plan-level concurrency caps on generally available Linux and Windows runners. macOS capacity and beta runners have separate constraints.
• US and EU regions, with enterprise deployments on region specific infrastructure. On the enterprise tier, runners pull large images and artifacts from ECR, S3, and similar stores with zero egress cost to you, whether your runners live in your cloud or ours.
• SOC 2 Type 2, with the report requestable at trust.warpbuild.com, SAML 2.0 and OIDC single sign on at a flat $250 per month, whatever the user count, and Slack support channels on demand.

Blacksmith

Blacksmith runs managed GitHub Actions runners on their own bare metal fleet, with Linux x64, ARM, Windows, and macOS coverage. Their quickstart publishes a one line runs-on diff with explicit label mappings, such as ubuntu-latest to blacksmith-2vcpu-ubuntu-2404, alongside a wizard that rewrites workflow files for you.

What stands out on their published pages, checked 2026-08-13:

• 3,000 free minutes per month with no credit card, printed on every pay as you go tier of their pricing page.
• Caching that needs no workflow edits. Their dependency caching docs state that zero code changes are required, because standard actions/cache and setup-* actions hit their colocated cache.
• No concurrency limits on any tier, stated in their docs.
• Automatic free size upgrades when their fleet has spare capacity, per their runner overview.
• SOC 2 Type 2 since September 2024, a published DPA and sub-processor list, and a public status page. This is parity with WarpBuild on compliance, and no page should frame it as a gap.
• A deep observability surface: CI analytics, run history, cross run log search, machine metrics, and SSH into running jobs.

The trade against Depot is a simpler adoption story and a free monthly allowance, set against a narrower product portfolio. Blacksmith sells runners and caching. Depot's own docs index covers container builds, a registry, agent sandboxes, and a separate CI engine as well.

Namespace

Namespace runs GitHub Actions runners on hardware they own. Their engineering post on building their own datacenter states that more than 95 percent of their platform has run on their own infrastructure since early 2024, across sites on the US East Coast, the US West Coast, and Europe.

They are the strongest macOS option in this set. Their macOS architecture docs publish four macOS versions, six machine shapes up to 12 vCPU with 56 GB of memory, bare metal Apple Silicon, and Xcode selectors that include a beta channel. Their machine shapes page also lists Linux on Apple Silicon as a distinct early access platform.

Other published strengths, checked 2026-08-13: a large named cache surface backed by local NVMe volumes rather than a network cache API; ALLOW, BLOCK, and ADVISORY egress policies on Linux and macOS; SOC 2 Type II with a public trust center; no charge for users or seats, per their billing docs; a changelog with 226 dated entries; and a one line runs-on migration documented in their GitHub Actions guide.

Two things to check against your own requirements. All Namespace compute runs on their fleet, and their federation docs cover identity rather than deploying compute into your cloud account. Plan level concurrency is published as vCPU denominated caps on their pricing page, which is a different model from an unlimited concurrency policy.

GitHub-Hosted Larger Runners

The option most teams skip. GitHub sells larger machine sizes for their own hosted fleet, documented on the larger runners reference. Billing, permissions, secrets, OIDC, and metrics stay inside the product that already hosts your repository, and there is no third party in the security review.

The tradeoffs are published as clearly as the benefits. GitHub sets per plan concurrency caps on its limits page, where the other options in this list mostly publish no hard limits. Standard runners are free for public repositories, but larger runners are never free, even on public repositories, per their billing concepts page. Data residency is an Enterprise Cloud feature documented separately, and there is no option to run the fleet inside your own cloud account.

Choose this when the simplicity of a single vendor outweighs the price and the caps, and when your workflows are not blocked on queue time or machine size.

Actions Runner Controller

Actions Runner Controller is GitHub's open source Kubernetes operator for self hosted runners. GitHub's ARC concepts page describes it as an operator that orchestrates and scales self hosted runners, with runners as pods in your own cluster, shipped as two Helm charts and one container image. The software is free; the cost is your cluster and your engineering time.

Facts to weigh, verified 2026-08-13:

• The GitHub maintained runner image is Linux based and published for linux/amd64 and linux/arm64 only, per its build workflow.
• ARC's documentation does not cover macOS runners. This was verified across the ARC repository and GitHub's ARC docs on 2026-08-13, and it is an absence in their documentation rather than a statement GitHub has published.
• No Terraform provider or module ships in the ARC repository; the installation surface is Helm charts and raw manifests.
• GitHub's ARC support scope excludes installation tooling other than Helm and excludes managed Kubernetes provider specifics, so cluster problems are yours.

ARC is the right answer for a platform team that already operates Kubernetes and has a policy reason to keep runners inside its own boundary. It is the wrong answer for a team that wants runners to stop being a project.

Which Option Fits

Every row in this table links to the page where that vendor states its own terms. Prices change more often than comparison pages do, so read the linked page before you decide.