Use case · DevOps & CI/CD
GitLab Runner hosting
GitLab Runner is the agent that executes GitLab CI/CD jobs, and hosting your own private runners gives control over the build environment, cost efficiency for heavy use, and sovereignty over your code and secrets — versus GitLab's shared runners. Runners need compute for builds and tests, scaled to the job load. Dedicated, EU-hosted infrastructure keeps a runner's code and builds sovereign.
Key points
- GitLab Runner is the agent that executes GitLab CI/CD jobs.
- Self-hosted private runners give control over the build environment versus shared runners.
- They're often more cost-effective than shared runners for heavy build volumes.
- Runners handle your source code and secrets, so their security and location matter.
- Self-hosting on EU infrastructure keeps code, builds, and secrets sovereign.
What is GitLab Runner, and why host your own?
GitLab Runner is the application that executes the jobs of a GitLab CI/CD pipeline — the agent that actually runs the builds, tests, and deployments GitLab's continuous-integration system defines. When a GitLab pipeline runs, its jobs are carried out by runners, so the runners are where the pipeline's real work happens. Runners can be the shared ones GitLab provides, or private runners that an organisation hosts itself and registers to its GitLab, and organisations often host their own runners for control, cost, and sovereignty reasons.
Hosting your own GitLab Runners means providing the infrastructure the runners run on, executing your CI/CD jobs on machines you control. The runners need compute for the builds and tests, and enough capacity for the job load, so the infrastructure must be resourced and scaled to the pipeline's work. This page focuses on hosting GitLab Runners specifically, and why self-hosting them can be preferable to shared runners; the general considerations of CI/CD pipelines are covered on that page, while what follows attends to running your own runners.
Self-hosted runners versus GitLab's shared runners
A key choice is between using GitLab's shared runners and hosting your own private runners, and self-hosting has real advantages for many organisations. Shared runners are convenient — GitLab provides them, and you use them without managing infrastructure — but they carry trade-offs: your code and builds run on GitLab's runner infrastructure, usage is often metered and can be costly for heavy build volumes, and you have less control over the runner environment. Private runners you host give control over the environment, can be more cost-effective for heavy use, and keep the builds, code, and secrets on infrastructure you control.
The honest basis for choosing is your use and what you value. Shared runners suit light or occasional CI/CD, or where minimising infrastructure management matters most and running builds on GitLab's infrastructure is acceptable. Private runners suit heavy build volumes, where their cost-effectiveness matters; needs for specific build environments or hardware; and cases where the code and builds should stay on infrastructure you control, for sovereignty or security. Organisations often self-host runners once their build volume makes shared runners costly, or their code needs to stay on their own infrastructure. We provide the infrastructure for self-hosted GitLab Runners, while being candid that shared runners suit some cases, especially lighter use.
Runner executors: how jobs run
GitLab Runner can execute jobs in different ways, called executors, which determine the environment in which jobs run, and the choice affects how the runner is set up. A common executor runs each job in a container, giving jobs a clean, defined, isolated environment each time, which suits many CI/CD workflows; other executors run jobs directly on the runner machine, or in other environments. The container-based executor is widely used because it gives jobs consistent, isolated environments, which the runner machine must be set up to provide.
The choice of executor shapes what the runner infrastructure must support. A runner using a container executor needs the container platform on the runner machine, so jobs can run in containers; a runner executing jobs directly needs the build tools on the machine itself. The runner machine, whatever the executor, must have the compute, memory, and storage the jobs need, and the setup the executor requires. We host GitLab Runner infrastructure set up for the executor a workflow uses — commonly runners able to run jobs in containers, giving them clean isolated environments — with the resources the jobs need, so that the runners execute the pipeline's jobs in the environment the workflow calls for.
Compute for runners, and scaling to the job load
GitLab Runners need compute for the builds and tests they run, and enough runner capacity for the job load, so that jobs run quickly and without queuing. The builds and tests a runner executes can be demanding, so the runner machines need the compute, memory, and storage to run them quickly; and the number of runners, or the capacity available, determines how many jobs can run at once. Underpowered or too few runners make the pipeline slow or leave jobs waiting, so the runners are where much of the pipeline's speed and capacity lie.
Providing for the job load means runners resourced for the jobs and scaled to how many run. Build-heavy pipelines need runners with strong compute; pipelines with many jobs need enough runner capacity to run them in parallel; and the capacity should grow with the load. GitLab Runners can be scaled by running more, or by autoscaling arrangements that add capacity as jobs arrive. We provide runner infrastructure resourced for the builds and tests, with the capacity to run jobs in parallel and scale with the load, so that a self-hosted GitLab Runner setup runs the pipeline's jobs quickly and promptly, rather than being slowed by runners too weak or too few for the work.
Security: runners handle your code and secrets
GitLab Runners execute CI/CD jobs that handle an organisation's source code and secrets, so the runners' security matters — a runner runs the build with access to the code and the credentials the jobs use. When a runner executes a job, it works with the source code being built and the secrets the pipeline needs, and it may have access used to deploy, so a compromised runner could expose code or secrets or affect deployments. This makes securing the runners, and controlling what they can access, a real concern, especially as the runners execute code as part of their work.
Self-hosting runners on controlled, isolated infrastructure supports their security, keeping the code, secrets, and job execution on infrastructure the organisation controls. On self-hosted runners, the source code being built, the secrets used, and the jobs' execution stay within the organisation's infrastructure, isolated and under its control, rather than on shared runners. Isolating runners appropriately, given that they run code, is part of securing them. We provide secure, isolated infrastructure for self-hosted GitLab Runners, so that the code, secrets, and job execution the runners handle stay on infrastructure the organisation controls, supporting the security of runners that execute jobs with access to sensitive code and credentials.
Sovereignty for code and builds
GitLab Runners handle an organisation's source code — often valuable intellectual property — along with secrets and build artifacts, so where the runners run governs these, making sovereignty a real consideration. When runners execute jobs, the source code, the secrets, and the builds are handled on the runner infrastructure, so its jurisdiction governs them. For organisations whose source code is sensitive or valuable, or subject to requirements about where it may be processed, where the runners run is a genuine concern, not merely a preference.
This is where self-hosting runners on EU infrastructure serves sovereignty. VV Internet Hosting is incorporated in the Netherlands, within the EU, so self-hosted GitLab Runners hosted with us run under European jurisdiction and outside the direct reach of the US CLOUD Act, keeping the source code, secrets, and builds under European law and on infrastructure the organisation controls. For organisations to whom the sovereignty of their source code and build process matters — whether by policy, by the sensitivity of the code, or by requirement — self-hosting the runners in the EU keeps that code and its processing sovereign, rather than running it on shared runners under another jurisdiction.
Where VV Internet Hosting fits — and where it does not
We host dedicated infrastructure for self-hosted GitLab Runners: machines resourced for fast builds and tests, set up for the executor the workflow uses, with the capacity to run jobs in parallel and scale with the load, and secure, isolated hosting for the code and secrets the runners handle — in EU datacenters under European jurisdiction. This suits organisations self-hosting their GitLab Runners that want control over the build environment, cost-effectiveness for heavy build loads, and European sovereignty over their code and builds. For that, we are a strong fit, and we will size the runner infrastructure to the job load.
We are clear about our limits. We provide the dedicated infrastructure your GitLab Runners run on; we do not provide GitLab itself as a managed service, nor operate your CI/CD for you — the runners connect to your GitLab, and the pipelines are yours. If you want GitLab's shared runners or a fully managed CI/CD, those are different, and shared runners suit lighter use. We are the dedicated, sovereign infrastructure on which you self-host your GitLab Runners — suited to those who want control, cost-effectiveness, and European sovereignty over their builds and code. If self-hosting your runners fits your needs, we can host them well.
Related use cases
Questions
GitLab Runners, answered plainly
Common questions about hosting for GitLab Runners.
What is GitLab Runner?
The application that executes the jobs of a GitLab CI/CD pipeline — the agent that actually runs the builds, tests, and deployments. Runners can be the shared ones GitLab provides, or private runners an organisation hosts itself and registers to its GitLab. The runners are where the pipeline's real work happens.
Why self-host GitLab Runners instead of using shared runners?
For control over the build environment, cost-effectiveness for heavy build volumes, specific hardware or environments, and keeping code and builds on infrastructure you control. Shared runners are convenient but run your code and builds on GitLab's infrastructure, and metered usage can be costly for heavy use. Organisations often self-host once build volume makes shared runners costly, or their code must stay on their own infrastructure.
Why does runner security matter?
Because runners execute CI/CD jobs that handle your source code and secrets, and may have deployment access — so a compromised runner could expose code or secrets or affect deployments. Self-hosting runners on controlled, isolated infrastructure keeps the code, secrets, and job execution within your control, which matters since runners run code as part of their work.
Planning GitLab Runners infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.