How We Slashed Our CI Pipeline Costs with Developer MacBook Pros

The Problem: Rising Cloud Costs and Developer Wait Times #

As our platform, SmoothGlue® Cloud, grew in adoption, we hit a familiar problem: cloud costs. The culprit? Our Continuous Integration (CI) pipelines. Running CI pipelines for multiple developer (dev) branches is essential in ensuring code quality and security, but the more devs we had, the more we saw our cloud costs skyrocket.

It didn’t stop there, though. As we tried to manage costs by limiting the number of runners, we ran into a new issue: devs were stuck waiting in line for pipelines to run. Frustrated devs waiting for an available runner was obviously not ideal.

Using Auto-Scaling to Manage Cost and Availability #

Our first step in tackling these challenges was to introduce auto-scaling groups. As demand surged during work hours, our CI runners scaled up; then, as evening rolled in and our team clocked out for family time, we scaled the runners back down. It was a solid improvement—we reduced cloud costs while keeping pipelines moving during peak hours.

But in true Change the Box fashion, we knew this wasn’t the final solution. There was still room to drive down costs and improve developer productivity. The key was sitting on our desks, right in front of us.

The Solution: Turning MacBooks into GitLab Runners #

Each of our devs is assigned a powerful MacBook Pro. In the modern software world, most devs aren’t running heavyweight local compile jobs or VMs. They’re coding in their editors and relying on cloud services for the heavy lifting. That left us with tons of idle compute power sitting on our desks while we were paying for extra cloud runners.

So why not use the machines we already have?

We set out to turn each dev’s MacBook Pro into a dedicated GitLab Runner. This would allow devs to leverage the hardware they already had for running their CI pipelines. No more waiting in line for cloud runners. No more skyrocketing cloud costs.

Here’s how we did it and how you can do it, too:

1. Install the GitLab Runner We ran this command on each dev’s machine to configure it as a runner:

curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
chmod +x /usr/local/bin/gitlab-runner

This downloaded and installed the GitLab Runner executable.

2. Register the Runner After installation, we registered each MacBook as a runner in GitLab, assigning it to the dev’s projects so their pipelines would run locally when triggered.

gitlab-runner register

Note: You’ll be prompted to provide your GitLab instance URL, a registration token, and other setup details.

3. Configure the Runner We then assigned the runner to specific projects or branches. For example, we configured it to only handle CI pipelines for the dev’s own branches.
4. Automate the Setup We wrote a simple setup script to automate these steps and roll it out across our team. This ensured every dev’s machine was ready to act as a runner.
5. Prioritize Local Compute We configured GitLab CI to prioritize local runners over cloud-based runners, ensuring that if the dev’s machine was available, it would always be used first.
6. Include Fallback Logic We then set up a fallback, so if a dev’s machine wasn’t available or was offline (e.g., they were out of office), the system would automatically fall back to cloud-based runners, ensuring no pipeline went unprocessed. Note: You can adjust the priority settings for your team using GitLab's CI/CD pipeline configurations.

Now each of our devs had a dedicated pipeline resource at their fingertips.

Immediate Results #

Our pipeline wait times dropped dramatically overnight. Devs no longer had to sit around waiting for a free runner, and our cloud costs dropped as we scaled back our reliance on cloud-based CI runners.

This solution embodies our Change the Box philosophy—finding incremental improvements that drive meaningful change. We didn’t need to overhaul our entire CI pipeline infrastructure. Instead, we looked at the resources we already had and found a way to make them work harder, faster, and cheaper for us.

By turning idle MacBooks into CI pipeline runners, we reduced costs, improved developer experience, and streamlined our workflow, all without adding expensive new infrastructure.

Don’t Let Idle Resources Go to Waste #

If your cloud costs are spiraling out of control and your devs are stuck waiting for pipelines, take a hard look at the resources you already have. You might just find the solution sitting right in front of you.

By leveraging idle developer machines, you can slash your cloud costs, keep your pipelines running smoothly, and give your devs the dedicated resources they need to move fast and ship code.