Fastest GitHub Actions Runners: Disk I/O

This page offers a detailed comparison of disk I/O performance for various providers of GitHub Actions self-hosted runners. The aim is to assist in identifying the best GitHub Actions self-hosted runner provider for your projects, based on your specific needs.

Providers included in the benchmark#

Official: GitHub (Azure)

Self-hosted: 👋RunsOn (AWS) ·AWS CodeBuild (AWS)

Third-party: Namespace (US/Europe) · Blacksmith (Hetzner) · StarSling (Oracle Cloud) · Avrea (Dedicated hardware) · Warpbuild (Hetzner / AWS) · Ubicloud (Hetzner)

Results#

The comparable table is sorted by Random writes, because this is where network-attached EBS volumes show their main limitation. You can click on any column header to sort by a different metric.

Comparable runner results

This table keeps default runners and RunsOn instance types at 2 vCPU or below, so the network-attached EBS and smaller NVMe results are easier to compare.

Provider	Type	Size	Configuration	Seq Writes (MiB/s)	Rand Writes (MiB/s)↓	Seq Reads (MiB/s)	Rand Reads (MiB/s)	CPU Single	Postgres RW (TPS)	Postgres RO (TPS)	Ping GitHub (ms)	Ping 8.8.8.8 (ms)	Infrastructure
Blacksmith	blacksmith-2vcpu-ubuntu-2404	145 GiB	ext4	2,267	584	4,385	892	4,540	6,155	44,862	N/A	N/A	AS20454 SECURED SERVERS LLC
Namespace	nscloud-ubuntu-24.04-amd64-2x8	63 GiB	overlay	2,466	409	3,374	602	4,736	4,305	35,040	N/A	N/A	AS401483 Namespace Labs
Avrea	avrea-ubuntu-24.04-2-vcpu	77 GiB	ext4	4,361	307	12,800	450	4,522	3,737	40,975	9.9	5.2	AS16276 OVH SAS
RunsOn	i7ie.large	1.2 TiB	overlay	253	177	505	179	2,553	2,958	22,533	1	1.6	AS14618 Amazon.com, Inc.
RunsOn	i7i.large	428 GiB	overlay	418	169	533	199	3,012	3,476	26,465	0.9	1	AS14618 Amazon.com, Inc.
RunsOn	i8g.large	428 GiB	overlay	413	169	533	202	1,947	2,654	17,861	1.8	1.6	AS14618 Amazon.com, Inc.
StarSling	starsling-ubuntu-24.04-2	150 GiB	ext4	1,713	127	1,976	160	3,292	2,613	21,361	62.2	2.5	AS31898 Oracle Corporation
RunsOn	m9gd.large	108 GiB	overlay	147	88	310	176	2,472	4,006	27,621	1.9	1.7	AS14618 Amazon.com, Inc.
RunsOn	c7gd.large	108 GiB	overlay	74	69	159	136	1,557	1,412	9,750	0.8	0.5	AS14618 Amazon.com, Inc.
RunsOn	m8id.large	108 GiB	overlay	114	68	239	136	3,215	3,358	27,009	1.5	1.4	AS14618 Amazon.com, Inc.
WarpBuild	warp-ubuntu-2404-x64-2x	145 GiB	ext4	889	48	1,714	71	3,808	1,688	17,234	23.7	1.1	AS24940 Hetzner Online GmbH
Ubicloud	ubicloud-standard-2-ubuntu-2404	72 GiB	ext4	366	24	1,360	59	2,916	902	16,032	5.8	5.5	AS24940 Hetzner Online GmbH
GitHub	ubuntu-24.04	72 GiB	ext4	201	15	201	37	2,312	1,299	8,875	N/A	N/A	AS8075 Microsoft Corporation
Ubicloud	ubicloud-premium-2-ubuntu-2404	72 GiB	ext4	447	13	1,402	58	2,898	1,178	17,351	5.4	5.3	AS24940 Hetzner Online GmbH
AWS CodeBuild	ubuntu-8.0-large	300 GiB	overlay	259	12	217	2	2,154	N/A	N/A	N/A	N/A	AS14618 Amazon.com, Inc.
RunsOn	m8azn.large	38 GiB	ext4	311	12	413	12	4,266	2,957	62,735	0.9	0.9	AS14618 Amazon.com, Inc.
RunsOn	m9g.large	38 GiB	ext4	319	12	413	12	1,234	2,502	28,060	1.3	0.8	AS14618 Amazon.com, Inc.

RunsOn larger instance types

Default 2-vCPU runners are usually limited by EBS throughput or the small share of local NVMe bandwidth attached to the instance. With RunsOn you can select a larger EC2 instance when a workflow needs real disk throughput, more local storage, or both.

