cirunner.dev Join early access

Early access · GitHub Actions & GitLab CI

Your CI.
Our compute.

Your C++, Rust or Android build has outgrown the hosted runners, but a self-hosted runner fleet sounds like a project of its own. Pick a bigger machine, x86 or ARM, with a GPU if you need one. We start a fresh one for every job, keep your build cache around, and bill the minutes it ran.

Join early access How it works
  • Bigger machinesmore cores and RAM than hosted runners
  • Build cachekept between jobs
  • No fleetone VM per job, then gone
pool acme/engine · x86_64-32x64 · eu-central
  1. queuedbuild-release · github.com/acme/engine#4821
  2. bootx86_64 · 32 vCPU · 64 GiB · ccache warm
  3. onlinerunner cr-7f3a2 registered 8.2 s
  4. donejob succeeded 6m 12s
  5. destroyedcr-7f3a2 · billed 6m 21s
3 running 0 idle · 0 to clean up

Runs jobs for

  • GitHub Actions
  • GitLab CI/CD
  • Gitea Actions
  • Forgejo Actions
  • Codeberg
  • Bitbucket Pipelines
  • +9 more

Built for heavy builds

For the jobs that make your team wait

Hosted runners stop where compile-heavy builds start. If your pipeline gets faster with more cores and memory, a bigger machine and a warm cache cut the time your team spends waiting on CI.

  • C / C++

    CMake, Ninja, Bazel, Meson. More cores for parallel compiles, a ccache that survives the VM, enough RAM to link with LTO.

    cmake --build build -j$(nproc)
  • Rust

    Large workspaces, release builds with LTO, and an sccache shared by the jobs in a pool.

    cargo build --release
  • Android / Gradle

    Many modules, R8, a Gradle daemon with room to breathe, and a build cache that survives the VM.

    ./gradlew assembleRelease
  • Game engines

    Unreal and Godot builds, shader compiles and asset cooks that run out of memory and disk on hosted runners.

    RunUAT BuildCookRun
  • Embedded & ARM

    Native arm64 machines for Yocto, Buildroot and cross-toolchains, without QEMU slowing every step down.

    bitbake core-image-minimal
  • CUDA & GPU

    Compile and test CUDA kernels on a real GPU in CI, then let the machine go.

    nvcc -arch=sm_89

How it works

Three steps to a faster build

  1. 01

    Connect your CI

    Install the cirunner.dev GitHub App, or paste a GitLab runner token. Scope it to a repo, an org or a group.

    glrt-••••••••••••
  2. 02

    Choose the machine

    Set vCPU, memory, disk, architecture and region. Attach a compiler cache that survives between jobs. Add a GPU for CUDA builds. Each size gets its own label.

    x86_64 · 32 vCPU · 64 GiB
  3. 03

    Push code

    Target the label in your pipeline. We boot a VM per queued job, register it, run the job and destroy the VM.

    runs-on: cirunner-x86_64-32x64

Configure a pool

Size the machine to the build

This is a preview of the dashboard. Nothing you enter here leaves your browser.

CI platform

Demo field. Stays in this page.

Architecture
Machine x86_64 · 32 vCPU · 64 GiB
Billing Per compute minute, while a job runs
Request this runner in early access

Platforms

GitHub Actions and GitLab CI at launch. Tell us what comes next.

Click a platform to vote for it. We build the next integration for the one with the most votes. Each tile links to our setup guide for running your own runners there today.

Why managed runners

Too big for hosted runners, too small for your own fleet

When a build outgrows hosted runners, the usual answer is to self-host. Then someone on your team owns the VMs, the autoscaler, the images and the 2 a.m. page when the queue backs up. That is a lot of infrastructure for a handful of slow pipelines, so we run it for you.

You run the fleet cirunner.dev
Setup Terraform, VM images, actions-runner-controller or docker-autoscaler, secrets for registration Connect GitHub or GitLab, pick a size
Isolation Long-lived runners carry caches, files and credentials from one job into the next Fresh VM per job, destroyed after it
Scaling Over-provision for peaks or write a controller that scales to zero One runner per queued job, zero when the queue is empty
Upkeep OS patches, runner binary upgrades, full disks, stuck and orphaned runners Ours
Hardware A separate pool to build and maintain for ARM, another for GPU Bigger x86, ARM and GPU machines in one config
Cost Idle VMs bill by the hour, plus the engineer time to run them Compute minutes while jobs run

Pricing

Pay per compute minute

The meter starts when your runner boots and stops when we destroy it. A pool with no queued jobs costs nothing. We will publish per-minute rates for each machine size before general availability; early-access teams help us set them.

Get pricing when it lands
  • vCPUper vCPU-minute
  • Memoryper GiB-minute
  • GPUper GPU-minute, by model
  • Idle pool0

FAQ

Questions

Is cirunner.dev a CI platform?

No. Your pipelines, YAML, secrets and logs stay in GitHub Actions or GitLab CI. We supply the machines that run the jobs and register them as self-hosted runners.

What do you do with my runner token?

We use it to register one runner per job and to remove the runner after the job. On GitLab, a runner authentication token can only register and run jobs; on GitHub, the app asks for the self-hosted runner permission. You can revoke either at any time.

Do jobs share machines?

No. Each job gets its own VM. We destroy the VM, its disk and its credentials when the job ends.

Can I bring my own image?

Yes. Start from our Ubuntu or Debian images or point us at your own image with your toolchain baked in. Tell us what you need in the signup form.

Will this speed up my web app build?

Probably not much. If your pipeline finishes in a few minutes on a 2 to 4 vCPU hosted runner, keep it there. We build for compile-heavy jobs that scale with cores, memory and disk: C and C++, Rust, Android, game engines, large monorepos.

How does the warm cache work if every VM is new?

The VM is new, the cache is not. Each pool keeps a cache volume (ccache, sccache, Gradle, Bazel or Docker layers) that we attach to every job's VM, so a fresh machine still starts with a hot cache.

How is this different from GitHub-hosted larger runners?

You get the same setup for GitHub Actions and GitLab CI, you pick the region, you set CPU, memory and disk one by one instead of picking from a fixed menu, and your compiler cache stays warm between jobs.

Guides

Running your own runners? Start here.

All runner guides