GitHub hosts its own source code on github.com, which creates a hard circular dependency: if GitHub goes down, the deploy scripts meant to fix it can also fail. The problem extends beyond that single loop. GitHub's engineering team identified three distinct failure modes in their deployment pipeline: direct dependencies, where a script pulls a binary from GitHub during an outage; hidden dependencies, where a tool already on disk silently phones home to check for updates; and transient dependencies, where an internal service called via API itself reaches out to GitHub, propagating the failure back upstream. Teams had no automated way to catch these before an incident.
To solve this, GitHub built a proof-of-concept using eBPF, specifically the BPF_PROG_TYPE_CGROUP_SKB program type, implemented in Go using the cilium/ebpf library. The approach works by placing only the deployment script inside a Linux cGroup, then attaching an eBPF program to that cGroup to monitor and selectively block outbound network egress. This means production traffic on the same host is unaffected. No Docker required. The mechanism targets the process, not the machine.
The full post walks through the actual eBPF program construction, not just the architecture decision. If you want to understand how GitHub enforces network policy at the kernel level during deploys, or if you are building your own deployment safety tooling, the implementation details are worth reading in full.
[READ ORIGINAL →]