Runners that come back

Self-hosted GitHub Actions runners on Kubernetes.

Errand runs GitHub Actions jobs on a cluster you control. A runner starts for each job, does the work, and goes away. Arm and x64 pools grow with the queue.

Status
Running AutoButler's own CI
Built on
Actions Runner Controller
Architectures
Arm64 and x64
Each runner
4 cores, 16 GiB
First cluster
Azure Kubernetes Service

How it works

Change one line in your workflow.

  1. Pick a runner label

    Point a job's runs-on at an Errand label instead of ubuntu-latest. Workflows, secrets, and permissions stay in GitHub.

  2. A runner starts for the job

    GitHub's Actions Runner Controller sees the queued job and starts a runner pod. The node pool adds machines when the queue grows.

  3. The job runs, then it is gone

    Each runner gets four cores and 16 GiB. When the job ends, the runner is removed and the next job gets a clean one.

Roadmap

Ours first, then yours.

Errand is not open to other teams yet. It opens up in this order.

  1. Our own CI

    Errand runs AutoButler's builds today, for Quark and the projects around it, on one Azure cluster.

  2. We host it

    The same stack, run by us for other teams. That waits on a stronger wall between jobs, so one team's build can never reach another's.

  3. You run it

    Bring a Kubernetes cluster, a container registry, and a storage bucket, and run the same stack on your own infrastructure.

From AutoButler

Built by the people behind Quark.

AutoButler makes Quark, a private home cloud. Errand is the build system we made to ship it.