Ephemeral CI runners for Irvyne Consulting.
ICR is our internal GitHub Actions runner infrastructure on hardware in France. This page documents the available sizes for our teams. Contact us to discuss your CI needs.
- 01runs-on: icr-8c-16g
- 028 vCPU · 16 GiB RAM
- 03Fresh VM · 192 GiB disk
- 04RAM reserved · CPU shared
- 05VM removed after the job
How it works
The runner lifecycle.
An illustrative animation, without performance measurements. The jobs shown use example resource sizes.
the stage scrolls sideways
live, sped up · 0 running · 0 waiting · 0 / 64 vCPU · 0 / 380 GB
Click a chapter to freeze the stage and read what happens there; Play resumes.
- 01 · runs-on: icr-8c-16g
A job is queued
Your workflow selects a label that specifies the VM’s vCPU count and memory.
- 02 · outbound HTTPS
The controller contacts GitHub
The controller polls GitHub’s scale-set API. GitHub does not connect into the farm’s network.
- 03 · RAM reserved
Resources control admission
Admission reserves RAM within a shared 288 GiB ceiling and keeps a 24 GiB host margin. A trial also limits runner and image-build allocations to 96 vCPUs. CPU and I/O pressure can defer new runners.
- 04 · verified image
A fresh VM starts
Each job starts in a clone of the active runner image, using a single-use GitHub registration.
- 05 · shared CPU
The job uses its resources
The VM sees its configured vCPUs. CPU can be overcommitted, so jobs slow down under contention. Allocated RAM remains reserved.
- 06 · capacity released
The VM is removed
When the job ends, its VM and disk are removed. Waiting jobs can then start.
Sizes
11 sizes, explicit CPU and RAM.
| Label | vCPU | Memory | Made for |
|---|---|---|---|
| icr-1c-2g | 1 | 2 GiB | Small scripts and notifications |
| icr-2c-4g | 2 | 4 GiB | Aggregate and trivial jobs |
| icr-2c-8g | 2 | 8 GiB | Light tests with more memory |
| icr-4c-8g | 4 | 8 GiB | General builds and tests |
| icr-4c-12g | 4 | 12 GiB | Web, build and API component shards; validate peak memory |
| icr-4c-16g | 4 | 16 GiB | Builds with larger working sets |
| icr-4c-24g | 4 | 24 GiB | Memory-heavy builds and tests; validate peak use |
| icr-4c-32g | 4 | 32 GiB | Memory-heavy tests with modest CPU demand |
| icr-8c-8g | 8 | 8 GiB | Light gates, tool tests and acceptance |
| icr-8c-12g | 8 | 12 GiB | Web and API component tests with a measured CPU budget |
| icr-8c-16g | 8 | 16 GiB | Parallel builds with moderate memory use |
| icr-8c-24g | 8 | 24 GiB | Memory-heavy builds and tests; validate peak use |
| icr-8c-32g | 8 | 32 GiB | Memory-heavy builds and existing workflows |
| icr-16c-12g | 16 | 12 GiB | Kotlin checks and CPU bursts; validate peak memory |
| icr-16c-16g | 16 | 16 GiB | CPU-heavy parallel builds |
| icr-16c-32g | 16 | 32 GiB | Kubernetes kind lanes and nightly tests |
Straight talk
What we promise, and what we do not.
Size from measurements
The suggested uses are starting points. Measure peak memory and leave room for compilers, browsers and containers.
Emergency swap
Each new runner has 4 GiB of disk-backed swap. Swap does not add to the RAM budget; swap activity means the job size needs review.
Working disk
New runners have a 192 GiB disk. A candidate image must retain at least 30% free space after provisioning.
One VM per job
The host firewall isolates each VM, which is destroyed with its disk afterwards. The operator can technically access job data while it runs.
Questions
Choosing and using a runner.
Contact us with any other questions.
How do I choose a size?
Choose the smallest profile that leaves headroom above measured peak memory. More vCPUs help only when the workload can use them. Validate the table’s suggested uses against your project.
How do I read a label?
icr-8c-16g requests 8 vCPUs and 16 GiB of RAM. Every documented label follows icr-<vCPU>c-<RAM>g; use the full label in runs-on.
Is there an aggregate CPU ceiling?
A trial limits total runner and image-build allocations to 96 vCPUs: 1.5 times the host’s 64 hardware threads (32 physical cores). CPU remains shared, and RAM, CPU/I/O pressure and host health also control admission. Existing jobs finish normally when the ceiling is reached.
Are 288 GiB always available?
That is the ceiling on total RAM allocated to runners, rather than a promise of free capacity. The available-memory check can refuse a new runner earlier to protect Proxmox and the other VMs.
Can my organisation use ICR?
The farm currently serves Irvyne Consulting internally. Contact us to discuss your needs; there is no self-service signup or public capacity offer.