WarpBuild vs Blacksmith for GitHub Actions

Blacksmith and WarpBuild both replace GitHub-hosted runners with managed machines that a workflow selects through a runs-on label, and both bill per minute with no base subscription fee. The structural difference is where the compute lives: Blacksmith publishes a vendor-operated fleet procured from data center providers in the US and EU, while WarpBuild runs jobs on WarpBuild-hosted runners or inside your own AWS, GCP, or Azure account.

Arrived with a different question? Blacksmith alternatives covers the wider option set with cited facts, and Blacksmith to WarpBuild migration has the label diff, the cache notes, and the rollback steps.

Every Blacksmith fact on this page links to the Blacksmith page that states it, checked on 2026-08-13. See the comparison changelog for what changed since the last verification pass. Recommendations are editorial and are marked as such.

What Blacksmith Does Well

Adoption is a one-line change with a wizard behind it. Their quickstart publishes a literal runs-on: diff plus a Migration Wizard that rewrites workflow files, with published mappings from ubuntu-latest, windows-latest, and macos-latest to their equivalent labels. Adoption friction is close to zero.

The free tier is real and permanent. Their pricing page prints 3,000 free minutes per month on every pay-as-you-go tier and requires no credit card at signup. Their runner docs publish the denomination (x64 2vCPU minutes) and the conversion ratios for ARM, Windows, and macOS families, which is more transparency than most vendors give a free tier.

Caching is transparent by default. Their dependency cache docs state that zero code changes are required: standard actions/cache and setup-* actions hit storage colocated with the runners, with 25 GB per repository per week free. On top of that they ship sticky disks, Docker layer caching, Docker container and service-image caching, Bazel build caching with no .bazelrc changes, and a beta git checkout cache. That is a deeper caching product surface than most runner vendors publish.

Observability is a genuine strength. Their docs cover a GitHub Actions analytics dashboard with p99 job duration and cost by repository, run history, cross-run log search with a query syntax, machine metrics with no configuration, test analytics, Slack monitors with VM retention, and SSH access into a running job at no additional cost.

Concurrency is parity, and their docs say so plainly. Their runner docs state that Blacksmith does not impose any concurrency limits on how many vCPUs or jobs run simultaneously. WarpBuild takes the same position: run as many jobs as your workflows need, and generally available Linux and Windows runners do not have plan-level concurrency caps. Neither side wins this dimension.

Compliance is parity too. Their security page states SOC 2 Type 2 and GDPR with quarterly penetration testing, plus a published DPA, a sub-processor list with an RSS feed, a trust center at trust.oneleet.com, and a public status page. WarpBuild holds SOC 2 Type 2 with evidence at trust.warpbuild.com. Treat this row as a tie.

Platform coverage is broad and current. Their runner docs publish Ubuntu 24.04 and Ubuntu 22.04 on x64 and ARM at five sizes each, Windows Server 2025 (labelled public beta in their own docs), and macOS with two shapes. They also publish nested virtualization on x64 Linux runners and automatic free size upgrades when their fleet has spare capacity.

They write about their systems, including the bad days. Their engineering blog includes a public postmortem of a July 2026 outage alongside architecture writing. They also publish nine customer stories and roughly 29 named customers on their customers page, an OSS program, and a Series B led by Peak XV Partners announced August 12, 2026 claiming more than 6,000 companies running GitHub Actions on the platform.

That is a strong product with real momentum. The rest of this page covers the dimensions where the two platforms differ.

Where WarpBuild Is Ahead

Runners inside your own cloud account

WarpBuild BYOC runs on AWS, GCP, and Azure, with the runner VMs provisioned inside your account and your network. No BYOC, VPC, or customer-account deployment option appears anywhere Blacksmith publishes: not on their pricing page, not on their security page, and nowhere in their docs sitemap as of 2026-08-13. Their published architecture is the opposite design by choice: their runner docs describe maintaining their own homogenous pool of compute so that customer jobs avoid competing with other on-demand workloads on hyperscalers.

This matters when a job needs to reach a private database, an internal registry, or a service behind your own VPC boundary, and when a security review asks which account the compute runs in.

Data residency you can name and select

WarpBuild names US and EU regions. Blacksmith names three regions in their Docker container caching docs: US West, EU West, and EU Central, and their security page states the fleet is procured from data center providers in the US and EU. What their docs do not publish is a way for a customer to choose one. BLACKSMITH_REGION appears in their docs only as an environment variable read inside a sticky disk example, and no page documents a region picker for a job or an organization. If your compliance answer requires naming the region your GitHub Actions jobs run in and pinning it, that is a WarpBuild capability today and an open question on their side.

Egress cost during deployments

On the enterprise tier, runners pull large images and artifacts from ECR, S3, and similar stores with zero egress cost to you. Zero egress applies whether your runners live in your cloud or ours. Deploy-heavy workflows that move gigabytes out of object storage on every release are where this shows up on the bill.

Blacksmith publishes nothing on the subject in either direction. We found no egress claim, no free-egress statement, and no data-transfer billing statement on their homepage, pricing page, security page, or product docs on 2026-08-13. This page does not claim they charge for egress. The accurate statement is that they publish no position on it.

API surface and Terraform

On the Blacksmith side, their llms.txt advertises an OpenAPI spec at https://docs.blacksmith.sh/api-reference/openapi.json, and that URL returned HTTP 404 on 2026-08-13, as did /api-reference and /api-reference/introduction. No api-reference URL appears in their sitemap. The word Terraform appears in none of their product or legal docs pages. Their published programmatic surfaces are the blacksmith CLI for Testboxes (early beta) and their useblacksmith/* GitHub Actions. The honest reading is that their API reference is unavailable rather than that no API exists, and that no Terraform provider is published.

