Overview of caching strategies in RunsOn

Fast runners are only a small part of a modern CI/CD platform. Caching capabilities are very important to make your workflows fast and efficient.

RunsOn offers multiple caching mechanisms so you can choose the right mix of speed, cost and portability for every job.

Choosing the right strategy

1. Need to minimize workflow change and stay compatible with GitHub-hosted runners? Start with Magic Cache. It behaves like the official cache when RunsOn isn’t available so you don’t have to update your workflows if you need to go back to official runners. On RunsOn, Magic Cache works as a transparent accelerator for both actions/cache-related actions, and type=gha buildkit export in docker builds.

2. Want the best price/perf for Docker layers? Benchmark S3 cache vs Ephemeral registry vs Snapshots. Ephemeral registry is usually a bit faster than S3, and block-level snapshots are the fastest when you have a large number of layers to cache, because it skips the entire docker layer export and compression steps. Snapshots incur additional EBS storage costs though.

3. Have large datasets or git repos you want mounted like a disk? Use EFS. No compression overhead, unlimited size, but more expensive than object storage.

4. Chasing every last millisecond and your workload fits in RAM? Go bold with tmpfs – just give the runner enough memory.