DevOps on a Budget: Setting Up a CI/CD Pipeline on SurferCloud UHost

For any modern engineering team, the CI/CD pipeline is the heartbeat of production. However, as teams adopt microservices, the number of builds, tests, and deployments explodes. If you are using AWS CodeBuild or GitHub Actions, you have likely seen your monthly bill creep up as you are charged for every "build minute."

When we migrated 50% of our production services to SurferCloud, we realized our DevOps pipeline also needed a home that wouldn't penalize us for being productive. By building a self-hosted CI/CD environment on SurferCloud UHost, we achieved faster build times and eliminated the "per-minute" anxiety. Here is how we did it.

Get Started: SurferCloud: Cloud Computing Services

Why Self-Host on SurferCloud?

The "Serverless" build model (like CodeBuild) has a major flaw: Cold Starts. Every time a build triggers, a new environment must be provisioned, dependencies downloaded, and Docker layers pulled. This can add 2–3 minutes to every build.

By using a dedicated UHost instance on SurferCloud, we keep a "warm" environment. Our Docker layers are cached locally, and our node_modules stay on the disk. A build that took 6 minutes on AWS now takes 90 seconds on SurferCloud.

The Architecture: GitLab + SurferCloud UHost

We chose GitLab as our orchestrator, but the same logic applies to Jenkins or GitHub Actions Runners.

1. Provisioning the Runner

We selected a SurferCloud UHost instance in the Hong Kong region (to ensure low latency for our Asia-based dev team). We opted for a high-CPU configuration (8 vCPUs) because compiling code is a CPU-intensive task.

2. Security and Isolation

Security is often the reason people stick with AWS. However, SurferCloud’s VPC and Security Groups provide the same level of isolation. We placed our CI/CD runner in a private subnet and only allowed outgoing traffic to our Git repository and incoming traffic for SSH via a VPN.

3. Scaling with Docker-in-Docker (DinD)

To handle multiple developers pushing code simultaneously, we configured the GitLab Runner to use the Docker Executor. This allows each build to run in its own isolated container on the SurferCloud host. Because SurferCloud uses high-speed NVMe storage, the I/O-heavy process of spinning up and tearing down containers is nearly instantaneous.

The Math: Per-Minute vs. Per-Month

Let’s look at the cost-benefit analysis for a team of 20 developers:

• The AWS CodeBuild Way: 20,000 build minutes per month at $0.01 per minute = $200/month.
• The SurferCloud Way: One 8 vCPU UHost instance = ~$65/month.

The savings are clear, but the real value is unlimited builds. On SurferCloud, our developers don't hesitate to push code to run tests. They don't worry about "wasting company money" on a build. This culture of "test early, test often" has significantly improved our code quality.

Optimizing for Global Deployments

Because SurferCloud has 17 data centers, we can deploy runners globally. We use a runner in Los Angeles for our US-based deployments and a runner in Frankfurt for our European staging environments. This reduces the time it takes to push large Docker images to regional registries, further speeding up our deployment cycle.

Conclusion: Empowering the Engineer

DevOps shouldn't be a luxury. By moving our CI/CD infrastructure to SurferCloud, we transformed our pipeline from a "metered expense" into a "fixed asset." We saved money, yes—but we also gained a faster, more responsive development environment that scales with our ambitions, not our budget.