Platform teams that manage runner configuration as code, or that want GitHub Actions infrastructure in the same Terraform state as the rest of the account, have a path on WarpBuild today.

macOS image and Xcode coverage

Counted on both sides on 2026-08-13:

Their runner docs state that their macOS runners follow the corresponding GitHub-hosted macOS runner images, and their smallest macOS runner is 6 vCPU. We checked their full docs sitemap for an Xcode version list, a per-Xcode label, or a beta-Xcode selector and found none. WarpBuild publishes its Xcode versions per image, ships Xcode 27.0 on the macOS 26 image while the upstream GitHub macOS 27 image is in beta, and offers multiple sizes and configurations per chip. For an iOS team that pins a specific Xcode build in GitHub Actions, that difference decides the evaluation.

Single sign-on

WarpBuild offers SAML 2.0 and OIDC single sign-on for a flat $250 per month, whatever the user count, listed on the pricing page. Blacksmith authenticates through GitHub only. Their settings docs state that Blacksmith currently only supports login using GitHub, their permissions docs state that Blacksmith uses GitHub for authentication and inherits your GitHub organization's structure, and their Enterprise tier bullets on the pricing page list no SSO row as of 2026-08-13. Access derives from GitHub org role and repository permissions, with no independent role model.

For a team whose identity provider is the system of record for access reviews, GitHub-only authentication is a real gap. For a team that already governs everything through GitHub org membership, it costs nothing.

Published shipping cadence

WarpBuild publishes runner image and platform changes every month in the public docs changelog, with an RSS feed. Blacksmith publishes no changelog we could find: https://www.blacksmith.sh/changelog returned HTTP 404 on 2026-08-13, no changelog URL appears in either of their sitemaps, and four common product RSS paths all returned 404. One narrow RSS feed does exist, at their sub-processor changelog, and it tracks sub-processor changes rather than product releases. Their engineering blog is the nearest public shipping signal, and it carries a four month gap and a three month gap in the last twelve months.

Editorial: a changelog matters to a buyer who needs to know when a runner image changed under a green build that started failing.

The shape of the bill

WarpBuild pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Signup includes $10 free credits.

Blacksmith also publishes usage-based per-minute pricing with no base subscription, platform, or seat fee, so the difference is meter count rather than a floor. Their pricing page lists priced add-ons for Docker layer caching, sticky disks, and static IPs, their support terms price Premium Support as a formula, and their coding agent product [code]smith meters agent compute units on its own docs page. A buyer forecasting spend there tracks runner minutes plus up to five further meters. See their pricing page for current rates; this page restates none of them.

Debugging and runner tooling

WarpBuild ships snapshot runners, remote Docker builders, CI observability, an MCP server, and the Action Debugger. Blacksmith's SSH access and monitors cover much of the same live-debugging ground, and their analytics dashboard is strong. Two pieces have no published Blacksmith equivalent as of 2026-08-13: an MCP server, which we could not find anywhere in their 33-URL docs sitemap, and snapshot runners that boot a later job from a captured VM state.

When Blacksmith Is the Better Choice

Some real cases favor them, and pretending otherwise wastes your time.

You want a permanent free monthly allowance. Their 3,000 free minutes per month per organization renew every month with no credit card. WarpBuild grants $10 in credits at signup, which is a one-time grant against usage-based rates. For a small repository with light GitHub Actions usage, their free tier can cover the whole workload.

Your builds depend on a remote Bazel cache with no configuration. Their Bazel build caching is transparent, with no .bazelrc changes and no workflow configuration. WarpBuild publishes no Bazel remote cache equivalent. If that feature is carrying your build times, moving costs you something real.

You rely on sticky disks for arbitrary persistent paths. Their sticky disks mount persistent ext4 volumes by key, up to five per job. WarpBuild covers the Docker case with remote Docker builders that hold a persistent layer cache, and the dependency case with the WarpBuild cache action, and snapshot runners cover whole-VM state. Arbitrary keyed volumes are a Blacksmith feature with no direct WarpBuild counterpart.

You want transparent interception of actions/cache with no workflow edit. WarpBuild caching is a drop-in action swap to WarpBuilds/cache@v1 rather than a transparent redirect. That is one line per cache step.

Your team is happy with GitHub-only access control and has no SAML requirement, no BYOC requirement, and no region-pinning requirement. On those three dimensions the WarpBuild advantages do not apply to you.

Feature Comparison

Every cell below either carries a link to the vendor page stating the fact or is marked verified absent with the date we checked.

Proof on the WarpBuild side: named customers on the homepage logo wall include SonarQube, Comcast, Sky, Braintrust, Bitcoin, and LanceDB, with case studies carrying before and after numbers and public repositories running warp- labels in their workflows.

Migration Path

The label change is one line per job, in both directions. blacksmith-2vcpu-ubuntu-2404 becomes warp-ubuntu-latest-x64-2x, and the rest of the workflow file stays as it is unless it uses useblacksmith/* actions.

Three things need attention beyond the label: workflows that adopted useblacksmith/setup-docker-builder and useblacksmith/build-push-action had their cache-from and cache-to directives removed per Blacksmith's own guidance and need a replacement path, sticky disk steps have no direct equivalent, and the first run on any cache key is a cold run while caches warm.

Rollback is the same one-line change in reverse and can be done the same day. Blacksmith to WarpBuild migration has the full label mapping table, a complete workflow example, the cache notes, the compatibility table with unsupported rows stated plainly, and guidance for running both platforms side by side on a subset of workflows.