CI/CD on a VPS: How to Organize Pipelines Properly Without Cloud Monsters

1. Introduction: Why CI/CD Without Cloud Giants

Over the past couple of years, many European companies have started looking at familiar CI/CD services like GitHub Actions, GitLab SaaS, or AWS CodePipeline with less excitement than before. The reason is simple: using “cloud monsters” has become not only expensive, but also inconvenient.

First, cost. When you have dozens or hundreds of pipelines running every day, the bill for runner minutes and additional cloud services becomes an unpleasant surprise for the CFO. Especially in 2025, when big players’ prices are creeping up faster than inflation.

Second, GDPR and other regulatory fun. European businesses are being checked more strictly for compliance with personal data processing rules. And when your code is running through someone else’s infrastructure in unknown data centers, lawyers start nervously adjusting their glasses.

Third, dependence on external APIs. The moment GitHub or AWS decides to “bolt on” a new limit, change an SLA, or roll out an update that breaks backward compatibility, your development becomes a hostage to someone else’s decisions. And the business needs predictability—not another late-night production fire caused by somebody else’s update.

And finally, control over the infrastructure. Your own VPS gives you that freedom: you decide which runner to use, where to store artifacts, and how exactly to configure pipelines. It’s not only about saving money, but also about confidence—your CI/CD lives where you decided it should, not where a cloud provider happens to want it.

That’s why more and more teams are returning to the good old approach: your own VPS + custom or open-source CI/CD. A bit more setup at the start—but full long-term independence.

2. Choosing a VPS for CI/CD: Important but Not-So-Obvious Parameters

When it comes to CI/CD on a VPS, most developers look only at the number of cores and the amount of RAM. The logic is simple: the more resources, the faster the project will build. But in practice the bottlenecks show up in completely different places—and that’s where the surprises begin.

First — the disk. If your provider is still stuck on old SATA or even slow SSDs, forget about comfortable builds. During compilation—especially in Java, C++, or Rust projects—the disk gets hammered so hard that the CPU can simply sit idle waiting. That’s why the key parameter is NVMe speeds and IOPS. The higher, the better. In practice the difference can be huge: a build that takes 15 minutes on SATA can finish in 5–6 on decent NVMe.

Second — networking. In CI/CD it matters no less than the disk. Every docker pull and docker push is tens or hundreds of megabytes—and sometimes gigabytes—of images. If your VPS provider has a tricky plan with throttled bandwidth or a traffic cap, a pipeline can unexpectedly get stuck in a jam. Pay attention not only to “honest” megabits per second, but also to burst speeds — they determine how quickly load spikes get cleared.

Third — nested virtualization. If you run integration tests that require KVM or QEMU, life will be hard without nested virtualization support. Many budget providers save on this, and you end up suffering with hacks. It’s better to check up front: does the chosen VPS support nested virt? Otherwise, you’ll have to move part of your tests somewhere else.

And finally — providers. In Europe there are several proven players:

●  Hetzner (Germany/Finland) — affordable and powerful VPS options with excellent NVMe.

●  OVHcloud (France/Germany/Poland) — flexible plans and a stable network, but sometimes you’ll have to wrestle a bit with support.

●  Scaleway (France/Netherlands) — a solid choice to get started with, with friendly APIs.

●  Time4VPS (Lithuania) — a budget option, but with decent quality.

Choosing a VPS is like choosing an office chair: pick a random one and you’ll regret it every day. It’s better to take one careful look at these “invisible” parameters once than suffer later from slow builds and failing pipelines.

3. Local CI/CD Solutions That Fit a VPS

Okay, we’ve picked the server—now the main question is: what CI/CD should you install on it? There are plenty of solutions on the market, but not all of them are equally convenient for a VPS. What matters is not only “it works,” but also “it doesn’t eat the whole machine for a single pipeline.” Let’s look at the most interesting options.

Woodpecker CI
This is essentially a “lightweight clone” of Drone that went its own way after Drone became too corporate. Woodpecker is fully self-hosted, easy to run in Docker, and doesn’t require tons of RAM. Its superpower is simplicity: pipelines are described in YAML, and Git integration is minimalist but sufficient. A great option if you want CI/CD “without extra buttons” and you want to control every step.

