Circle CI VPN
You set up a circle ci vpn by starting a tunnel inside your build job. You can also run a self-hosted runner inside your private network. Most teams store a shared key in their build settings to open this tunnel. When that role is too broad, any build script can reach every internal server. How a circle ci vpn works in build jobs Cloud build runners start on public machines outside your private network. They cannot reach your internal databases or private servers by default. To fix this, team
VPN Access Control + GitLab CI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a circle ci vpn by starting a tunnel inside your build job. You can also run a self-hosted runner inside your private network. Most teams store a shared key in their build settings to open this tunnel. When that role is too broad, any build script can reach every internal server.
How a circle ci vpn works in build jobs
Cloud build runners start on public machines outside your private network. They cannot reach your internal databases or private servers by default. To fix this, teams install a VPN client during the build run. The job reads a stored secret key and logs in to the network.
Once the tunnel opens, the build runner gets a private IP address. The runner can now send traffic to internal hosts as if it lived there. When the job ends, the runner shuts down and closes the tunnel.
Some teams skip the per-job tunnel and use self-hosted runners instead. You install the runner agent on a server inside your private network. That machine polls the build service for queued jobs and runs them inside your walls. Both paths put the build worker directly on your internal network.
Network rules and IP allowlists
Before teams adopt a VPN, they often try IP allowlists on their firewalls. Cloud build machines share large pools of public IP addresses that change often. Allowing those public ranges opens your firewall to many outside machines at once. A VPN or private runner avoids wide public IP rules on your perimeter firewall.
Inside the private network, teams use subnet rules to limit what the runner reaches. You might place the VPN client in a small subnet with strict routing rules. That subnet can only talk to specific ports on your test database or staging app. Still, managing firewall rules for dozens of build projects takes constant work.
VPN Access Control + GitLab CI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network tunnels solve and what keeps the session active
A VPN solves the basic transport problem between a cloud runner and private hosts. It encrypts traffic across the internet and keeps your servers off public IP addresses. Outside attackers cannot scan your internal ports from the open web.
Yet a network tunnel only checks who can enter the subnet. Once the runner connects, the network trusts all traffic coming from that tunnel. The VPN does not inspect the database queries or shell commands inside the traffic. If a build job holds a broad database password, it can run destructive queries.
Network logs also lack detail about what happened during a build run. Your firewall log shows that the runner IP talked to a database port. It does not record which user triggered the build or which SQL statements ran. Also, raw data like emails, phone numbers, or card numbers flows back to build logs. Without command-level checks and field masking, a private tunnel still leaves wide runtime gaps.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Should I use a per-job tunnel or a self-hosted runner?
A per-job tunnel works well for small teams that want zero servers to maintain. It adds startup time to every build because the client installs and connects each run. A self-hosted runner starts jobs faster, but your team must patch and run the host machine.
How do I keep VPN keys safe in build settings?
Store your tunnel keys in restricted project contexts rather than shared team settings. Only let specific branches or trusted team groups read those contexts during a run. Rotate the client keys on a set schedule and revoke old keys right away.
Why can a build job still drop tables over a VPN?
A VPN only controls network routing between the runner and the database host. It does not read or block the SQL statements sent inside that network path. If the database role allows table drops, the tunnel will pass that command through.