Strengthening Deployment Safety with eBPF: GitHub's Approach

The Challenge of Circular Dependencies

At GitHub, we run our own source code on github.com, testing new features internally before releasing them to users. However, this creates a unique risk: if github.com goes down, we lose access to our own code—a classic circular dependency. To mitigate this, we maintain a mirror of our repositories for emergency fixes and store pre-built assets for rollbacks.

But we soon realized that the deployment process itself introduces new circular dependencies. For instance, a deployment script might inadvertently download a dependency from GitHub or call an internal service that relies on GitHub—creating a loop that can bring down the entire system when issues arise.

Types of Circular Dependencies

Consider a MySQL outage scenario: GitHub cannot serve release data, and we need to push a configuration change to affected nodes via a deployment script. This reveals three dependency types:

• Direct dependencies: The script tries to pull an open source tool from GitHub, which is unavailable, so the deployment fails.
• Hidden dependencies: A tool already on the disk checks for updates on GitHub and hangs or fails if it can’t reach the site.
• Transient dependencies: The script calls an internal API (e.g., a migration service) that itself fetches a binary from GitHub, propagating the failure back.

How eBPF Solves the Problem

Instead of relying solely on teams to audit their scripts (which often misses subtle dependencies), we turned to eBPF—a kernel technology that lets us safely run sandboxed programs inside Linux. With eBPF, we can intercept system calls (like network requests) during deployments and selectively block calls that would create circular dependencies.

Our new host-based deployment system attaches eBPF programs to key syscalls, checking each outgoing request against a whitelist of allowed destinations. For example, we block attempts to reach api.github.com or internal services during the deploy, preventing the script from accidentally triggering a loop.

Implementation Details

We wrote small eBPF programs that hook into connect() and sendto() syscalls. When a deployment starts, the agent loads these programs, which inspect the destination IP and port. If the request matches a forbidden pattern (e.g., an internal service that depends on GitHub), the program returns a permission denied error, halting the script cleanly. The deployment logs the event for review, allowing engineers to fix the script.

This approach not only catches obvious dependencies but also hidden ones—like tools that check for updates in the background. It’s a robust, low-overhead solution that scales across thousands of hosts.

Conclusion

eBPF gives us fine-grained control over deployment behavior without modifying the scripts themselves. By proactively blocking circular dependencies, we make our infrastructure more resilient—even during major incidents. If you’re facing similar challenges, eBPF is a powerful tool worth exploring.