Use case · DevOps & CI/CD
CI/CD pipelines
A CI/CD pipeline automates building, testing, and deploying code, running jobs on runners that need compute for builds and tests. Fast pipelines mean fast feedback, and they scale to run many jobs in parallel. Self-hosted runners give control, cost efficiency, and sovereignty over source code and secrets. Dedicated, EU-hosted infrastructure keeps a CI/CD pipeline's code and builds sovereign.
Key points
- A CI/CD pipeline automates building, testing, and deploying code.
- Jobs run on runners or agents that need compute for builds and tests.
- Fast pipelines give fast feedback, which is central to their value.
- Self-hosted runners give control, cost efficiency, and sovereignty over code and secrets.
- EU hosting keeps a pipeline's source code, builds, and secrets under European sovereignty.
What is a CI/CD pipeline, and what does it need?
A CI/CD pipeline automates the steps of building, testing, and deploying software — continuous integration automatically building and testing code as it changes, and continuous delivery or deployment automatically delivering or deploying it. Instead of these steps being done manually, a pipeline runs them automatically whenever code changes, so that changes are built, tested, and made ready to deploy consistently and quickly. This automation is central to modern software development, giving developers fast feedback on their changes and a reliable, repeatable path from code to deployment.
A CI/CD pipeline needs compute to run its jobs — the builds, tests, and deployment steps — on machines called runners or agents, and it benefits from that compute being fast and plentiful enough to run jobs quickly and in parallel. The pipeline's jobs consume real resources, especially the builds and tests, which can be demanding, so the infrastructure running them affects how fast the pipeline is. This page focuses on the infrastructure a CI/CD pipeline runs on; specific runner and server software are covered on their own pages, while what follows attends to what running a pipeline needs, including self-hosting its runners.
Build and test compute: runners and agents
The jobs of a CI/CD pipeline — building code, running tests, and deploying — execute on runners or agents, which are the machines that carry out the pipeline's work, and these need compute suited to the jobs. Building software can be computationally demanding, compiling code and assembling artifacts; running tests can be extensive, exercising the software thoroughly; and these jobs run on the runners, consuming their compute, memory, and storage. So the runners must be resourced for the builds and tests they run, since underpowered runners make the pipeline slow.
Providing for a CI/CD pipeline therefore means providing runners with adequate compute, memory, and storage for the jobs, and enough of them to run the pipeline's jobs. A build-heavy pipeline needs runners with the compute to build quickly; a test-heavy one needs runners to run the tests; and pipelines that run many jobs need enough runner capacity for them. We provide the infrastructure for CI/CD runners — machines resourced for the builds, tests, and deployments a pipeline runs, with the capacity for its jobs — so that the pipeline's work executes on infrastructure suited to it, rather than being slowed by runners too weak or too few for the jobs.
Performance: fast builds mean fast feedback
The speed of a CI/CD pipeline matters greatly, because a fast pipeline gives developers quick feedback on their changes, while a slow one makes them wait and disrupts their work. When a developer makes a change, the pipeline builds and tests it, and the sooner that completes, the sooner the developer learns whether the change is good and can proceed; a slow pipeline leaves them waiting, breaking their flow and slowing development. So pipeline speed directly affects developer productivity and the pace of development, making fast builds and tests valuable beyond the pipeline itself.
Achieving fast pipelines means runners with strong compute and fast storage, and enough capacity to avoid jobs queuing. Powerful runners build and test quickly; fast storage speeds the file-heavy work of builds; and enough runner capacity means jobs run promptly rather than waiting for a free runner. High-core-count processors help build and test in parallel, and fast NVMe storage speeds the many file operations builds perform. We provide runner infrastructure with the compute, storage, and capacity for fast pipelines, so that builds and tests complete quickly and developers get prompt feedback — because the speed of the pipeline bears directly on how quickly developers can work.
Scalability: parallel jobs and handling load
A CI/CD pipeline often needs to run many jobs, sometimes in parallel, so it must scale to handle the load of the changes and jobs it processes. Multiple developers making changes, pipelines with many parallel jobs, and busy periods all generate many jobs to run, and the pipeline must handle them without long queues, which means enough runner capacity to run the jobs, in parallel where they can be. Parallelism also speeds pipelines directly, since independent jobs run at once rather than in sequence, so scaling out runners both handles load and speeds pipelines.
Supporting this means enough runner capacity, able to grow with the load, to run the pipeline's jobs promptly and in parallel. A pipeline's job load can vary — quiet at times, heavy at others — so runner capacity sized for the load, with the ability to add runners as it grows, keeps jobs running without long waits. We provide runner infrastructure that scales to a pipeline's job load — enough capacity to run jobs in parallel and promptly, growing as the load rises — so that a CI/CD pipeline handles the changes and jobs it processes without becoming a bottleneck, keeping builds, tests, and deployments flowing even when many are running.
Self-hosted versus cloud CI/CD runners
A significant choice is between self-hosting a pipeline's runners on infrastructure you control and using cloud-hosted runners provided by a CI/CD service. Cloud-hosted runners are convenient — the service provides the runners, and you use them without managing infrastructure — which is valuable, but they carry trade-offs: your code and builds run on the provider's infrastructure, costs for heavy use can be substantial, and you have less control over the runner environment. Self-hosted runners, on infrastructure you control, require providing the runners but keep the builds, code, and environment in your hands, and can be more cost-effective for heavy use.
The honest basis for choosing is what you value against the effort. Cloud runners suit light or occasional use, or where minimising infrastructure management matters most and running builds on the provider is acceptable. Self-hosted runners suit heavy use, where their cost-effectiveness and control matter, and cases where the code and builds should stay on infrastructure you control — for sovereignty or security. Organisations often self-host runners when their build volume makes cloud runners costly, or when their source code should not run on a third party's infrastructure. We provide the infrastructure for self-hosted CI/CD runners, while being candid that cloud runners' convenience suits some cases, especially lighter use.
Security: code, secrets, and deployment access
A CI/CD pipeline handles sensitive things — source code, credentials and secrets, and access to deploy to production — which makes its security important, since a compromised pipeline could expose code, leak secrets, or push malicious changes. The pipeline touches an organisation's source code as it builds it, holds secrets it needs to build and deploy, and often has access to deploy to production systems, so it concentrates sensitive assets and access. A security failure in the pipeline could therefore be serious, exposing code or secrets or allowing unauthorised deployments, which makes securing it a real concern.
Self-hosting the pipeline's runners on controlled infrastructure supports its security, keeping the code, secrets, and deployment access on infrastructure the organisation controls rather than a third party's. On self-hosted runners, the source code being built, the secrets used, and the deployment access all stay within the organisation's infrastructure, isolated and under its control, which reduces the exposure of these sensitive assets. We provide secure, isolated infrastructure for self-hosted CI/CD runners, so that the code, secrets, and deployment access a pipeline handles stay on infrastructure the organisation controls — supporting the security of a pipeline that concentrates sensitive assets and access, which is part of why organisations self-host their runners.
Sovereignty, and where VV Internet Hosting fits
A CI/CD pipeline handles an organisation's source code — often among its most valuable intellectual property — along with secrets and build artifacts, so where the pipeline runs governs these, making sovereignty a real consideration. VV Internet Hosting is incorporated in the Netherlands, within the EU, so a CI/CD pipeline's self-hosted 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, self-hosting the pipeline in the EU addresses it.
We host dedicated infrastructure for self-hosted CI/CD runners: machines resourced for fast builds and tests, with the capacity to run jobs in parallel and scale with the load, and secure, isolated hosting for the code, secrets, and deployment access a pipeline handles — in EU datacenters under European jurisdiction. This suits organisations self-hosting their CI/CD that want fast pipelines, cost-effectiveness for heavy build loads, control over the runner environment, and European sovereignty over their source code and builds. We are clear about our limits: we provide the dedicated infrastructure the runners run on, not a managed CI/CD service that provides the pipeline platform itself. We are the dedicated, sovereign infrastructure on which you self-host your CI/CD runners — and if that fits your needs, we can host it well.
Related use cases
Questions
CI/CD pipelines, answered plainly
Common questions about hosting for CI/CD pipelines.
What is a CI/CD pipeline?
An automated sequence that builds, tests, and deploys software — continuous integration automatically building and testing code as it changes, and continuous delivery or deployment automatically delivering or deploying it. Instead of doing these steps manually, a pipeline runs them automatically whenever code changes, giving developers fast feedback and a reliable, repeatable path from code to deployment.
Should I use self-hosted or cloud CI/CD runners?
It depends on your use and values. Cloud runners are convenient but run your code and builds on the provider's infrastructure, and can be costly for heavy use. Self-hosted runners keep the builds, code, and environment in your hands, can be more cost-effective for heavy use, and keep code on infrastructure you control — which matters for sovereignty and security. Organisations often self-host for heavy build volumes or sensitive code.
Why does CI/CD security matter so much?
Because a pipeline handles sensitive things — source code, credentials and secrets, and often access to deploy to production. A compromised pipeline could expose code, leak secrets, or push malicious changes, so it concentrates sensitive assets and access. Self-hosting runners on controlled, isolated infrastructure keeps the code, secrets, and deployment access within the organisation's control.
Planning CI/CD pipelines 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.