How big a server does a build cache need? CPU, RAM and disk
You are sizing a disk, not a compute tier. The server is one small program that idles in tens of megabytes, so the question is how much cache you want to keep.
Starting sizes
| vCPU | RAM | Disk | |
|---|---|---|---|
| Absolute minimum | 1 | 1 GB | cache cap + about 5 GB for the system |
| Recommended start, about 5 to 20 developers plus CI | 1 to 2 | 2 GB | 25 to 50 GB SSD |
| Larger CI farms | 2 to 4 | 4 to 8 GB | cache cap + about 20% |
These are starting points from our deployment guide. Your build graph decides the rest. It is hard to be limited by CPU, because the busy path is reading and writing stored files, not computing.
Set a size cap
Choose how much cache you want, set it with FSCACHE_MAX_BYTES, and make the disk about 20% bigger. When the cache reaches the cap it removes the least recently used entries and never grows past it. The extra room covers file system overhead and uploads in progress.
The value is in bytes. It is easy to be wrong by a factor of 1024, so copy one:
| Cap | FSCACHE_MAX_BYTES |
|---|---|
| 10 GiB | 10737418240 |
| 20 GiB | 21474836480 |
| 50 GiB | 53687091200 |
| 100 GiB | 107374182400 |
Two mistakes that look like "the cache doesn't help"
- A cap that is far too small, such as 20 MiB when you meant 20 GiB, makes it evict constantly, so the hit rate never climbs. The status page at
/statuszshows the cap it read next to current usage. - Leaving the cap at its default of 0, which means no limit, on a small disk is the one setup that will fill the disk.
Put it near the runners
On bigger setups the network matters more than the processor. A small server in the same region, ideally the same network, as your CI runners beats a large one far away.
Related: Gradle and Maven setup and Jenkins and CI build cache. Full detail is in the Docker deploy guide.