Using tmpfs for faster builds

Since v2.8.2, you can configure RunsOn to automatically create a tmpfs volume, which will then be used to host the following directories:

• /tmp (overlay)
• /home/runner (overlay)
• /var/lib/docker (bind mount)

For now the tmpfs volume is set to use up to 100% of the available memory on the runner, so if the job suddenly fails for an unknown reason, just increase your runner size (highly recommended to use large-memory instance types such as r7* or r8*).

Usage

Flex

Enable tmpfs from the job label and choose a runner with enough memory for the job’s writes:

jobs:
  tmpfs:
    runs-on: runs-on=${{ github.run_id }}/family=r7/ram=16/extras=tmpfs
    steps:
      - run: df -ah /mnt/tmpfs
      - run: df -ah /home/runner
      - run: df -ah /tmp
      - run: df -ah /var/lib/docker

Fleet

For Fleet, publish a runner fleet with tmpfs enabled in Terraform:

runners = {
  linux-tmpfs = {
    cpu    = 8
    ram    = 16
    family = ["r8g"]
    image  = "ubuntu24-full-arm64"
    extras = ["tmpfs"]
  }
}

Use cases

Using tmpfs is a good fit for:

1. Speeding up I/O intensive workflows, since any writes to the directories listed above are done in memory, and are much faster than writing to disk.

Accessing tmpfs

If you include tmpfs in the extras parameter of your workflow job, a tmpfs volume will be created in the /mnt/tmpfs directory, and the directories specified above will automatically be bind-mounted or overlay-mounted into it.

Using tmpfs in your workflow

jobs:
  efs:
    runs-on: runs-on=${{ github.run_id }}/family=r7/ram=16/extras=tmpfs
    steps:
      - run: df -ah /mnt/tmpfs
      # tmpfs            16G  724K   16G   1% /mnt/tmpfs
      - run: df -ah /home/runner
      # overlay          16G  724K   16G   1% /home/runner
      - run: df -ah /tmp
      # overlay          16G  724K   16G   1% /tmp
      - run: df -ah /var/lib/docker
      # tmpfs            16G  724K   16G   1% /var/lib/docker

Considerations

Again, this is a kind of YOLO mode (but with potentially great rewards), so make sure your are correctly right-sizing your runners.

Volatility (stopped/warm pools)

tmpfs is volatile. Because /var/lib/docker is bind-mounted onto the tmpfs volume, all Docker state (images, containers, volumes) is lost on every stop/start. For stopped pools, warm boots skip host setup to keep resume latency low, so any container started during preinstall on the first boot will not exist on the next boot. Recreate required containers via prerun or job hooks.

Limitations

• extras=tmpfs is only available on Linux runners.