Your CI pipeline just failed again, and not because of bad code. The runner can’t reach the internal service you swore was “definitely open.” You sigh, check the firewall, and realize you need yet another tunnel. That is the daily grind GitLab TCP Proxies were made to end.
GitLab uses TCP proxies to bridge secure, temporary network access between runners, services, and private environments. Instead of exposing networks or hardcoding credentials, it routes job traffic through authenticated connections managed by GitLab’s infrastructure. This approach keeps pipelines fast and secure while avoiding brittle VPN setups or one-off SSH hacks.
Understanding how these proxies fit into the bigger picture helps a lot. Think of each proxy as a short-lived gatekeeper. It runs within your GitLab workflow, verifies identity, and forwards traffic only for the specific job that requested it. When the job finishes, the gate vanishes. You get connectivity without lingering attack surfaces.
Here is the workflow in plain English. A job kicks off in the runner. GitLab’s control plane issues a connection token that authorizes the runner to talk to its private target. The TCP proxy sits in between, validating the token and relaying packets cleanly. No persistent tunnel, no static IP list, just dynamic access that maps perfectly to your least-privilege policy.
To keep things reliable, tie the proxy logic to your identity source, whether that is AWS IAM, Okta, or another OIDC provider. Establish clear RBAC mappings so only the right pipelines can reach protected services. Rotate tokens frequently, and log every session for forensic clarity. Troubleshooting then becomes as simple as reviewing job metadata instead of guessing what went through port 5432 at 2 a.m.