hushrun and Depot
Updated
Depot makes each CI minute faster: hosted GitHub Actions runners, remote container builders with a shared layer cache, and Depot Cache, a remote cache for build tools such as Bazel, Gradle, Turborepo, Nx and sccache. hushrun makes CI do less: it skips checks and tests that already passed on the same files, and reuses compiled Rust code. They answer different questions, and they work together.
| Depot | hushrun | |
|---|---|---|
| What it is | Runners, container builders and a remote cache | A wrapper around the commands you run |
| CI runners | Yes: Linux, Windows and macOS, x86 and Arm | No: it runs on whatever runner you have |
| Container builds | Yes, on remote BuildKit builders with a layer cache the team shares | No |
| Remote cache for build tools | Bazel, Go, Turborepo, Nx, sccache, Pants, Gradle and GitHub Actions' cache | No: it reuses Rust crates through its own shared store |
| Compiled code | Through the build tool's cache, such as sccache for Rust, C and C++ | Rust only, inside hushrun run |
| Skips a check that already passed | No | Yes, on laptops, in CI and in agents' sandboxes |
| Leaves out tests that already passed | Through a build tool that does, such as Bazel or Gradle | Yes, for the runners in Reuse tests |
What Depot does
- Runners. Depot's GitHub Actions runners replace GitHub's hosted runners with a change to
runs-on, such asdepot-ubuntu-24.04forubuntu-24.04. They work for repositories owned by GitHub organizations, and use Depot's cache with no change to the jobs. - Depot Cache. A remote cache for Bazel, Go, Turborepo, Nx, sccache, Pants and Gradle, and for GitHub Actions' cache. It's preconfigured on Depot's runners, and reachable from laptops and other CI. Entries are kept 14 days by default, with no limit on size unless you set one.
- Rust through sccache. On Depot's runners, sccache finds Depot Cache already configured: you set
RUSTC_WRAPPER: sccache. On a laptop, two variables point sccache at it. - Container builds.
depot buildtakes the same arguments asdocker build, runs on a remote builder, and builds x86 and Arm images natively, with the layer cache shared by project.
Depot does things hushrun doesn't do at all: faster and larger machines, container builds, and caching for many build tools and languages.
How hushrun differs
- It avoids the run, not the minute. A check that passed on these exact files skips, wherever it passed: on your laptop, in an agent's sandbox, or in an earlier CI run. See How it works.
- It works before CI. A coding agent's or a teammate's pass counts for CI, within CI's rules. A runner can't help a run that never needed to happen.
- Tests one by one. When a check's code changed, hushrun can leave out the tests that already passed on the files they read. It's off until you turn it on, check by check.
- Compiled Rust, with trust rules. The shared store takes trusted code only from the CI of branches an admin lists, and a laptop's code never reaches CI. Rust only, and on GitHub Actions only, in CI.
- No machines. hushrun doesn't make a runner faster or build containers.
Using both
hushrun runs on Depot's runners as on any other: wrap your checks with npx hushrun init, and change runs-on for Depot. Checks that already passed skip, and what runs, runs on Depot's machines.
Two things to know:
- Choose one compile cache per Rust job. hushrun's build reuse turns itself off where
RUSTC_WRAPPERis set, as for sccache. Use sccache and Depot Cache for compiles, and hushrun for checks and tests; or leaveRUSTC_WRAPPERunset and use hushrun's shared store. - Depot's runners aren't GitHub's own. With hushrun's shared store, a trusted branch's CI on runners other than GitHub's writes trusted code only after an admin chooses Trust self-hosted runners. Read what that trusts first: Self-hosted runners.
Which to choose
- Choose Depot when each run is slow because of the machine, a container build or a build tool's cache, or when you need macOS, Arm or larger runners.
- Choose hushrun when the same code runs the same checks more than once, across laptops, agents and CI.
- Use both when you have both problems: fewer runs, each on a faster machine.
Sources
Checked on 2026-11-14: