I built Buildcage to solve a recurring problem at work: during Docker builds, tools like `npm install` and `pip install` can execute arbitrary code and make outbound connections to arbitrary hosts without visibility or control. A compromised dependency could silently exfiltrate build secrets or phone home to an attacker’s server — and you’d have no way to detect it.

Buildcage adds transparent outbound network control to Docker builds: you define which domains are allowed, and everything else is blocked and logged. No proxy injection, no certificate changes — HTTPS filtering is done via SNI inspection, so TLS stays untouched. It’s a drop-in layer for Docker Buildx and GitHub Actions.

I shared an earlier version about three weeks ago. Since then, I replaced the proxy layer (nginx → HAProxy), enabling interception of all TCP ports and adding IP allowlisting. I also redesigned the rule syntax to support wildcards, regex, and a unified host:port format.

Since Buildcage sits in your build pipeline, it’s reasonable to ask: how do you trust the tool itself? You can fork the repo and build the image yourself — I added a self-hosting guide for this. The docs also explicitly list what it defends against and what it can't prevent. Security tools should be honest about their limitations.

This is not a silver bullet — it's a last line of defense. If something slips through your other measures, at least it can't call home.

GitHub: https://github.com/dash14/buildcage

Feedback is very welcome. And if you find it useful, a GitHub star genuinely helps.