Depot

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the fast container builds I actually need instead of Depot — and understand what the speed comes from, because it is not the machine.

**It is the cache.** A hosted runner starts with nothing every time, so every layer rebuilds. A persistent cache on a machine that is already warm is where the difference lives, and you can have one for the price of a VPS.

STACK
- One or two ordinary machines — one per architecture if you build multi-architecture images
- Docker with BuildKit, or buildah
- A small agent, or just your CI's self-hosted runner
- Caddy in front only if you expose a registry

THE SHAPE
- A self-hosted CI runner on a machine with real cores and fast disks, kept warm between jobs
- BuildKit with a local cache mount, so layers persist across runs on that machine
- A registry cache as well, so a second machine can pull what the first built
- **One machine per architecture**, natively. Emulated cross-architecture builds are several times slower and are the usual reason a multi-architecture build takes twenty minutes

WHAT MAKES A BUILD FAST, IN ORDER
- **Layer order.** Copy the lock file and install dependencies before copying the source. If a one-line change invalidates the dependency layer, no cache anywhere will help you
- **A .dockerignore that is actually correct.** Sending a build context with node_modules and .git in it costs seconds before anything starts
- Cache mounts for the package manager's own cache, so a new dependency does not redownload everything
- Multi-stage builds, with the final stage copying only what runs
- A base image pinned by digest, so a build is reproducible and the cache is not invalidated by somebody else's push
- Measure each of those before buying hardware. Most slow builds are a badly ordered Dockerfile rather than a slow machine

CACHE MANAGEMENT, WHICH IS THE PART THAT ROTS
- A cache with no eviction fills the disk, and a full disk fails every build at once
- Set a size limit and prune on a schedule, keeping the layers actually used recently
- Record cache hit and miss per build and print it. A silent cache miss is why a build got slow and nobody noticed
- A disk watchdog that fails the build with a clear message rather than a mysterious one

SECURITY
- Builds run untrusted code from your own repository, which is fine — until a pull request from a fork does. Never run fork builds on a machine with a warm cache and registry credentials
- Registry credentials injected at build time, never baked into an image, and redacted from logs
- Rootless where the runtime supports it

OPERATIONS
- The runner as a systemd unit with a restart policy
- Disk, memory and cache size monitored, with an alert well before it matters
- A documented way to clear the cache and rebuild from nothing, because you will need it

WHAT MATTERS MOST
Fix the Dockerfile first and measure. Then a warm self-hosted runner with a persistent cache gets most of the remaining difference for the price of a small server — and if it does not, you have learned something more useful than a subscription.