WarpBuild vs Depot for GitHub Actions

Depot and WarpBuild both run GitHub Actions jobs on managed runners that you select by changing a runs-on label. Depot pairs those runners with a container build service and a separate CI engine of their own, while WarpBuild concentrates on the runner fleet: managed runners inside your AWS, GCP, or Azure account, more macOS shapes, and usage based pricing with no subscription underneath it.

Arrived with a different question? Depot alternatives covers the wider field, and migrating from Depot to WarpBuild has the label mapping, the cache changes, and the rollback path.

Every Depot fact below links to the Depot page that states it, checked on 2026-08-13, and every factual correction to this page after that date is logged on the comparison changelog. The feature comparison table is the fact layer. The section headings around it are our reading of the tradeoffs, and you should treat them as such.

What Depot Does Well

Container builds are their strongest product and the place their engineering shows. They publish live per commit benchmark pages for public repositories including PostHog, Mastodon, Moby, and Temporal, with the methodology printed on the page: for every commit, one job builds the project with docker/build-push-action and another builds it with depot build, and both durations are recorded. A continuously updated, reproducible measurement against a named public repository is rare in this category. Read the scope correctly when you compare, because those pages measure depot build against docker build. They do not measure their GitHub Actions runners against GitHub-hosted runners.

The infrastructure work behind it is public too. Depot Metal covers bare metal EC2 with microVMs and NVMe backed storage, the Switchyard orchestrator is described in the Depot CI docs, and the RAM disk write buffer they launched as Ultra Runners is now documented as a per size disk accelerator on their Linux and macOS runners, included at no extra cost on every plan.

Concurrency is a tie. Depot documents no concurrency limits and prints unlimited build concurrency on every plan on their pricing page, including the entry plan. On WarpBuild, run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps. Neither side wins this row, and a comparison page that awards it to one of them is selling you something.

Billing granularity is theirs to keep. Usage is tracked per second with no one minute minimum, in their own words on the pricing page, so a 30 second job bills as 30 seconds. Users are unlimited on their middle and top plans, so there is no per seat charge above the entry tier. Self imposed usage caps that halt builds at a ceiling you set are published on the same page.

The product surface is broad and coherent: container builds, GitHub Actions runners, Depot CI, Depot Cache, Depot Registry, agent sandboxes, and test result analytics. Data transfer into and out of their network is free, including registry and cache traffic. Egress filtering, an allow and deny control on outbound traffic from Linux runners, is available on every plan.

Observability is real on their side. Their docs cover CPU and memory utilization with automated runner sizing recommendations, step level timing breakdowns, failure rate tracking, live runner status, and test result analytics. Shipping cadence belongs to them as well: their changelog carries 222 entries with an RSS feed and covers every month from May 2022 through August 2026 with a single gap month, and their 2026 months are the busiest on that page. They also publish an llms.txt index and a markdown variant of every docs, blog, changelog, and customer page, which is a stronger agent readiness posture than most vendors in this category have.

Where WarpBuild Is Ahead

macOS shapes and published image detail

Depot publishes three macOS labels, depot-macos-26, depot-macos-15, and depot-macos-14, and all three land on the same hardware shape of 8 CPUs, 24 GB of memory, and a 400 GB disk, per their runner types page. WarpBuild publishes five macOS labels across the same three macOS versions in two sizes, 6 vCPU with 22 GB and 12 vCPU with 44 GB of memory, on M4 Pro hardware. The full list is in cloud runners.

Image contents are documented differently on each side. Depot publishes no Xcode version matrix and points at GitHub's runner-images READMEs for image contents, with their own caveat that their images may lag GitHub's. A published Xcode selector or Xcode version list on depot.dev was verified absent on 2026-08-13. WarpBuild publishes the Xcode version its macOS 26 image ships, Xcode 27.0 build 27A5194q, together with the iOS, tvOS, watchOS, and visionOS 27.0 simulator runtimes bundled with it.