Gitea + Actions
If you like the GitHub Actions concept but don’t want to depend on GitHub, Gitea saves the day. In recent versions it gained Actions support that’s very similar to the original. The difference is that everything runs right on your VPS. You can run Gitea as your Git server and configure runners for your pipelines next to it. You get almost the same experience as GitHub Actions, but locally and under your control. For small teams, it’s the perfect middle ground between simplicity and flexibility.

GitLab CE

Community Edition is the free version of GitLab, and it’s often chosen as an “all-in-one machine.” In a single interface you get Git repositories, an issue tracker, a wiki, and full CI/CD. For teams that value having everything integrated in one place, GitLab CE can be a universal solution. The downside: it’s noticeably heavier than Gitea or Woodpecker, so you need to account for your VPS resources.

Jenkins (2.440+) with containers
Yes, Jenkins is still alive—and not just alive, but actively evolving. Recent versions include many optimizations, and if you run build agents in Docker containers, Jenkins can be trimmed down pretty well for VPS resources. It’s no longer that “Java monster” that eats gigabytes of memory for a couple of pipelines. Of course, Jenkins is still heavier than Woodpecker, but if you need maximum flexibility and a ton of plugins, it’s still a solid workhorse.

Forgejo + Actions
Forgejo is a fork of Gitea that went its own way with a focus on larger teams and corporate scenarios. Essentially, if Gitea is “GitHub for friends,” Forgejo is “GitHub for a dev department.” It also has Actions, federation support, and more room to scale. If your team is growing and Gitea starts to feel cramped, moving to Forgejo is a logical step.

Bottom line:

●  For small projects and startups — Woodpecker or Gitea.

●  For teams that want an “all-in-one” tool — GitLab CE.

●  For enterprise or larger teams — Jenkins or Forgejo.

CI/CD on a VPS has long stopped being “exotic”—it’s a mature and flexible approach.

4. Pipeline Architecture Without the Cloud

When we say “CI/CD on a VPS,” the obvious question is: how do you build a pipeline architecture that’s fast, reliable, and doesn’t turn into a ball of hacks? It’s not that scary. You just need to split the roles and think a little about the network topology.

Dedicated build runner.
The first mistake many people make is running build and deploy on the same server. It seems convenient, but in practice it becomes a mess: builds eat resources, deployments start to lag, and if the VPS goes down, the whole process collapses. It’s much more reliable to have a separate VPS for build agents. They assemble the project, run tests, and prepare artifacts there.

A separate VPS for deployment.
The second server is the “safe harbor” for production deploys or staging. It isn’t overloaded by compilation, and only finished artifacts land there. It’s easier to keep things stable and split responsibility: if a build fails, the dev team fixes it; if a deploy fails, DevOps takes a look.

Networking inside the data center.
If you choose a VPS from a solid provider, you can almost always set up private networking or a VLAN. That means the build server and the deploy server communicate directly inside one data center, without going out to the public internet. And that greatly speeds up artifact transfers: Docker images or archives move over the internal network at gigabit speeds, not through an external link with its limitations.

Optimizing Docker layers.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

Caching dependencies.
Another lifesaver is caching. Node.js, Python, Java, Go—all these ecosystems love downloading gigabytes of packages. Set up a local cache on the VPS and you’ll get dependencies instantly instead of constantly hitting npm or PyPI. That can cut build time by multiples.

So: a simple setup—“VPS for builds + VPS for deploy + internal network + caching”—turns your CI/CD into a stable, fast mechanism that’s no worse than cloud solutions.

5. CI/CD Security on a VPS

CI/CD on a VPS is, of course, freedom and savings—but it also comes with responsibility. In cloud solutions, the provider solves part of the problems; here, it’s all on you. The good news: most security practices are easy to implement even on a regular VPS.

Isolating build agents.
Rule number one: never blindly trust the code you’re running—even if you wrote it. A pipeline can accidentally (or intentionally) run commands that gain access to the server. So it’s better to keep build agents in a “sandbox.” There are two lightweight options for this:

