If you’ve ever tried to deploy from GitHub Actions into a locked-down environment, you’ve probably hit the the IP allowlist problem.

You know the one. Your CI job wants to SSH into a server, run a migration on a prod database, or hit a private Kubernetes API. But your infrastructure is locked down to specific IPs, and GitHub’s runners come from a massive, rotating, impossible-to-wrangle pool of addresses. You can’t realistically allow them all, and GitHub even advises against trying.

‍

So, people do all kinds of terrible things: self-hosted runners just to get a static IP, giant IP allow-lists, and temporary firewall rules that nobody remembers to remove. It’s all messy, brittle, and one mistake away from having your production database exposed to the public internet for three days.

There’s a better way, and it's easier than you might think!

‍

Identity > IP

Border0 gives your GitHub Actions workflow an identity, a real one with scoped access, and lets it connect to exactly what it needs. This means no access to the whole network, only the services you’ve explicitly authorized.

You create a service account that gets a token. The token lives in GitHub Secrets. Your workflow incorporates Border0 to authenticate and connect.

No SSH keys floating around. No shared DB passwords, No exposed ports. No IPs to whitelist. And no lingering “temporary” firewall rules. It's not just safer, it's also a lot easier.

‍

There are two main ways to connect to your resources: directly to a specific service using a Border0 socket, or by routing all traffic through your infrastructure using an exit node. You can use one or both in the same job. Let’s look at each.

‍

Use Case 1: Just Let Me Reach the Database, Please

Say your CI job needs to run a schema migration after a deploy.

In the old world, you'd figure out the runner's IP, add it to your database's allow list, run the job, and hope you remembered to clean it up later. (You probably wouldn't.)

‍

With Border0, you can make this database available as a Border0 resource (we call them sockets), which is basically a secure proxy that only accepts connections from your trusted service account over WireGuard. In your GitHub Action workflow, the Border0 client logs in using the token and connects to the database through that socket. The migration runs, securely and cleanly, over an encrypted WireGuard tunnel. It even works if your database runs in a private VPC or behind a NAT gateway, No need to make any network changes or open ports on the firewall!

The same process works for SSH, calling a private API, or accessing your internal Grafana instance. It’s all just a matter of making the resource available as a socket in Border0 and giving the right identity access to it.
‍

Kubernetes? Also covered.

You can expose your cluster's API via a Border0 socket. Then one CLI command updates your kubeconfig to point at that socket. Suddenly kubectl in your GitHub Action behaves like it's inside the cluster, even if the runner is on another continent. No firewall changes. No ports to open. No insecure kubeconfig files with cluster-admin tokens sitting in your repo. It works, it’s locked down, and it’s easy to audit.

Use Case 2: Make Your GitHub Action Look Like It’s Coming From Home

Now let’s flip it. What if your CI job needs to call a third-party API that only trusts requests from your corporate IP? Or scrape something from YoutTube or behind Cloudflare, but you keep getting blocked!
‍

GitHub runners aren’t great at this because they're often blocked by content providers and their public IPs change constantly. One day it’s 20.57.x, and the next day it’s 67.x.x.x. Your request gets blocked, fails silently, or just disappears.

‍

We can solve this by using a Border0 Exit Node.

You spin up a Border0 connector inside your own network (in AWS, GCP, your home lab, the office whatever) and make it available as an exit node. Then, in your GitHub Actions workflow, the Border0 client connects and uses that exit node.

Boom. From then on all outbound traffic from your runner is now tunnelled through a stable predictable IP that you control. Cloudflare is happy, your partners are happy, and your YouTube scraper works again!

Looking at the screenshot above, at first, the GitHub Actions runner shows up with a Microsoft IP from San Jose. After we route traffic through the Exit Node, the same runner now looks like it’s coming from AWS in Montreal. Same job, same workflow, totally different network presence.

‍

And yes, you can combine this with service-specific sockets we described earlier. You can run kubectl into your cluster and call a picky external API, all in the same job. It’s like teleporting your CI runner into your network for just long enough to get the job done.

‍

What It Looks Like in Code

Here’s a real workflow using both an exit node for stable egress and a Kubernetes socket for secure deploys.

Example: .github/workflows/demo-border0.yml

‍

This workflow installs the Border0 client, starts a VPN connection through the exit node so your traffic comes from your own IP, then configures kubectl to connect to your cluster via Border0. No firewall changes, no IP drama, and no special networking setup. Just solid, secure CI.
‍

Every session that runs through Border0 is logged. You can see exactly what kubectl commands your GitHub Action executed, whether it's a k8 API call, or even an exec into a container!

But it’s not just visibility, you also get control. With Border0 policies, you decide what your GitHub Action is allowed to do. Maybe it can only update deployments in a specific namespace. Maybe it is blocked from deleting anything. It’s up to you.

‍

And if something strange happens, like your CI suddenly tries to exec into pods or mess with cluster roles, Border0 Insights can alert you. So you’re not just getting convenience. You’re also getting visibility, control, and peace of mind.

‍

Welcome to a Borderless Pipeline

Using Border0 with GitHub Actions lets you ditch the network plumbing and focus on shipping code. You stop worrying about IP allow-lists, runner locations, or kubeconfig secrets. You start treating your CI jobs like real users with identities, scoped access, and audit logs.

Your team's conversations will change from "what’s the runner’s IP today?" to "cool, my GitHub bot just tunneled into the VPC and deployed to prod."

Simple. Secure. Borderless. Happy deploying.

‍