Temp Storage

By default, every Sprinters-powered runner comes with 10 GiB of temp storage (just like GitHub-hosted runners).

The type, the size and the performance of this temp storage are all fully configurable via the runs-on: label in your workflow yml.

There are 3 types of temp storage available: gp3, zram and ephemeral:

By default, the storage type is auto-selected based on the following criteria, in this order:

• If RAM is at least 3x larger than the desired temp space, zram is used.
• If not and the instance type has ephemeral NVMe storage, ephemeral is used.
• Otherwise, gp3 is used.

You can set the size of the auto-selected temp storage via the label:

runs-on: sprinters:aws:ubuntu-latest:m7i.large:temp=64

This will auto-select the optimal storage for the specified instance type using the formula above for 64 GiB of temp storage. For the m7i.large instance in this example, this will result in a 64 GiB gp3 EBS volume with 3000 IOPS and 150 MiB/s throughput.

The auto-selection can be overridden by explicitly specifying one of the available storage types below.

zram

When all the temp storage fits in RAM, you can forego EBS entirely and use an ultra-fast zstd-compressed RAM disk instead:

runs-on: sprinters:aws:ubuntu-latest:temp=zram/16

This gives you the highest possible I/O performance and completely eliminates your EBS costs!

RAM is not pre-allocated and an empty zram temp disk does not use any memory. The size in the label merely serves as an upper bound for the size of the uncompressed data. Data you add to the zram disk is first zstd-compressed, and will, depending on how compressible it is, only consume about half or a third of its size in RAM. And when the runner terminates, the entire zram disk is automatically discarded.

A runner with 16 GiB RAM with compressible temp data can therefore easily accommodate a 16 GiB (or larger!) zram disk. But remember that the RAM the zram disk occupies isn’t available to other processes. So, keep a close eye on usage and consider moving to a larger or memory-optimzed instance if needed.

gp3

When using gp3 EBS volumes, by default a 10 GiB gp3 EBS volume with 3000 IOPS and 150 MiB/s throughput is attached to your instance as temp storage.

The volume is reformatted on every boot and destroyed after the job completes.

Size

Unlike GitHub-hosted runners, Sprinters-powered runners are not restricted by a fixed amount of temp space. If your job needs more temp space, you do not need to resort to brittle hacks like deleting the preinstalled software using actions like jlumbroso/free-disk-space.

Instead, you can freely pick the exact amount of temp space you need, between 1 and 65536 GiB by specifying it in the label:

runs-on: sprinters:aws:ubuntu-latest:temp=gp3/256

Optimization

EBS charges you by the allocated GiB. This makes it financially sound to right-size. Unfortunately, guessing the necessary capacity isn’t always easy. To guide you, Sprinters shows the actual temp usage at the end of every job run in the Complete runner section of the job output:

If your temp volume was say 100 GiB and utilization was 38%, you can safely slash your EBS costs in half by adjusting its size to 50 GiB for future runs with enough room to spare:

runs-on: sprinters:aws:ubuntu-latest:temp=gp3/50

Performance

By default gp3 volumes are provisioned with 3000 IOPS and 150 MiB/s throughput.

For I/O-intensive jobs, Sprinters gives you full control over the performance (and EBS costs!) of your temp volume. You can freely scale it from 3000 to 80000 IOPS and 150 to 2000 MiB/s throughput.

To do so, specify the desired IOPS (4000 in this example) and throughput (750 MiB/s in this example) in the label:

runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/4000/750

The exact EBS performance upper limits depend on the size and IOPS of the gp3 volume. The IOPS:GiB ratio is limited at 500:1 and throughput:IOPS ratio at 0.250:1. As this can be annoying to calculate, Sprinters lets you specify the convenience value max for both IOPS and throughput to automatically calculate the maximum supported performance for the given volume size and IOPS.

To use the maximum supported number of IOPS for this size, you can therefore specify:

runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/max/750

Or the maximum supported throughput for these IOPS:

runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/4000/max

Or both:

runs-on: sprinters:aws:ubuntu-latest:temp=gp3/100/max/max

ephemeral

Instances that have ephemeral NVMe storage can make use of their much faster internal store volumes instead:

runs-on: sprinters:aws:ubuntu-latest:c6id.8xlarge:temp=ephemeral

The first ephemeral volume of the instance is then fully used for temp storage.

In this case, with a c6id.large instance, this gives you 1900 GB of ephemeral storage with 536,666 IOPS and zero EBS costs!