Depot also documents a capacity constraint on macOS that has no equivalent on their Linux and Windows runners. Their runner types page states: "due to licensing constraints from Apple, our macOS runner capacity is not fully elastic like our other runner types. We periodically update capacity to match demand, but macOS jobs can experience longer queue times during times of high demand." Their troubleshooting page breaks the same point down into no autoscaling, a fixed pool size, and first in first out processing. In fairness, that page also publishes a remedy: dedicated macOS instances reserved for one organization, on an annual commitment arranged with their team.

WarpBuild asks teams planning unusually high macOS concurrency to talk to support before they scale up, which is documented in cloud runners. Ask both vendors the same question about your peak macOS job count before you commit.

Which clouds your runners can live in

Depot Managed places their data plane in your own AWS account as a single tenant sub account, and their docs gate it two ways: AWS only, and Business plan only. Google Cloud is described there as something they are "considering support for" in the future, and Azure does not appear. Both were verified on 2026-08-13. Terraform is absent from their published surface: their own llms.txt site index returns no provider, module, or documentation page for it as of 2026-08-13.

WarpBuild BYOC runs on AWS, GCP, and Azure, with a Terraform path for AWS. See BYOC and the Terraform docs.

Pricing shape and meter count

Depot's self serve plans are monthly subscriptions with included allowances, and usage above those allowances is metered separately for Depot CI, GitHub Actions jobs, Docker builds, cache storage, agent sandboxes, registry storage, and test results. That is seven meters on top of a plan fee, counted from their pricing page on 2026-08-13. A permanent free tier was verified absent on the same date; what they publish is a 7 day trial with no credit card. Included minutes are consumed at a size multiplier, so a large runner burns the allowance faster than elapsed time suggests, per their runner types page.

WarpBuild pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, and signup includes $10 in free credits. Per minute rates by runner label are published on the pricing page.

SSO posture

Depot publishes what single sign on costs, which is more transparent than most of this category. The SAML and SCIM row on their pricing page shows it unavailable on the entry plan, available on the middle plan as an optional monthly add on with the price printed in the cell, and included on the top plan. Read the shape rather than the number: single sign on is an add on charged on top of an already paid plan, and the add on is priced against that plan.

WarpBuild publishes the same number in one form: SAML 2.0 and OIDC single sign on for a flat $250 per month, whatever the user count. Runner pricing underneath it stays usage based, with no base subscription fee, no platform fee and no seat fee. See SSO and the pricing page.

Support channels

Depot's support rows on their pricing page read: Discord community on all three plans, email support from the middle plan up, and Slack Connect on the top plan only. Their help page lists three surfaces, documentation, email, and the community Discord. A published SLA for the self serve plans was verified absent on 2026-08-13; Depot Managed carries the Business plan SLA.

WarpBuild makes Slack support channels available on demand.

Interactive debugging inside GitHub Actions

Both sides ship observability. The asymmetry is interactive debugging. Depot's first party SSH into a running job is a Depot CI feature. For their GitHub Actions runners, their troubleshooting page routes you to the third party action-tmate action and adds: "Depot doesn't maintain the action-tmate action. Please report any issues or problems on the project GitHub page." A first party interactive debugger for their GitHub Actions runners was verified absent on 2026-08-13.

WarpBuild ships the Action Debugger, an open source action that pauses a workflow and opens an SSH session on the runner, alongside snapshot runners that boot later jobs from a captured VM state, CI observability with right sizing recommendations, and an MCP server for driving the API from an agent.

Data residency and published compliance

Depot Cloud runs in two named AWS regions, us-east-1 and eu-central-1, per the FAQ on their pricing page. Custom regions are a Business plan row on the same page, and region pinning for their GitHub Actions runners specifically is not documented, verified absent on 2026-08-13. WarpBuild names US and EU regions, and enterprise deployments can be placed on region specific infrastructure.

