Grab a spot →
Skip to main content

Route egress through proxy

Connect docs via MCP

Many organizations require all outbound traffic to leave through a single, auditable egress point. Self-Deployed Runtime supports this out of the box: it honors standard proxy environment variables, so you can route every connection it makes to Atlan through a forward or egress proxy for logging, inspection, and compliance.

This complements network allowlisting. Use a firewall to restrict where traffic can go, and a proxy to inspect and audit it. The guided install wizard also surfaces the HTTP proxy and custom-CA options during setup.

What outbound traffic to expect​

The SDR makes outbound connections to these Atlan endpoints—allowlist them and keep them out of NO_PROXY:

DestinationPortProtocolTraffic
<your-tenant>.atlan.com443HTTPSAuthentication, workflow events, and metadata/file uploads
<your-tenant>-temporal.atlan.com443gRPC/TLSWorkflow-engine connection

Choose your path​

Your proxy configuration follows from one question: does your policy require connection-level auditing only, or payload inspection too?

RequirementApproachWhat it implicates
Audit only: prove all egress leaves through one logged point (which host, when, how much)Pass-through proxy (no decryption)Nothing is decrypted, nothing breaks, there is no CA to manage, and no Atlan credentials are exposed in proxy logs. Satisfies most "single auditable egress" mandates.
Audit and payload inspection: also inspect request contents (for example, DLP or deep compliance)TLS inspection (decryption)Requires trusting the proxy's CA, forwarding uploads byte-for-byte so their SigV4 signatures don't break, and HTTP/2 tuning for the workflow engine. Decryption also places Atlan auth tokens and upload signatures in cleartext in proxy logs—redact and access-control them.

Both approaches give a complete connection-level audit trail. Select the narrowest that meets your requirement and follow only that path.

The proxy tunnels the SDR's encrypted traffic and logs each connection—destination, timestamp, and data volume—without decrypting anything.

Before you begin​

Make sure you have:

  • A proxy reachable from the SDR host that supports HTTP CONNECT (required to tunnel HTTPS and gRPC).
  • Administrative access to set environment variables on the SDR.

Step 1: Point SDR at your proxy​

Set the standard proxy environment variables so the SDR sends its traffic through the proxy:

HTTP_PROXY=http://YOUR_PROXY_HOST:PORT
HTTPS_PROXY=http://YOUR_PROXY_HOST:PORT

If your proxy requires authentication, provide the credentials in the URL (HTTP Basic):

HTTPS_PROXY=http://YOUR_PROXY_USER:YOUR_PROXY_PASSWORD@YOUR_PROXY_HOST:PORT

Prefer an unauthenticated proxy on a trusted network segment—then there is no proxy credential to manage. If you must authenticate, percent-encode any reserved characters in the password (@ → %40, : → %3A), and be aware that credentials in HTTPS_PROXY are readable by anyone who can inspect the SDR's environment (for example, docker inspect or process listings). Where your platform supports it, populate the value from a Kubernetes Secret or Docker secret instead of hardcoding it. SDR's secret vault stores source-system credentials, not proxy settings, so it doesn't apply here.

Keep local or internal traffic off the proxy with NO_PROXY. For example, a self-hosted object store or secret store running alongside the SDR:

NO_PROXY=localhost,127.0.0.1,your-internal-object-store-host

Set these wherever your deployment defines the SDR's environment:

Add them to the environment: block of the SDR service in your docker-compose.yml:

docker-compose.yml
services:
  runtime:
    environment:
      HTTP_PROXY: http://YOUR_PROXY_HOST:PORT
      HTTPS_PROXY: http://YOUR_PROXY_HOST:PORT
      NO_PROXY: localhost,127.0.0.1,your-internal-object-store-host

All traffic types (authentication, workflow events, the workflow engine, and uploads) honor these settings.

Step 2: Allow long-lived workflow connections​

Pass-through decrypts nothing, so there is no CA to trust and no request rewriting to worry about. The one thing to check: the workflow-engine connection to <your-tenant>-temporal.atlan.com is a long-lived gRPC stream, so set generous idle and connection timeouts on the proxy or it may drop the tunnel during quiet periods.

Then restart the SDR so it picks up the new environment.

Step 3: Verify egress flows through proxy​

Confirm each traffic type reaches Atlan through the proxy. In your proxy's access log or dashboard you can see:

RequestExpected
POST <your-tenant>.atlan.com/auth/realms/.../token200
POST <your-tenant>.atlan.com/api/eventingress/200
gRPC to <your-tenant>-temporal.atlan.com200
PUT <your-tenant>.atlan.com/api/blobstorage/... (during a workflow)200

If all of these appear with 200 responses, egress is correctly routed through your proxy. Because nothing is decrypted, the payloads stay opaque—you get destination, timestamp, and data volume for a complete connection-level audit trail.

Troubleshooting​

SymptomCause and fix
Workflow-engine connection drops or times outRaise the proxy's idle and connection timeouts—the gRPC stream to <your-tenant>-temporal.atlan.com is long-lived.
Some egress doesn't appear at the proxyConfirm the variables are set in the SDR's container environment (not just your shell), and set both the upper- and lowercase forms (HTTP_PROXY and http_proxy).
Local object-store or secret traffic failsAdd those hosts to NO_PROXY; they shouldn't go through the proxy.

See also​

Need help​

If you are still facing issues and need help, contact security@atlan.com for assistance.