blog.info()

I previously wrote about how I optimized my build pipeline's runtime from 4 minutes to 2 minutes. I thought I had hit the ceiling of what was possible with standard tools.

I was wrong.

This week, I optimized that same pipeline from 2 minutes down to 30 seconds. Overall, that represents an 87.5% decrease from my original baseline. The secret wasn't a better algorithm or a smaller binary, it was abandoning the cloud for bare metal.

The Discrepancy

I was running my build locally the other day, and it finished in 4 seconds.

I stared at the terminal. Then I stared at my GitHub Actions log, which was currently churning away at the 1-minute-30-second mark.

I asked myself, "Why is the discrepancy so massive?" My original conclusion was that GitHub's free tier runners just have limited compute. While true (standard runners are 2-core VMs), that wasn't the full story. The CPU speed wasn't the bottleneck, the architecture of cloud CI was.

The Cost of "Clean Slate" Virtualization

Most modern build pipelines rely on ephemeral Docker containers. This is great for reproducibility. You get a clean OS every time, but it comes with a massive performance tax that we've accepted as normal.

Here is where the time actually goes:

The Docker Tax: Before a single line of code is compiled, the pipeline has to pull the Docker image. Even with layer caching, initializing the container and the network bridge takes 20-30 seconds.
The "Cold Boot" Penalty: Because every run is a fresh VM, you have zero cache by default. You have to re-download Go modules, re-compile the standard library, and re-process every asset from scratch.
Virtualization I/O: On macOS specifically (where I develop), running Docker adds a significant I/O overhead because file system calls have to bridge between the host (macOS) and the VM (Linux).

Enter the Self-Hosted Runner

I decided to set up a self-hosted runner on my own hardware. This changed the paradigm from "Ephemeral" to "Persistent."

By running the build directly on the host OS ("on metal") without Docker, the performance gains were immediate:

Incremental Builds: The Go build cache (GOCACHE) persists between runs. The compiler sees that 99% of the source code hasn't changed and skips compiling it.
Native Cross-Compilation: instead of using Docker to emulate a Linux environment (which can be slow on ARM chips), I use Go's native cross-compilation (GOOS=linux GOARCH=amd64) directly on the Mac. It is blazing fast.
Zero Setup Time: Git doesn't need to clone the whole repo, it just fetches the diff. Tools like ffmpeg and chromedp are already installed. The pipeline starts executing logic in milliseconds, not minutes.

The Trade-off

Self-hosting isn't a silver bullet. It trades isolation for speed.

Because the workspace persists, you risk "state drift," where a file you deleted locally still exists on the runner, potentially causing false positives in tests. I mitigated this by adding a "Self-Healing" step to my pipeline: if a build fails, the runner automatically runs git clean -fdx to wipe the directory, ensuring the next run is clean.

Conclusion

For a personal engineering blog or a solo project, waiting minutes for a deploy is a momentum killer. By moving to a self-hosted runner, I've turned deployment into an almost instantaneous feedback loop.

If you have spare compute and a need for speed, it might be time to bring your runner home.