Provider	Type	Size	Configuration	Seq Writes (MiB/s)	Rand Writes (MiB/s)↓	Seq Reads (MiB/s)	Rand Reads (MiB/s)	CPU Single	Postgres RW (TPS)	Postgres RO (TPS)	Ping GitHub (ms)	Ping 8.8.8.8 (ms)	Infrastructure
RunsOn	i7i.16xlarge	14 TiB	overlay	5,523	742	4,611	205	2,917	18,233	135,404	1.6	1.1	AS14618 Amazon.com, Inc.
RunsOn	i7i.8xlarge	6.8 TiB	overlay	5,427	701	4,557	204	2,817	17,002	128,093	1.5	1.1	AS14618 Amazon.com, Inc.
RunsOn	i7i.4xlarge	3.4 TiB	overlay	3,322	643	2,684	189	3,043	12,782	103,140	1.8	2	AS14618 Amazon.com, Inc.
RunsOn	i7i.2xlarge	1.7 TiB	overlay	1,651	596	2,115	185	2,643	8,650	70,226	2.5	1.6	AS14618 Amazon.com, Inc.
RunsOn	i7i.xlarge	858 GiB	overlay	817	335	1,066	210	3,234	7,101	59,852	1.4	1.5	AS14618 Amazon.com, Inc.

Analysis#

How to read the disk numbers#

While CPU speed is the most important factor for most workflows, disk performance can be the limiting factor in specific scenarios that require a high number of IOPS. That’s why it is important to be able to pick runner types that match your needs.

The table compares the disk performance of various providers. Sequential read and write performance is compared, as well as random read and write performance. Sequential performance is more important when dealing with large files, while random performance is more important for small, many files. Benchmark is run as per this Google Cloud article ↗ and measures the performance on the disk where the GITHUB_WORKSPACE resides.

ℹ Why the RunsOn results are split

The main results table keeps default runners and RunsOn instance types at 2 vCPU or below, so the comparison stays close to the usual GitHub Actions runner size. The second table shows larger RunsOn EC2 shapes, because disk bandwidth on AWS changes a lot once you choose bigger instances.

AWS instance store capacity and device count vary by instance type and size, and EBS throughput is also capped by the selected instance’s EBS-optimized bandwidth. When a RunsOn runner has local instance storage, RunsOn automatically formats and mounts it for GITHUB_WORKSPACE. If the instance exposes multiple local NVMe devices, RunsOn stripes them together so the runner can use the combined space and higher aggregate throughput, matching AWS’s own RAID 0 guidance for additive I/O bandwidth.

References: EC2 instance store volumes ↗, NVMe instance-store attachment ↗, EBS-optimized bandwidth ↗, storage-optimized instance-store bandwidth ↗, and RAID 0 throughput ↗.

Comparable 2-vCPU runners#

Blacksmith has the best random write result in the comparable table at 584MiB/s, followed by Namespace at 409MiB/s and Avrea at 307MiB/s.
Avrea has the strongest sequential read/write profile among the comparable runners: 4361MiB/s writes and 12800MiB/s reads.
StarSling is also solid on sequential throughput at 1713MiB/s writes and 1976MiB/s reads, but its random writes are lower at 127MiB/s.
GitHub-hosted ubuntu-24.04, AWS CodeBuild, Ubicloud premium, and the RunsOn EBS-only m8azn.large / m9g.large rows are all in the same low-random-write band, roughly 12-15MiB/s.

EBS and small local NVMe#

Network-attached EBS is fine for many CI jobs, but it shows its limits on random writes. The EBS-only RunsOn rows and AWS CodeBuild land around 11.8MiB/s, while GitHub is at 15MiB/s.
Small local NVMe is better, but not magic. RunsOn c7gd.large and m8id.large reach about 68MiB/s random writes, while m9gd.large reaches 88MiB/s.
The i7i.large, i7ie.large, and i8g.large rows are the more interesting 2-vCPU RunsOn options: they provide much larger local disks and reach 169-177MiB/s random writes.

For most CI workflows this still may not dominate total job time. If the job mostly pulls cache files, archives, Docker layers, or dependencies from the network and then spends time on CPU, sequential throughput and network latency often matter more than random writes. But databases, large monorepos with many small files, package-manager metadata, and test suites that churn the workspace can hit this hard.

Scaling up RunsOn#

The larger RunsOn table shows why instance choice matters. If you want to top the random-write chart, you can do it by selecting a larger local-NVMe instance, starting with i7i.2xlarge at 596MiB/s random writes and 1.7TiB of local NVMe.
Sequential writes scale much further: i7i.8xlarge reaches 5427MiB/s and i7i.16xlarge reaches 5523MiB/s.
Random writes also improve, but flatten earlier in this run: 596MiB/s on i7i.2xlarge, 643MiB/s on i7i.4xlarge, 701MiB/s on i7i.8xlarge, and 742MiB/s on i7i.16xlarge.

RunsOn allows you to select instances with local SSDs, and automatically mounts them for the workspace. That is the practical takeaway: default runners are enough for many workflows, but when disk is the bottleneck you can choose a runner shape with the storage and bandwidth you actually need.