What's new in RunsOn v3.2

RunsOn v3.2 makes CI faster while giving operators clearer control over cost, reliability, and cache security.

The release adds persistent EBS-backed caches, shared telemetry across Flex and Fleet, automatic recovery from eligible Spot interruptions, and a safer path to stronger cache isolation.

Persistent caches without archive round trips#

The biggest new capability is sticky disks.

A job can attach an EBS cache volume with sticky=. RunsOn restores the latest compatible snapshot before the job and creates a new snapshot after a clean run.

Unlike archive caches, sticky disks do not pack and unpack the cache on every run. That makes them a better fit for BuildKit state, Git mirrors, language caches, and large generated directories.

runs-on/action@v2 maps common tool caches to the disk, including Go, Node, pnpm, Ruby, Rust, Python, Gradle, Maven, Playwright, Git, and BuildKit. You can also configure custom project paths when the built-in mappings do not fit.

Sticky disks are scoped by repository, cache lineage, Git ref, operating system, and architecture. A feature branch can start from the default branch cache without writing back to it, and pull requests get the same safe fallback. Windows runners cannot restore Linux caches, and arm64 runners cannot restore x64 caches.

The full sticky disk guide includes the label syntax, BuildKit setup, Windows support, storage sizing, and migration from runs-on/snapshot@v1.

See cost and reliability together#

Sticky disks make CI faster, but EBS volumes and snapshots cost money. v3.2 puts those costs beside queue time, failures, capacity, and Spot interruptions.

Flex and Fleet now publish the same operational metrics. The supplied CloudWatch dashboard and the new SigNoz guide cover job volume, queue time, launch attempts, capacity, failures, and Spot interruptions. The OTLP dashboards also estimate the cost of EC2 instances, live EBS volumes, and retained sticky-disk snapshots.

OTEL dashboard overview showing jobs launched and completed, failure rate, queue latency, estimated job cost, period cost, and estimate coverage

These estimates are not AWS invoices. When pricing is unavailable, the dashboard marks the cost as uncovered instead of counting it as $0. That keeps the totals honest.

You can drill estimated spend down by repository and workflow, compare Flex with Fleet, and watch the ongoing storage cost of retained snapshots. See the OpenTelemetry reference for signal setup and the metric contract.

OTEL dashboard chart showing the estimated hourly cost of retained sticky-disk snapshots

Fleet can recover from Spot interruptions automatically#

Fleet now persists evidence of Spot interruptions and feeds it into the same circuit breaker as Flex.

With the default 2/15/30 policy, two interruption notices within 15 minutes send new launches to on-demand capacity for 30 minutes. Configure the policy in Terraform with spot_circuit_breaker; set it to false to disable it.

If Spot interrupts the instance that ran a job and the first workflow attempt fails, Fleet can rerun the job on on-demand capacity. Automatic reruns require the RunsOn GitHub App to have Actions: read and write. A job with retry: false remains excluded from Fleet-initiated reruns.

OTEL dashboard chart tracking Spot interruptions by EC2 instance family

The Spot pricing guide explains the exact behavior, when to publish a dedicated on-demand fleet, and how to test interruption handling.

Cache isolation gets two opt-in controls#

v3.2 introduces two opt-in isolation controls:

Magic Cache isolation issues short-lived credentials scoped to the repository and branch.
Sticky-disk isolation removes legacy EBS permissions from runner roles after you migrate old snapshot workflows.

Both default to off. That is deliberate: an upgrade should not silently invalidate existing cache paths or legacy workflows.

Start by fixing upgrade blockers and updating custom telemetry queries. Then migrate runs-on/snapshot@v1 workflows to sticky disks, test each isolation mode outside production, and enable the controls. The v3.2 upgrade guide has the complete checklist, including Terraform policy-input renames, the explicit Environment tag, ECR pull-through changes, and CloudFormation preflight checks.

Inspect and clean up jobs from the CLI#

Two CLI improvements make cache cleanup and job diagnostics easier:

roc cleanup JOB_URL shows a plan before deleting recreatable caches and sticky-disk snapshots for a job’s ref.
roc logs JOB_URL --full now includes diagnostics, durable Spot evidence, server and runner logs, CloudTrail events, EC2 console output, and a redacted stack-settings summary.

The CLI reference documents their required permissions and safety boundaries.

v3.2 also adds Ubuntu 26.04 runner images for x64 and arm64, a standalone Terraform ami_sync module for regions without a published AMI, mandatory_extras for Flex, and whole-device I/O and tmpfs utilization metrics.

Before deploying v3.2 to production, work through the upgrade guide.