Why there are no self-hosted runners
Self-hosted runners break the security model that makes gated commits work. Our runners are faster anyway.
GitHub, GitLab, and Bitbucket all let you bring your own runner. Connect a VM, install an agent, and your CI runs on your infrastructure. It sounds like a feature. It is not — it is a workaround for slow shared runners. And it breaks the one thing a CI system must guarantee: that results are trustworthy.
The runner is the trust boundary
In gittan.eu, a push only lands on main if the pipeline passes. The pipeline runs security scanning, org-level policies, tests, and build verification. This is the gate — it replaces pull request approval with automated, deterministic enforcement.
That only works if you trust the machine running the pipeline. If a customer controls the runner, they control the gate. A modified runner could skip security scanning, forge a passing result, or ignore org policies entirely. The push would land, and the audit log would say it passed.
Self-hosted runners turn gated commits from a security guarantee into a suggestion.
Why others have them
The reason self-hosted runners exist on other platforms is performance. GitHub Actions shared runners take ~90 seconds just to start — VM provisioning, image pulls, cold caches. Teams bring their own hardware to make CI bearable. That is not a feature, it is a patch for infrastructure that is too slow.
gittan.eu does not have that problem. Runners are warm. Base images are pre-pulled. Steps run in parallel, not a sequential list. Pipeline start time is under a second. A workflow that takes 10 minutes on GitHub Actions typically finishes in 3 minutes on gittan.eu — on our shared infrastructure.
You do not need your own runners when the shared ones are already fast.
What about data residency?
Some teams want self-hosted runners because they do not want their code leaving their network. All gittan.eu infrastructure runs in the EU, in Paris and Amsterdam. Your source code is cloned to a runner in Paris or Amsterdam, executed there, and the working directory is destroyed after the pipeline completes. Code never leaves the EU.
If your organization requires a specific jurisdiction or dedicated tenancy beyond EU residency, that is a conversation we are open to — but it is still our infrastructure, managed by us.