Chimera
A GitHub Actions runner rewritten from scratch, and the first public documentation of the protocol that governs it.
Chimera is a drop-in replacement for GitHub Actions self-hosted runners: a single Rust binary that manages several runners in parallel, runnable as a systemd service, in a Docker container or simply from a terminal. It speaks the same registration and job-execution protocol as the official runner, so it works with any existing workflow without changes.
The most interesting part of the project, though, is not the rewrite. It is what had to be produced to make it happen.
The problem
The official self-hosted runners are slow, heavy on resources, prone to memory leaks and awkward to manage. Each runner is a separate process, with its own configuration and its own service to monitor. In an organisation with dozens of runners spread across several machines, the operational overhead becomes significant: updates to propagate, workspaces to clean, containers and orphan processes that survive the end of the job.
Chimera was born to make that experience better, with a focus on performance, reliability and multi-runner management.
The protocol, documented for the first time
GitHub's official runner is open source, but the protocol it speaks is not. There is no specification, no endpoint reference, no description of the formats in which runners and backend exchange jobs, logs and status. The only way to understand it is to read the implementation and watch the traffic.
Reimplementing that behaviour in Rust meant rebuilding the protocol piece by piece. That work became a public specification of over 1,500 lines, released together with the code: the entire lifecycle of a runner, from registration to authentication, from job polling to log streaming, through to completion: endpoints, payloads, formats and non-obvious behaviours.
What emerges is a protocol layered by years of migrations: three distinct backend services, two generations of APIs that coexist and are chosen job by job, three different kinds of token in circulation, and an internal serialisation format all of its own. Many details do not fail loudly but silently: a timestamp with the wrong precision generates no errors, it simply produces a UI that shows incorrect data.
It is material useful to anyone who has to integrate with Actions, build CI tooling or understand what is going on when a runner stops behaving as expected. To date there is nothing equivalent.
What "drop-in" means
The compatibility is not partial. Chimera supports running steps on the host and in containers, all kinds of actions (Node.js, Docker, composite), the whole ${{ }} expression system, all workflow commands, conditions, timeouts, continue-on-error, cancellation, live log streaming to the GitHub UI and actions/cache.
Registration works exactly as with the official runner: same token, same labels:
chimera register --url https://github.com/org/repo --token AABBC... --name runner-0
chimera register --url https://github.com/org/repo --token DDEEF... --name runner-1
chimera startFrom there the runners poll concurrently, each with a clean workspace for every job.
And more
A single process manages all the runners, with error isolation: the failure of one does not drag the others down. Cleaning up workspaces, containers and orphan processes is automatic. And caching no longer goes through GitHub's remote service: Chimera exposes a local cache server compatible with actions/cache, which makes hits immediate with no change to the workflows.
Limits
GitHub Enterprise Server is not supported and Windows is out of scope. It should also be borne in mind that the protocol the project relies on, not being officially documented, can change without notice: it is the implicit trade-off of any compatible implementation, and it is one of the reasons the specification is kept together with the code and not separately.
Open source
Chimera is released under the MIT licence. As well as being a tool you can use in production, it aims to be a readable reference implementation of the GitHub Actions runner protocol: code and specification validate each other, and anyone can check, correct or extend both.