Self-hosted CI runners
Run GitHub Actions on a microVM you control. The runner only makes outbound connections, so no port is ever exposed — and Krova's own CI runs on one.
Cubes from $2.92/moNo credit card to sign up
Why run this on a Cube
Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable.
Nothing exposed to the internet
A runner is outbound-only: it long-polls GitHub over HTTPS and GitHub never connects back. You publish no ports at all, so your build machine has no inbound attack surface — unlike a box you have to open up for a webhook.
Your toolchain, kept warm
Root access means any language, build tool or system dependency, installed exactly as your pipeline needs it. Because the Cube persists between jobs, dependency caches and Docker layers are still there on the next run instead of being rebuilt every time.
Its own kernel, not a shared one
Each Cube is a Firecracker microVM with its own kernel and a per-cube sandbox, so builds are isolated at VM grade rather than by namespaces over a shared host. Snapshot a fully-provisioned runner and bring new ones up from it.
Costs nothing when idle
Power a runner off between jobs to stop compute billing and pay by the minute only while a build is actually running. RAM and disk are reserved 1:1, so build times stay predictable instead of sagging under a noisy neighbour.
How it works on a Cube
Install the GitHub Actions runner on a Cube and point a workflow at it.
- 01
Create a Cube, then add a non-root user for the runner — GitHub's installer refuses to configure as root.
- 02
Download the Linux x64 runner, install its .NET dependencies, and register it against your organisation or repository.
- 03
Install it as a systemd service, so it survives a restart and comes back on its own.
- 04
Point a workflow at it with runs-on: [self-hosted] — and add Docker to the Cube if your jobs build or test against containers.
Those four steps are the shape of it. The full walkthrough has every command, plus the three whose error messages do not describe the actual problem. Read the GitHub Actions guide
Frequently asked questions
Can I use this with a public repository?
You should not, and this is GitHub's own guidance rather than ours: anyone can fork a public repository and open a pull request whose workflow runs arbitrary code on your runner. Keep self-hosted runners on private repositories. Registering at the organisation level puts a runner in the default runner group, which only private repositories can reach.
Do I need to open any ports on the Cube?
No. The runner only makes outbound connections to GitHub, so nothing needs to be published. SSH is enough to set it up, and the Cube stays unreachable from the internet for CI purposes.
Can I still get a clean machine for every job?
Yes, two ways. Register the runner with --ephemeral and it accepts one job then deregisters, so nothing carries over between builds. Or drive the whole Cube lifecycle from your pipeline with the REST API, SDK or CLI: create one from a prepared snapshot at the start of a run and delete it at the end. Both need a little automation around them; a persistent runner does not.
Launch your first Cube
Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it.