Ephemeral CI runners on hardware that is actually fast.
ICR runs your GitHub Actions jobs on fresh virtual machines carved out of a dedicated AMD EPYC 9355P server in France: 4.4 GHz boost clocks, NVMe ZFS storage, an 8 Gbps line. Each job gets its own VM. When the job ends, the VM is destroyed with its disk.
- 18:27:03push irvyne-consulting/website · 41a66b3
- 18:27:15job queued on icr-4c
- 18:27:19runner created icr-4c-bc4d74 · linked clone of the runner template
- 18:27:34job running · 31 s after the push · online
- 18:28:40job completed · 1 min 06 s · 44 browser tests included · succeeded
- 18:28:47runner destroyed · disk removed
- 01Dedicated FranceEarly access
Running now for a first customer, on hardware we own.
- 02European tierPlanned
Opens when five organisations have registered interest.
- 03ColocationPlanned
Moves the hardware to a certified data centre and brings the availability commitment.
How it works
One job, one virtual machine, then nothing.
- 01
You keep your workflows
A job targets a label such as icr-4c through the runner variable your organisation already uses. Switching back to ubuntu-latest is one variable.
- 02
GitHub tells us a job is waiting
Our controller long-polls GitHub's runner scale-set API, outbound over HTTPS. GitHub never connects to our network and nothing is exposed on the Internet.
- 03
A VM is born for that job
A linked clone of a versioned template boots in seconds, registers with a single-use configuration and runs exactly one job.
- 04
It is destroyed
Power-off, disk removed, memory returned to the host. The next job starts from a clean image again.
Tiers
Two tiers, one lifecycle.
The same ephemeral builders, on hardware we own in France or on rented European bare metal. Each tier carries its status; the status on this page is the status on your annex.
Dedicated France
The fastest tier, on hardware we own in France.
- AMD EPYC 9355P, 4.4 GHz boost, NVMe ZFS storage, 8 Gbps line
- One customer per VLAN, one fresh VM per job, destroyed with its disk
- Encryption at rest with keys we hold; a named operator you can call
- Nothing inbound: the runners call GitHub
The hardware sits in our own rack today. We sign availability commitments once it is colocated in a certified data centre.
On request, contracted per customer.
European
The same ephemeral builders on rented bare metal at European providers.
- Bare metal at European providers: Germany, Finland or France, your choice
- Same lifecycle: one fresh VM per job, destroyed with its disk
- Disks encrypted with keys we hold, off the rented server
- More capacity at a lower price; bursts welcome
Designed, not running. This tier opens when five organisations have registered interest.
An indicative monthly price is published when the tier opens.
- Planned
- Designed, not running. Register interest; the tier opens on a public threshold.
- Early access
- Running for a few customers, no availability commitment, priced per customer.
- Available
- Contracted, with the availability commitment written in the annex.
Sizes
Three sizes, 4 GiB of memory per vCPU.
| Label | vCPU | Memory | Made for |
|---|---|---|---|
| icr-2c | 2 | 8 GiB | browser and end-to-end tests, light checks |
| icr-4c | 4 | 16 GiB | most builds and test suites; the default |
| icr-8c | 8 | 32 GiB | compilation-heavy builds: JVM, Rust, large Docker images |
Straight talk
What we promise, and what we do not.
Shared capacity, best effort
The concurrency you contract is an admission ceiling on a shared server, not reserved hardware. Jobs queue when the server is full.
Ephemeral, with honest limits
A VM and its disk are destroyed when the job ends, so nothing from a job is meant to outlive it. The operator can technically access what a job can read while it runs; the contract says so in writing.
No availability commitment yet
ICR is in early access. A canary job runs every 30 minutes, and the fallback to GitHub-hosted runners stays in your hands: one variable, no code change. The commitment arrives with colocation.
Evidence
What we measured, and what we did not
Measured on 2026-09-13 on the early-access host: one fresh VM per run, no registry push, one observation per cell unless stated. Historical GitHub-hosted figures are medians of production jobs from March to May 2026 on a different revision, date and cache state: they describe the wait a team lived with, not a like-for-like benchmark.
| Job | ICR, measured | GitHub-hosted, historical |
|---|---|---|
| Java service, Gradle build with tests and Docker image | 5.7 min on 4 vCPU (warm cache); 5.7 min warm, 9.0 min cold on 8 vCPU | 9.7 min median for the test job alone (n = 8) |
| Rust service, Docker image build after a source change | 2.3 min on 8 vCPU | 22.9 min median (n = 11) |
| Rust service, Docker image build, cache disabled | 5.2 min on 8 vCPU | not measured |
Runner online 18 to 23 seconds after the push, job running at 24 seconds, VM destroyed about 3 seconds after the job (early-access host, 2026-09-13).
Onboarding
Four steps, no agent to install.
- 01
You install the Irvyne Consulting Runners GitHub App on your organisation; it can only manage self-hosted runners.
- 02
We create your scale sets and you set the runner variable to icr-4c, and to icr-8c for heavy workflows.
- 03
One week of canary on a few repositories, then the organisation-wide switch when your tech leads say so.
- 04
A monthly job-level statement. Pricing is contracted, not listed.