Warm builds. Introducing Avrea persistent disks

Stop paying for the same preparation

A small code change can trigger a lot of repeated work. Download the same dependencies. Pull the same container images. Rebuild intermediate files that barely changed. Then throw away the runner, along with everything that could have helped the next build.

Caching reduces that work, but moving a cache has a cost too. An archive needs to be restored and unpacked before the build, then packed and uploaded when the job finishes. For large caches or directories full of small files, those steps can become a substantial part of the run.

Persistent disks give your tools a filesystem they can reuse across jobs. Point a tool's cache directory at the disk, and it can read the files where they already live. You avoid the archive restore and save cycle for that directory, and your build spends more of its time on what changed.

Keep the useful state across fresh VMs

Each job still runs in a fresh Avrea VM. The persistent disk is separate from the runner's operating system and is tied to a given repository. Avrea attaches a private copy of the disk's saved state for the job to use.

The disk is for things that don't easily fit into our existing package or build caches: something that would still need caching, like a custom tool that only knows how to cache to a directory. You choose which paths go on the disk. Your tools continue to manage their own cache entries and invalidation.

The benefit depends on the tool, the cache contents, and how much changes between runs.

Avrea manages disk attachment, job cleanup, and publication of the next saved version. Your team gets reusable storage without maintaining a long-lived runner fleet.

Let pull requests start from a warm cache

You choose which branches may publish changes to the disk. The default writer policy follows the repository's default branch, so builds on that branch can prepare state for later jobs.

Other jobs can work on disposable copies. A pull request can read the saved cache, add its own files, and run its build. Its changes are discarded afterward. The next job starts from the published state again.

Parallel jobs get separate copies, so they do not compete over one live filesystem. If two writer jobs start from the same version, the first to finish publishes. A stale writer cannot overwrite newer contents; its changes are discarded rather than merged. A writer job still publishes when one of its steps fails, as long as the runner finishes normally. Cancelled and crashed jobs don't publish.

Treat the disk as a cache that every job can read. Pull requests from forks get a disposable copy too, so keep secrets, credentials and anything you can't rebuild somewhere else.

Docker gets to keep its layers

On supported Linux runners, Docker cache on persistent disk preserves Docker images, local build cache, and volumes between eligible jobs. Plain docker build and the default builder can reuse that state automatically.

An application build can reuse unchanged layers. A test job can reuse an image it previously pulled. For teams building containers throughout the day, that removes a lot of repeated work.

Container-based Buildx builders need a stable builder name and keep-state: true so their cleanup step retains the BuildKit state. Avrea's remote Docker cache can also be used alongside the disk. The Docker caching documentation covers setup and supported images.

Start with one cache directory

For organizations with persistent disks enabled, open the repository's settings in the Avrea console. Enable Persistent disk, choose the size and operating systems, and review the writer branches. Enable Docker cache on persistent disk separately if your Linux jobs need it.

For other tools, use PERSISTENT_DISK_PATH. Avrea provides separate disks for Linux, macOS, and Windows. On Linux you get /mnt/persistent, on macOS /Volumes/AVREA_PERSISTENT and on Windows the drive letter P: (for persistent).

Persistence is best effort and requires a datacenter with persistent storage. A job can run without the disk, so your build should always be able to start with an empty cache.

Disks cost $0.50 per GB per month for the size you provision, whether or not it's full. Sizes run from 10 to 500 GB, 50 GB by default, and a disk can grow later but not shrink. Each operating system gets its own disk and its own charge, so one 50 GB Linux disk is $25 for a full month. The Docker cache lives on the Linux disk at no extra charge, and disk charges draw on the same monthly credit as runner minutes.

Start with the directory your jobs spend the most time repopulating. Let a writer branch warm it, then compare later runs. If your repository settings don't show Persistent disk yet, contact Avrea to get it enabled for your organization.