runaway

// self-hosted github actions orchestration

Your runners.
Your servers.
No middleman.

An open-source orchestrator for ephemeral GitHub Actions runners. Drop it on the VMs you already own, point it at your GitHub orgs, and get clean scale-to-zero CI — no Kubernetes cluster, no SaaS owning your compute.

BSL 1.1 · runs on any docker host · no inbound port

scale-set / ci-linux live
rnr-7f3a
rnr-2c9e
rnr-b14d
rnr-e80a
rnr-44f1
rnr-9ab6
rnr-1d2c
rnr-c057
rnr-3e9f
one job each · then gone AutoRemove: true

// what you get

01 RUNAWAY

True ephemeral, by design

Every runner runs exactly one job, then the container is destroyed and replaced — AutoRemove, not restart: unless-stopped. No accumulated state, no writeable-layer bloat, no "why is this runner acting weird" at 2am.

02 RUNAWAY

Multi-host, no open port

Add a machine — a homelab box, a Hetzner VM, anything with Docker — by running one agent that dials out to the hub over an authenticated WebSocket. No inbound port, no SSH, no Tailscale. NAT-friendly by construction.

03 RUNAWAY

Scale to zero, warm floor

Runaway watches GitHub for queued jobs and sizes each pool to demand. minRunners=0 scales to zero between jobs, or keep a warm floor so the next push does not cold-start. Optional webhooks cut latency; polling needs no public exposure.

Plus persistent caches for npm/pnpm/yarn/pip/Go/cargo, per-scale-set private-registry credentials, opt-in isolated runtimes, and a dashboard that shows what every host is doing.

// where it fits

Self-hosting is the right call. The other options make you give something back.

vs / kubernetes

actions-runner-controller

ARC is GitHub's official answer, and it's the right tool at enterprise scale. But it runs on Kubernetes — which means you own a cluster: control-plane upgrades, node patching, cert-manager, load balancers, webhook plumbing, and the expertise to secure all of it. For one team on a few VMs, that's a second full-time system. Runaway is Docker-native: a compose stack on a Linux box, no cluster underneath.

vs / saas

hosted runner services

Actuated, RunsOn, and the hosted-runner vendors are genuinely fast — but each puts itself back in the loop. Actuated runs the control plane you depend on. RunsOn deploys into your AWS account but stays their product, on their cloud. You end up self-hosting the compute and renting the orchestration. Runaway is the orchestration, open-source, on whatever hardware you already have — no account, no vendor plane, no cloud lock-in.

vs / diy

systemd + docker run --rm

A systemd unit and docker run --rm works, and plenty of people run exactly that. It just does not scale past one host or one person’s head: no UI, no autoscaling, no multi-host placement, no job history — and the moment someone reaches for Docker Compose with restart: unless-stopped, the containers stop being ephemeral and start bloating. Runaway is that same primitive — one ephemeral container per job — with orchestration, a dashboard, and multi-host built in.

// ~5 minutes

From zero to a runner taking jobs.

No cluster to provision, no agent to compile. Bring up the stack, connect a GitHub org, and the reconciler does the rest.

~/runaway
$ docker compose up -d → hub + agent online
# add a GitHub org + PAT in the UI → org validated
# create a scale set → pool spawned in seconds
$ git push → a runner picks up the job
# job finishes → runner destroyed · pool back to floor
$

// install

Drop it on a box you own.

Clone the repo, generate three secrets, and bring up the stack:

RUNAWAY_MASTER_KEY=$(openssl rand -base64 32)
BETTER_AUTH_SECRET=$(openssl rand -base64 32)
RUNAWAY_LOCAL_AGENT_TOKEN=$(openssl rand -base64 32)

docker compose -f docker-compose.example.yml up -d

Open http://localhost:3000, create your admin account, add an org + PAT, and create a scale set. The hub and a co-located agent run as one compose stack.