Self-hosted GitHub Actions and Bitbucket runners that register themselves, accept jobs, and exit cleanly. No Kubernetes required.
| runner-a1b2c3 | github actions, myorg | listening |
| runner-d4e5f6 | github actions, myorg | listening |
| runner-g7h8i9 | bitbucket pipelines | listening |
| runner-j1k2l3 | job finished | exiting |
Runners register themselves on start and deregister on exit, so scaling down leaves nothing behind in the CI settings.
Pass your GitHub organisation name and a runner registration token as environment variables. The container self-registers with GitHub on startup.
docker run -d \
-e GITHUB_ORG=myorg \
-e RUNNER_TOKEN=xxx \
ghcr.io/samjuk/github-actions-runner:latestRun as many instances as you need. Each container registers as a separate runner and picks up jobs independently. Use Docker Swarm, Compose, or plain Docker.
docker service scale github-runners=10When a container stops, whether you scale down or the orchestrator terminates it, it deregisters from GitHub automatically. No stale runners, no manual cleanup.
No. ARC is a Kubernetes operator, which is powerful but requires a Kubernetes cluster. This is a plain Docker image designed for teams running Docker Swarm or Compose who want self-hosted runners without the Kubernetes overhead.
GitHub will re-queue the job for another available runner. The container's shutdown hook attempts deregistration, but GitHub also handles stale runners automatically after a timeout.
Yes, runners operate in ephemeral mode by default. Each container picks up exactly one job then exits, preventing any environment pollution between builds.
Yes, there is a separate image for Bitbucket with identical register and deregister behaviour. Both images are maintained and share the same approach.
Anything with Docker installed. A single VM, a Docker Swarm cluster, or a few Compose instances, whatever you already have. The runner image itself is lightweight; the compute requirement depends entirely on what your CI jobs do.