---
title: "Reverse tunnel proxy"
canonical_url: "https://docs.getdx.com/reverse-tunnel-proxy/"
md_url: "https://docs.getdx.com/reverse-tunnel-proxy.md"
last_updated: "2026-07-21"
---

# Reverse tunnel proxy
The reverse tunnel proxy lets DX import data from your self-hosted source systems (GitHub Enterprise Server, Jira Data Center, etc.) **without opening any inbound ports**.

## When to use it

If your organization restricts inbound traffic by IP, the simplest option is to allowlist DX's IP addresses — see [Allowlisting DX](https://docs.getdx.com/allowlisting-dx/). Reach for the reverse tunnel proxy when your organization allows **no inbound traffic at all**, so IP allowlisting isn't an option.

## How it works

You run a lightweight proxy (`frpc`) inside your own network. It dials **outbound** to DX over WSS/TLS on port 443 and relays DX's API calls to your source systems on your internal network. Because the connection is always initiated from your side, no inbound firewall changes are needed.

The proxy is open source — you can review or build it from the [`reverse-tunnel-proxy` repository](https://github.com/get-dx/reverse-tunnel-proxy).

## Setup

1. Ask your DX account representative to enable the tunnel for your instance. Once enabled, an admin can copy the `FRP_AUTH_TOKEN` from the [Connections page](https://app.getdx.com/admin/datacloud/connections).
2. Run the proxy inside your network using either Docker or Kubernetes (below). Both need the same two environment variables:

   | Variable          | Description                                                   |
   | ----------------- | ------------------------------------------------------------- |
   | `FRP_SERVER_ADDR` | Your DX tunnel endpoint, e.g. `tunnel-yourinstance.getdx.net` |
   | `FRP_AUTH_TOKEN`  | Auth token provided by DX (keep secret)                       |

3. Once the proxy is running, you can configure any connection's settings to route its traffic through the tunnel.

> **⚠️ Warning**: The proxy must be running before the connection is switched to use the tunnel — otherwise imports for that connection will fail.

### Docker

```sh
docker run --rm \
  -e FRP_SERVER_ADDR=tunnel-yourinstance.getdx.net \
  -e FRP_AUTH_TOKEN=dx-provided-token \
  ghcr.io/get-dx/reverse-tunnel-proxy:latest
```

### Kubernetes

Store the token in a Secret, then deploy:

```sh
kubectl create secret generic dx-tunnel-secrets \
  --from-literal=FRP_AUTH_TOKEN=dx-provided-token
```

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dx-reverse-tunnel-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dx-reverse-tunnel-proxy
  template:
    metadata:
      labels:
        app: dx-reverse-tunnel-proxy
    spec:
      containers:
        - name: dx-reverse-tunnel-proxy
          image: ghcr.io/get-dx/reverse-tunnel-proxy:latest
          env:
            - name: FRP_SERVER_ADDR
              value: "tunnel-yourinstance.getdx.net"
            - name: FRP_AUTH_TOKEN
              valueFrom:
                secretKeyRef:
                  name: dx-tunnel-secrets
                  key: FRP_AUTH_TOKEN
      restartPolicy: Always
```
---

## Sitemap

[Overview of all docs pages](/llms.txt)