On compliance, compare what each side publishes rather than what each side holds. Depot's public attestation statement is a SOC 2 Type I announcement from March 2024, plus an AICPA SOC badge in their site footer that links to AICPA's general page. A public Type 2 statement or a trust portal on depot.dev was verified absent on 2026-08-13, which is a statement about their published evidence and nothing more. WarpBuild is SOC 2 Type 2 across Security, Availability, and Confidentiality, with the report requestable at trust.warpbuild.com.

Two different egress bills

Two separate bills carry the word egress, and mixing them produces a wrong comparison.

The first is data transfer on the vendor's own network. Depot does not charge for it. Their words: "No egress charges. We don't charge you for egress traffic," from their post on self hosting GitHub Actions. Transfer into and out of their registry and cache is free on the same terms.

The second is the bill your own cloud sends you when runners pull large images and artifacts out of ECR, S3, and similar stores. Depot has a published answer here too, and it is co-location: their cost analysis post argues that because their runners are hosted in AWS, keeping data in the same region removes transfer costs. That argument is scoped to teams whose infrastructure already sits in AWS, and it lives in a blog post rather than on the plan table.

On the WarpBuild 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, so a team on Azure or GCP gets the same outcome as a team on AWS.

Two limits Depot documents on their own runners

Both of these are Depot facts about Depot, quoted from their pages. Neither implies a WarpBuild capability; check the WarpBuild docs against your workload before you plan around either.

Windows containers. From their runner types page: "Windows runners don't come equipped with Hyper-v because of an AWS limitation on EC2. Therefore, if you use things that require it like docker, than Depot Windows Runners are unlikely to work for you." Their Windows launch post scopes the same limit to Windows containers and Hyper-V features and says they are looking at adding support in the future. WarpBuild Windows runner labels, sizes, and images are documented in cloud runners.

Repository ownership. From their GitHub Actions overview: "To use Depot runners, your repository must be owned by a GitHub organization (not a personal account)." Their quickstart adds that configuring the runners requires the organization owner role.

When Depot Is the Better Choice

Three cases, stated plainly.

Your bottleneck is container builds. If most of your GitHub Actions minutes go into docker build, Depot's container build product is the center of their engineering and the exact path their public benchmarks measure. Their cache orchestration and registry are built around that workload. A runner swap alone will not move a container build bottleneck on any platform, so a team in that position should evaluate build products rather than runner fleets.

You want to move off GitHub Actions. Depot ships a CI engine of their own, and if leaving the GitHub Actions execution model is on your roadmap, buying runners from a vendor whose deeper investment lands there is a coherent choice. The callout below has the facts.

You want one vendor for the whole build platform. Runners, container builds, cache, registry, agent sandboxes, and test analytics on one bill and one support channel has real operational value, and Depot covers more of that surface than a runner focused vendor does.

Feature Comparison

The table below is generated from the evidence layer that backs this page. Every Depot cell carries the URL where the fact is stated and the date it was checked, and every WarpBuild cell maps to a claim ID in this page's frontmatter.

Migration Path

Moving in either direction is a runs-on change, which keeps a trial low effort and a rollback just as simple.

 jobs:
   build:
-    runs-on: depot-ubuntu-24.04-8
+    runs-on: warp-ubuntu-latest-x64-8x
     steps:
       - uses: actions/checkout@v4

Two things do not travel with the label. Caching changes, because Depot substitutes their cache for the GitHub Actions cache API automatically while jobs run on their labels, while WarpBuild caching uses the drop-in WarpBuilds/cache and WarpBuilds/setup-* actions documented in caching. And depot build steps inside a workflow belong to their container build product, so they keep running against Depot until you replace them.

Migrating from Depot to WarpBuild has the full label map across Linux, Windows, and macOS, the cache feature by feature comparison, the compatibility table with unsupported rows stated plainly, the parallel run plan, and the rollback steps.