The worker host needs outbound HTTPS (port 443) only. No inbound ports, no UDP.

​
Required hosts

HostPurposeRequired
<api-host> — your region’s API hostJob claim, findings / events / spend / artifact uploadYes (always)
registry-1.docker.ioImage pull from Docker HubYes (first run + upgrades)
auth.docker.ioDocker Hub auth handshakeYes (first run + upgrades)
production.cloudflare.docker.comDocker Hub layer CDNYes (first run + upgrades)
Your scan targetThe actual pentest trafficYes (per target — varies)
<api-host> is the API host of the region your organization is in. Allow-list only that one — the worker never contacts another region, and a rule written for the wrong one fails closed. Set the worker’s region with TIGERGATE_REGION (Setup); leave it unset for us1, whose API host is api.tigergate.dev.

​
What you do not need

  • No outbound to api.openai.com, api.anthropic.com, etc. — LLM calls happen from TigerGate’s platform, not your worker host.
  • No inbound from the public internet. The worker is poll-based; it dials out and pulls jobs.
  • No UDP. All traffic is HTTPS.
  • No TigerGate-side IPs to allow-list. We use a fronting CDN; pin by hostname, not IP.

​
Verifying connectivity

From the worker host, before installing: 
# 1. Platform reachability — swap in your region's API host (us1 shown)
curl -fsS https://api.tigergate.dev/health
# Expected: {"status":"ok","timestamp":"..."}

# 2. Confirm it is the region you meant, before allow-listing it
curl -fsS https://api.tigergate.dev/api/meta/region
# Expected: {"code":"us1",...} — needs no credentials

# 3. Docker Hub reachability
docker pull tigergate/tigerstrike:1.0.0
# Expected: image pulls successfully
If either fails, fix the firewall / proxy first — the worker won’t recover from network unreachability with a re-install.

​
Behind a proxy

If your egress goes through an HTTP(S) proxy, configure Docker + the worker:

​
Docker daemon

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.internal:3128"
Environment="HTTPS_PROXY=http://proxy.internal:3128"
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

​
Worker

In docker-compose.client.yml add the proxy env to the tigerstrike service: 
services:
  tigerstrike:
    environment:
      HTTP_PROXY: http://proxy.internal:3128
      HTTPS_PROXY: http://proxy.internal:3128
      NO_PROXY: localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
Add target hosts to NO_PROXY if they’re internal — you don’t want the proxy in the loop for the actual pentest traffic.

​
Air-gapped / mirror registries

If Docker Hub is blocked outright, mirror the worker image to your internal registry: 
# On a network with Docker Hub access:
docker pull tigergate/tigerstrike:1.0.0
docker save tigergate/tigerstrike:1.0.0 -o tigerstrike-1.0.0.tar

# Move tigerstrike-1.0.0.tar to the air-gapped network, then:
docker load -i tigerstrike-1.0.0.tar
docker tag tigergate/tigerstrike:1.0.0 registry.internal.example.com/tigergate/tigerstrike:1.0.0
docker push registry.internal.example.com/tigergate/tigerstrike:1.0.0
Edit the image: line in docker-compose.client.yml to point at your mirror: 
image: registry.internal.example.com/tigergate/tigerstrike:1.0.0
The platform itself (your region’s API host) is not mirrorable — the worker has to reach it for job claim + findings upload. If your environment forbids any internet egress at all, we can’t run TigerStrike there. (We’re working on a fully on-prem control plane for some enterprise customers; talk to support.)

​
Egress IPs / hostname pinning

Every region’s API host resolves to a Cloudflare-fronted address pool. Pin by hostname; don’t try to allow-list IPs — they rotate. If your firewall doesn’t support hostname rules, contact [email protected] and we’ll provide the current Cloudflare ASN / IP-list snapshot. You’ll need to refresh it monthly.

​
Outbound to scan targets

The worker reaches scan targets directly, not via the platform. So:
  • Public targets — same as a regular browser; you typically don’t need extra firewall rules.
  • Internal targets — make sure the worker host has network access to your private subnet (e.g. it’s deployed inside the same VPC, or has a VPN tunnel to it).
  • Allow-listed targets — add the worker host’s IP to the target’s allow-list, not TigerGate’s. The worker is the one making requests.