Depot vs WarpBuild: Cache Depth Against Bring-Your-Own-Cloud
Depot and WarpBuild publish the same managed Linux rate at every size. As with Depot and Blacksmith, price does not decide this one, so architecture does.
Both are drop-in GitHub Actions runner providers and both list Linux x64 at $0.004/min at 2 vCPU, $0.008 at 4, $0.016 at 8, and $0.032 at 16. There is no managed price difference to choose on.
What differs is what each adds beyond compute. Depot brings build acceleration heritage: RAM disks by default, uncapped cache at up to 1,000 MiB/s, and per-second billing. WarpBuild brings a BYOC mode at $0.002/min where runners execute in your own cloud account, and arm64 rates 25% below its own x64 pricing.
Standard GitHub-hosted runners are free and unlimited on public repositories, and public repos get 4 vCPU and 16 GB rather than the 2 vCPU and 8 GB private repositories receive. No paid runner beats free, so everything below assumes a private repository past its included minutes.
Depot vs WarpBuild
| Depot | WarpBuild | |
|---|---|---|
| Linux x64, 2 vCPU | $0.004/min | $0.004/min |
| Linux x64, 8 vCPU | $0.016/min | $0.016/min |
| Linux arm64, 2 vCPU | No separate rate published | $0.003/min |
| BYOC mode | No | Yes, $0.002/min plus your cloud bill |
| Cache | Unlimited, up to 1,000 MiB/s | Not published as uncapped |
| Disk | RAM disk by default | Standard |
| Billing granularity | Per second | Per minute |
| Isolation | Single-tenant EC2 per job | Managed, or your own cloud under BYOC |
Pick on the bottleneck you actually have
| If your constraint is | Pick | Because |
|---|---|---|
| Large Docker layer or dependency caches | Depot | Uncapped cache at 1,000 MiB/s and a RAM disk |
| A wide matrix of short jobs | Depot | Per-second billing removes the rounding tax |
| ARM64 builds | WarpBuild | Published arm64 rate 25% under its x64 pricing |
| Private network or data residency | WarpBuild | BYOC runs inside your own cloud account |
| Existing committed cloud spend | WarpBuild | BYOC control-plane fee plus your negotiated compute rate |
| Nothing in particular | Either | The managed rates are identical; trial one job on each |
Switching, and switching back
Every managed runner in this category is selected by the runs-on label, so adoption and reversal are the same one-line edit. That makes a two-week trial on your slowest job a better decision procedure than any amount of modelling.
jobs:
build:
runs-on: ubuntu-latest # GitHub-hosted
# runs-on: latchkey-small # Latchkey
How to evaluate a managed runner honestly
Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.
- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.
The verdict
There is no managed price difference, so ignore the rate card and choose on constraint.
Cache-bound or matrix-heavy pipelines: Depot, for uncapped cache and per-second billing.
ARM builds, private networking, or existing cloud commitments: WarpBuild, where BYOC at $0.002/min plus your own compute is a genuinely different cost structure.
Both are a one-line runs-on change, so run each on your slowest job for a week rather than deciding from this table.