A CI runner spins up and dies in minutes, a container has no persistent disk and often no fixed IP, and an outbound channel has to be wired in fresh on every run — doing that by hand through a desktop app is not an option. Here is how to pass a proxy into a container and a pipeline correctly: no credentials in the image, allowing for a floating runner address, with traffic and isolation under control.
Passing proxy parameters via environment variables
The standard way to pass a proxy into a container and a pipeline step is the HTTP_PROXY, HTTPS_PROXY and NO_PROXY variables (and their lowercase counterparts some libraries read instead). The value is the same connection string: protocol, credentials, host, port. Most HTTP clients, package managers and CLI tools pick these up automatically, no code changes needed.
NO_PROXY separately lists addresses and domains to call directly: internal services on the container network, a local image registry, addresses between steps of one pipeline. Without it, internal traffic also routes through the external channel, adding cost and latency for nothing. Set variables at the step level, not the whole pipeline, when jobs need different addresses — a build step runs direct while an external-checks step goes through the right geo.
Why credentials cannot be baked into the image
An image is built in layers, and each layer lands in the registry and stays there even after a secret is removed in a later one — a command adding login and password to an env variable during the build leaves them readable through layer history, even if the next command deletes them. Secret-scanning tools find such credentials in seconds, in public and private registries alike — registry privacy is not security.
The correct pattern is injecting the secret at runtime, not build time: environment variables, an encrypted secret store, or a volume mounted at launch that never touches an image layer. The image stays identical across environments; only the value the CI system substitutes at job start changes.
An IP whitelist fails for runners with a floating address
Allowing access by the runner's IP only works for dedicated infrastructure with a fixed address. A cloud runner gets a container from a shared pool each run, and its external IP changes job to job, sometimes mid-step when the node is recreated — a whitelisted address goes stale by the next run, and access starts failing for no visible reason in the code.
The only durable scheme is login-password authentication tied to an account, not an address — the connection string carries credentials rather than relying on a static allowed-address list a runner can never guarantee. How rotation works here is covered in rotating IPs via API.
CI traffic cost and how to limit it
A pipeline hitting an external channel at every step accumulates traffic faster than it looks at first: a thousand checks of pages with images already runs 3-5 GB, and a daily monitoring pass over a hundred addresses adds roughly 1.5-3 GB a month for one scenario, before counting retries on a flaky step.
Three things cut that cost: caching dependencies and build artifacts so only genuinely external calls go out; disabling media where a scenario only needs text or an API response; and a datacenter address at a fixed monthly price for geo-insensitive tasks — not billed by traffic at all, so test runs never add to a gigabyte bill. The economics are covered in cheap versus expensive proxies.
Isolation between parallel jobs
A pipeline with parallel jobs — a typical CI setup — should not route every branch through the same assigned address: if one step gets blocked on reputation or hits a captcha, every parallel job sharing that IP gets caught up in it, including unrelated ones.
The fix is a separate session or credential segment per branch, keyed by job or step number. For channels with per-session address assignment, every job gets its own IP automatically, provided the session identifier is genuinely unique per run rather than hardcoded once for the whole pipeline.
Frequently Asked Questions
Can the same proxy account be used in several pipelines at once?
Technically yes, but on a channel with a shared concurrent-session limit that creates contention between unrelated pipelines: one crowds out the other's sessions at peak load. It is more practical to split several active pipelines across separate credential segments, even under one plan.
How do I pass a proxy into a container if the tool inside ignores environment variables?
Some tools ignore HTTP_PROXY and want the address in their own config file or flag — pass the connection string explicitly when invoking it, reading it from the same variable in the wrapping step script.
Should access be restricted to only the external domains a pipeline actually calls?
Yes, if the account supports that — it is less about saving traffic than ruling out accidental calls to internal addresses from a NO_PROXY mistake, which otherwise go unnoticed until someone digs through logs.
Proxies with login-password authentication for CI, ready to pass via environment variables with no dependency on the runner's address, are in the proxy section. Integration docs and limits are in the proxy API.