Leveraging eBPF for Safer Deployments at GitHub

GitHub faces a unique challenge: because it hosts its own source code, any outage on github.com can create a circular dependency that prevents engineers from deploying fixes. To address this, GitHub has adopted eBPF (extended Berkeley Packet Filter) in its host-based deployment system to monitor and block deployment scripts from making network calls that could reintroduce these dangerous loops. Below, we explore the problem and how eBPF provides a robust solution.

What is the circular dependency problem GitHub faces?

GitHub runs its own infrastructure on github.com, meaning all source code, release artifacts, and deployment tools are hosted there. If github.com goes down—say due to a MySQL outage—engineers cannot access the very code needed to fix it. This is a classic circular dependency: to deploy a fix, you need GitHub, but GitHub is broken. While GitHub maintains a mirror of its code and prebuilt assets for rollbacks, this only addresses the most basic loop. The real challenge is preventing deployment scripts from inadvertently creating new circular dependencies during an incident.

What are the three types of circular dependencies in deployments?

During a hypothetical MySQL outage, three dependency types can appear. Direct dependencies: A deploy script tries to pull a tool from GitHub, but GitHub is unavailable, so the script fails. Hidden dependencies: A tool already on disk checks for updates from GitHub; if GitHub is down, the tool may hang or error. Transient dependencies: The script calls an internal API (e.g., a migration service), which in turn fetches a binary from GitHub, causing the failure to cascade back. All three can block or delay incident resolution.

How did GitHub previously handle these circular dependencies?

Before adopting eBPF, GitHub relied on manual review. Each team owning stateful hosts had to audit their deployment scripts and identify any potential circular dependencies—a time‑consuming and error‑prone process. Dependencies were often missed because they were hidden inside tools or introduced by third‑party libraries. Moreover, as scripts evolved, new dependencies could appear without notice. GitHub needed an automated, runtime approach to catch and block problematic calls without requiring constant human oversight.

What is eBPF and how does GitHub use it for deployment safety?

eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that allows running sandboxed programs in response to events like system calls or network packets. GitHub uses eBPF to selectively monitor and block outbound network calls made by deployment scripts. By attaching eBPF programs to the connect or sendto syscalls, GitHub can inspect the destination IP and port, and if the call would create a circular dependency (e.g., connecting to github.com or an internal service that depends on GitHub), the program can deny the call and log it. This provides a real‑time safety net without modifying the scripts themselves.

How does eBPF prevent direct and hidden dependencies?

For direct dependencies, the eBPF program immediately blocks any attempt by the deploy script to reach github.com or other prohibited hosts, preventing the script from hanging or failing on an unavailable resource. Hidden dependencies are trickier—a tool already on disk might check for updates during runtime. Here, eBPF intercepts the tool's network calls as well, even though the script didn't explicitly invoke them. By attaching to all processes spawned by the script (and their children), eBPF can block any unforeseen network activity, ensuring that even buried update checks don't introduce a circular dependency.

What are the benefits of using eBPF over manual review?

eBPF automates the enforcement of deployment safety, eliminating human error and reducing the burden on each team. It works at the kernel level, so it cannot be bypassed by scripts that circumvent application‑level checks. The policy is centralized and can be updated without modifying hundreds of deployment scripts. Additionally, eBPF provides detailed logging of every blocked call, making it easy to audit and fix problematic dependencies. This approach shifts safety from a pre‑deployment checklist to an active runtime guard, giving incident responders confidence that their deploy scripts won't accidentally recreate the very outage they are trying to fix.