What is the closest alternative to Blacksmith?

For a team that wants managed GitHub Actions runners with the same one-label adoption, WarpBuild and Depot are the closest matches on product shape, and Namespace is the closest on macOS depth. The dimension that separates them is where the compute runs: WarpBuild BYOC runs on AWS, GCP, and Azure (https://www.warpbuild.com/docs/ci/byoc), Depot Managed is AWS-only and gated to their Business plan (https://depot.dev/docs/managed/overview), and Namespace runs everything on their own fleet (https://namespace.so/docs/federation).

Is there a free alternative to Blacksmith?

Actions Runner Controller is free software you run yourself on Kubernetes, published by GitHub at https://github.com/actions/actions-runner-controller. The software costs nothing and the cluster, the images, the scaling configuration, and the upgrades are yours to operate. Managed vendors charge per minute instead. GitHub-hosted standard runners are free for public repositories, and GitHub states that larger runners are always charged for, even on public repositories (https://docs.github.com/en/billing/concepts/product-billing/github-actions).

Which alternative supports running runners in my own cloud account?

WarpBuild BYOC runs on AWS, GCP, and Azure, with a Terraform provider for AWS (https://www.warpbuild.com/docs/ci/byoc). Depot Managed deploys their data plane into your AWS account on the Business plan and lists GCP as under consideration (https://depot.dev/docs/managed/overview). Namespace publishes no bring-your-own-cloud option; their federation docs cover workload identity only (https://namespace.so/docs/federation). GitHub-hosted runners run in Microsoft Azure under GitHub's account (https://docs.github.com/en/actions/concepts/runners/github-hosted-runners).

How hard is it to switch runner vendors?

For managed vendors, the workflow change is the runs-on label, so a switch and a rollback are both one line per job plus any vendor-specific action steps. What does not move is cache state: expect one cold run per cache key on the new platform while caches warm. Actions Runner Controller is the exception, because adopting or leaving it means standing up or decommissioning a Kubernetes deployment. See /migrate/blacksmith-to-warpbuild for a worked example.

Do the alternatives publish their compliance posture?

WarpBuild holds SOC 2 Type 2 with evidence at https://trust.warpbuild.com/. Blacksmith states SOC 2 Type 2 and GDPR on https://www.blacksmith.sh/security with a trust center at https://trust.oneleet.com/blacksmith-sh. Namespace publishes SOC 2 Type 2 evidence at https://trust.namespace.so and Depot publishes a security page at https://depot.dev/docs/security. Ask each vendor for the report itself; most gate it behind a request form.

Blacksmith Alternatives for GitHub Actions

Five real alternatives to Blacksmith for GitHub Actions runners, with cited facts on cloud placement, regions, concurrency, macOS depth, and billing shape.

Teams shopping for a Blacksmith alternative usually want one of four things: runners inside their own cloud account, a region they can name in a compliance answer, deeper macOS and Xcode coverage, or a bill with fewer meters on it. This page lists the options that are real products with public documentation, states what each one publishes, and links every fact to the vendor page that states it, checked on 2026-08-13.

Already comparing head to head? WarpBuild vs Blacksmith covers the two platforms dimension by dimension. Already decided? Blacksmith to WarpBuild migration has the label diff and the rollback steps.

Why Teams Look for Alternatives

Blacksmith is a capable platform, and most switching conversations start from a requirement it does not cover rather than from a complaint. The four requirements we see most often:

Compute placement. No bring-your-own-cloud, VPC, or customer-account deployment option appears on their pricing page, their security page, or anywhere in their docs sitemap as of 2026-08-13. Their published design is a vendor-operated fleet procured from data center providers in the US and EU. A job that needs to reach a private database or an internal registry inside your own network has no documented path.

Region selection. Their docs name three regions (US West, EU West, EU Central) in the Docker container caching page, and no page documents how a customer selects one for a job or an organization.

Identity. Their settings docs state that Blacksmith currently only supports login using GitHub, and no SAML or SCIM product is published. Teams that run access reviews out of an identity provider need something else.

macOS depth. Their macOS offering publishes two sizes and three image selectors resolving to two macOS versions, and no Xcode version list or Xcode selector appears anywhere in their docs.

What to Evaluate

Score every candidate on the same dimensions, in this order, because the first four decide most evaluations and the rest decide the renewal.

Where the compute runs. Vendor fleet, your cloud account, or your own Kubernetes cluster. This drives your security review, your network access, and your data flow diagram.
Region naming and pinning. Can you name the region in a customer questionnaire, and can you pin it without a support ticket?
Concurrency policy. Published caps, denominated in jobs or vCPU, versus no hard limits. Check whether the cap is per plan and whether queueing controls exist because of it.
Meter count and free tier. Count the line items that can appear on an invoice: runner minutes plus cache storage, artifact storage, egress, seats, support, and add-ons. Fewer meters means a forecast you can defend.
macOS and Xcode coverage. If you ship Apple software, count the macOS versions, the shapes, and the published Xcode versions on both sides before you decide.
Identity and access. SAML, SCIM, and a role model independent of GitHub org membership.
API and infrastructure as code. A working API reference and a Terraform provider, if runner configuration belongs in the same state as the rest of your infrastructure.
Cache portability. Assume none. Ask what a cold start costs you on the first run and what vendor-specific actions you would need to remove on the way out.
Support channel and SLA. Which tier gets a Slack channel, what the response times are, and whether an uptime SLA carries service credits.
Shipping cadence. A public changelog tells you when a runner image changed under a build that started failing.

The Alternatives

WarpBuild

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, selected with warp- labels. BYOC runs on AWS, GCP, and Azure, so the runner VMs live inside your account, and a Terraform provider covers BYOC on AWS. Regions are US and EU. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Signup includes $10 free credits. Generally available Linux and Windows runners do not have plan-level concurrency caps, and capacity adjusts dynamically. Single sign-on costs a flat $250 per month, whatever the user count. Slack support channels are available on demand, and the platform holds SOC 2 Type 2 with evidence at trust.warpbuild.com. Tooling includes snapshot runners, remote Docker builders, CI observability, an MCP server, and the Action Debugger. On the enterprise tier, runners pull large images and artifacts from ECR, S3, and similar stores with zero egress cost to you, and that applies whether your runners live in your cloud or ours. Runner image and platform changes ship monthly in the public changelog.

Depot

Depot runs GitHub Actions runners alongside a container build product that is their center of gravity. Their runner types page publishes Linux x64 on AMD EPYC instances, Linux ARM64 on Graviton4, Windows Server 2022 and 2025, and macOS at three OS labels on a single shape of 8 CPUs and 24 GB. That same page carries a queue-time caveat in their own words: Apple licensing constraints mean their macOS capacity is not fully elastic and macOS jobs can wait longer during high demand, with dedicated reserved capacity offered as an annual-commitment mitigation. Depot Managed deploys their data plane into your AWS account, is gated to their Business plan, and lists GCP as under consideration with no Azure option. No Terraform provider appears in their site index. Their pricing page publishes plan tiers with a monthly floor, unlimited concurrency on every plan, per-second billing, and two regions, us-east-1 and eu-central-1. They publish per-commit benchmarks for container builds, which is unusual transparency in this category.

Namespace

Namespace runs GitHub Actions runners on hardware they own. Their engineering blog states they have run more than 95 percent of their platform on their own infrastructure since early 2024. They are the strongest macOS offering in this set: their macOS docs publish four macOS versions, six machine shapes, Xcode selection through shape selectors including a bleeding-edge channel, and an image-update RSS feed. There is no bring-your-own-cloud option; their federation docs cover workload identity only. Their pricing page publishes per-plan concurrency caps denominated in vCPU (the Developer plan is capped at 32 vCPU for Linux and 12 vCPU for macOS), a unit-minute model with platform multipliers, and a dozen separate invoice meters. Free access is a 30-day trial rather than a permanent free tier. Their data residency docs state that workspace data may be processed across their global infrastructure by default, that regional preference goes through their support team, and that region-exclusive residency requires an enterprise plan.

GitHub larger runners

Staying on GitHub is a legitimate answer, especially for teams whose main problem is a slow default runner rather than a cost or placement problem. GitHub's larger runners add bigger x64 and ARM64 Linux and Windows shapes, macOS large and xlarge shapes, and GPU shapes. They are available to organizations and enterprises on GitHub Team and GitHub Enterprise Cloud plans, and GitHub states that larger runners are always charged for, including on public repositories, with included plan minutes not applicable. GitHub publishes per-plan concurrency caps, and macOS concurrency is shared between standard and larger runners. All of it runs in Microsoft Azure under GitHub's account, so there is no customer-account option; Azure private networking and static IP ranges for larger runners on GitHub Enterprise Cloud are the nearest adjacent capabilities. Nothing beats it on integration depth and setup time.

Actions Runner Controller

Actions Runner Controller is GitHub's open source Kubernetes operator for self-hosted runners, shipped as two Helm charts and one container image. The software is free and the operating cost is yours: cluster capacity, scaling configuration, runner image maintenance, and chart upgrades. The GitHub-maintained runner image is Linux only, built from a .NET runtime base for linux/amd64 and linux/arm64 in their publish workflow. Windows support on the modern scale-set mode is an open issue rather than a shipped feature, and a full-repository search for macOS at the current commit found exactly one match, inside a legacy document describing GitHub-hosted runners rather than ARC capability. ARC is the right answer for a platform team that already operates Kubernetes and has a policy reason to keep GitHub Actions compute in house.

How WarpBuild Compares

Against Blacksmith, the WarpBuild differences are placement, residency, identity, and the API surface: BYOC on three clouds, named US and EU regions, SAML and OIDC single sign-on with a published fee, a working API for every feature, and a Terraform provider for BYOC on AWS. Concurrency and SOC 2 Type 2 are parity between the two. Blacksmith's permanent free monthly minute allowance, transparent actions/cache interception, and Bazel remote cache have no WarpBuild equivalent, and the comparison page states each of those plainly.

Against Depot, WarpBuild covers three clouds for BYOC rather than one, publishes its Xcode versions per image with multiple sizes and configurations per chip, and charges no monthly plan floor. Depot's container build product and their public per-commit benchmarks are genuinely ahead of the field, and concurrency is parity.

Against Namespace, WarpBuild offers BYOC that Namespace does not publish, no hard concurrency caps against their per-plan vCPU caps, and a single usage-based meter against their unit-minute multipliers and their storage meters. Namespace publishes more macOS versions and a bleeding-edge Xcode channel, so an iOS team chasing beta toolchains should count both catalogs before deciding.

Against GitHub larger runners and ARC, the tradeoff is the familiar one: WarpBuild adds placement control, region naming, and runner tooling that GitHub-hosted runners lack, and removes the cluster operations that ARC requires.

Editorial recommendation: shortlist on requirement 1 and requirement 2 from the evaluation list, then run the top two candidates in parallel on a real repository for a week. Both switches are one line per job, and both rollbacks are the same line in reverse.