●  LXD — fast containers with full isolation, almost like VMs.

●  Firecracker — micro-VMs from AWS that start in milliseconds and are ideal for temporary builds.
Both options let you run builds so that a random script can’t crawl into neighboring processes.

Secrets management.
The second pain point of any CI/CD is secrets: keys, passwords, tokens. Storing them in YAML—or, God forbid, in the repository—is a direct path to leaks. Secret management systems help here:

●  Vault by HashiCorp — a classic: it stores secrets centrally and hands them out on a “minimum, for a limited time” principle.

●  Sealed Secrets — an option for Kubernetes where secrets are encrypted and stored right in Git, and decrypted only on the cluster. And yes, this works without the cloud too if you have your own self-hosted Kubernetes.

SSH access to deploy servers.
The most vulnerable point is the deploy step, when CI/CD needs to connect to a server. The key is not to keep “forever keys” on disk, but to use temporary keys or short-lived tokens. For example, CI/CD can generate a key that lives for 5 minutes, is used for deployment, and is deleted immediately. Even if someone intercepts it, it’s useless.

In short: a bit of extra isolation, proper secret storage, and disciplined access controls—and your CI/CD on a VPS will be no less secure than the cloud giants’, just without their price tags and extra bureaucracy.

6. Integrating with European DevOps Tools

CI/CD on a VPS isn’t only about build and deploy—it’s also about the whole supporting “service tail”: artifacts, monitoring, and logs. Fortunately, there are lightweight, convenient tools that fit perfectly on your own VPS.

Artifact storage.
Instead of pushing everything into Amazon S3, you can use European alternatives. For example, Bunny.net Storage is a fast and inexpensive CDN + storage with data centers in Europe. Or you can run MinIO on a separate VPS and get full S3-compatible storage under your control. This is especially handy when you have multiple pipelines and need a single place where all binaries, images, and packages live.

Pipeline monitoring.
The classic combo here is Prometheus + Grafana. Prometheus collects metrics about builds and runners, and Grafana turns them into nice dashboards. You can see at a glance where the build queue is, which pipelines are slow, and where everything is flying. You can also configure alerts right in Grafana so you don’t have to dig through logs—just see the bottleneck immediately.

Logs and alerts.
To avoid relying on external log services, you can install Loki (logs in the spirit of “Prometheus for texts”) and Alertmanager. The result is a full loop: a pipeline fails—you get a notification in Slack or Mattermost, while all logs stay on your VPS without external integrations.

And one more important point: all these tools play nicely together. Prometheus collects metrics, Loki stores text logs, Alertmanager sends alerts, and Grafana draws clean dashboards. Together they give you a complete picture of what’s happening with your pipelines. In effect, you get your own little “DevOps Cloud”—only without the cloud and with full control.

7. Conclusion: Flexible and Sovereign DevOps

CI/CD on a VPS isn’t about saving a couple of euros on subscriptions. It’s about control and independence. You decide where your artifacts are stored, how secrets are handled, and what limits are acceptable. No “black boxes” from cloud giants, no sudden SLA changes, no new limits “starting tomorrow.” Everything is honest and transparent: the infrastructure is yours—and so are the rules.

But it’s important to understand: for this approach to really work, you need to take the right steps from the start. There are three things worth doing immediately:

1. Choose the right VPS. With NVMe disks, a solid network, and nested virtualization support. This is the foundation—without it, any pipeline will suffer.
2. Adopt a lightweight self-hosted CI. You don’t have to spin up Jenkins with a hundred plugins right away. To get started, Woodpecker or Gitea Actions is enough. The key is that your pipelines live next to your code and are controlled by you—not by an external API.
3. Secure your pipelines. Isolating build agents, managing secrets via Vault or Sealed Secrets, and using temporary SSH keys isn’t “overkill”—it’s the norm. Then your CI/CD will be not only fast, but also reliable.

As a result, you get a flexible, sovereign DevOps stack: it can be small for a startup or grow into a full-fledged system for a corporation. The main thing is that it’s entirely under your control. And that’s the value that’s driving companies today to move away from cloud monsters toward their own solutions.