TigerGate Docs — code-to-cloud security platform

The self-hosted worker is a Docker container you run on a Linux VM inside your network. It claims pentest jobs from the TigerGate platform, spawns sandbox containers per scan, and reports findings back — all over outbound HTTPS. No inbound ports required.

When to use it

Situation	Hosted	Self-hosted
Public target on the open internet	Yes	Yes
Target behind a VPN	No	Yes
Target on a private subnet (10.x / 172.x / 192.168.x)	No	Yes
IP allow-list TigerGate isn’t on	No	Yes
Private codebase you can’t push to a public Git host	No	Yes
Corporate policy forbids SaaS probing your infrastructure	No	Yes

The two paths share everything above the worker — same dashboard, same findings inbox, same budgets, same LLM-provider config. The only difference is where the agent’s sandbox runs.

What the worker does

The platform queues a scan when you click Start scan in the dashboard.
Your worker long-polls the platform for jobs.
When a job lands, the worker spawns 2–4 short-lived sandbox containers — each has a headless browser + terminal + HTTP proxy.
The agents probe the target. Findings stream back to the platform.
Scan ends on time-cap or budget-cap; the worker tears down its sandboxes.

What stays on your host

Stays on the worker host	Sent to TigerGate
The sandbox containers themselves (per-scan)	Findings (severity, payload, narrative)
Scan artifacts (HTTP traces, screenshots) — under `tigerstrike_runs` volume, retention-swept	Spend telemetry + scan timing metadata
The target’s responses (request/response bodies, screenshots) — until the platform retention sweeper prunes them	None of the LLM API key — that lives on TigerGate’s side; we inject it into each scan job at runtime.

The LLM provider key never touches your worker host. The agents make LLM calls through the platform, not directly. This means you don’t have to allow-list api.openai.com on the worker host’s firewall.

What you need

A Linux VM with 8 vCPU / 16 GB RAM / 40 GB disk — see Requirements.
Docker 24+ + Docker Compose v2.
Outbound HTTPS to your region’s API host (api.tigergate.dev on us1) and Docker Hub. See Outbound endpoints.
A pentest-worker API key from the dashboard. See Setup.

Run it

First, in the dashboard: configure your LLM provider (Pentest → Settings → AI Providers) and create a pentest-worker API key (Organization → API Keys). Then run the worker with Docker or Kubernetes. The image is prebuilt — tigergate/tigerstrike (Docker Hub); no build step.

Docker Compose
Kubernetes

docker-compose.client.yml:

name: tigerstrike
services:
  tigerstrike:
    image: tigergate/tigerstrike:1.0.0      # pin in production
    entrypoint: ["/usr/local/bin/tigerstrike-service"]
    command: ["--port", "8085", "--workers", "2"]
    network_mode: host                      # required — worker reaches its sandboxes on the host bridge
    restart: unless-stopped
    stop_grace_period: 30s                  # let in-flight scans drain on SIGTERM
    environment:
      TIGERGATE_API_KEY: "tg_<pentest-worker-key>"
      TIGERSTRIKE_WORKER_NAME: "acme-prod-dc1"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock          # sandbox runs on the host daemon
      - tigerstrike_runs:/var/lib/tigerstrike/runs         # scan artifacts
      - /var/lib/tigerstrike/codebase:/var/lib/tigerstrike/codebase:ro   # optional: private codebases
    mem_limit: 4g
    cpus: 2
volumes:
  tigerstrike_runs:

Run it:

docker compose -f docker-compose.client.yml up -d
docker compose -f docker-compose.client.yml logs -f tigerstrike   # expect: worker registered as "…"

Full walkthrough: Setup.

Managed clusters run containerd, not Docker, so the pod carries a privileged docker:dind sidecar that hosts the per-scan sandboxes (both containers mount the volumes at identical paths). Create the namespace + secret, then apply:

kubectl create namespace tigerstrike
kubectl -n tigerstrike create secret generic tigerstrike-api \
  --from-literal=TIGERGATE_API_KEY=tg_<pentest-worker-key>
kubectl apply -f tigerstrike.yaml
kubectl -n tigerstrike rollout status deploy/tigerstrike

tigerstrike.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: tigerstrike-runs, namespace: tigerstrike }
spec: { accessModes: ["ReadWriteOnce"], resources: { requests: { storage: 20Gi } } }
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: tigerstrike-dind-cache, namespace: tigerstrike }
spec: { accessModes: ["ReadWriteOnce"], resources: { requests: { storage: 20Gi } } }
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: tigerstrike, namespace: tigerstrike, labels: { app: tigerstrike } }
spec:
  replicas: 1
  strategy: { type: Recreate }
  selector: { matchLabels: { app: tigerstrike } }
  template:
    metadata: { labels: { app: tigerstrike } }
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: tigerstrike
          image: tigergate/tigerstrike:1.0.0
          command: ["/usr/local/bin/tigerstrike-service"]
          args: ["--port", "8085", "--workers", "2"]
          env:
            - { name: DOCKER_HOST, value: "tcp://127.0.0.1:2375" }   # talk to the DinD sidecar
            - { name: TIGERSTRIKE_WORKER_NAME, value: "acme-eks" }
            - { name: TIGERSTRIKE_BOOT_TIMEOUT, value: "15m" }       # first sandbox pull is ~600 MB
            - name: TIGERGATE_API_KEY
              valueFrom: { secretKeyRef: { name: tigerstrike-api, key: TIGERGATE_API_KEY } }
          ports: [{ containerPort: 8085, name: health }]
          startupProbe: { httpGet: { path: /health, port: 8085 }, periodSeconds: 5, failureThreshold: 24 }
          livenessProbe: { httpGet: { path: /health, port: 8085 }, periodSeconds: 30, failureThreshold: 6 }
          resources: { requests: { cpu: "1", memory: "2Gi" }, limits: { cpu: "2", memory: "4Gi" } }
          volumeMounts:
            - { name: runs, mountPath: /var/lib/tigerstrike/runs }
        - name: dind
          image: docker:24-dind
          securityContext: { privileged: true }
          env: [{ name: DOCKER_TLS_CERTDIR, value: "" }]
          args: ["--host=unix:///var/run/docker.sock"]
          startupProbe: { tcpSocket: { port: 2375 }, periodSeconds: 5, failureThreshold: 24 }
          resources: { requests: { cpu: "1", memory: "2Gi" }, limits: { cpu: "4", memory: "8Gi" } }
          volumeMounts:
            - { name: dind-storage, mountPath: /var/lib/docker }
            - { name: runs, mountPath: /var/lib/tigerstrike/runs }   # same path in both containers
      volumes:
        - { name: runs, persistentVolumeClaim: { claimName: tigerstrike-runs } }
        - { name: dind-storage, persistentVolumeClaim: { claimName: tigerstrike-dind-cache } }

DinD needs a privileged pod. If your cluster enforces Pod Security, label the namespace: kubectl label ns tigerstrike pod-security.kubernetes.io/enforce=privileged. On nodes that already run Docker you can drop the sidecar and mount hostPath: /var/run/docker.sock instead.

The worker self-registers within ~10s — confirm it in Pentest → Scanners, then pick it as the runner on a new scan. No inbound ports are needed either way.

Configuration options

Set these as environment variables (Compose environment: / Kubernetes env:). Only TIGERGATE_API_KEY is required.

Variable	Default	Purpose
`TIGERGATE_API_KEY`	— (required)	`pentest-worker` token from the dashboard.
`TIGERSTRIKE_WORKER_NAME`	`tigerstrike-onprem`	Name in the fleet view — give each host a unique one.
`TIGERGATE_REGION`	`us1`	Region that owns your organization. Must match the region the API key was issued in.
`TIGERGATE_BACKEND_URL`	from `TIGERGATE_REGION`	Explicit platform URL. Overrides the region — set it only for a self-hosted or staging platform.
`TIGERSTRIKE_OUTPUT_ROOT`	`/var/lib/tigerstrike/runs`	Where scan artifacts are written.
`TIGERSTRIKE_BOOT_TIMEOUT`	`5m`	Grace for a scan’s first sandbox to boot. Raise to `15m` on slow-egress hosts (first sandbox pull ~600 MB).
`TIGERSTRIKE_STALL_TIMEOUT`	`10m`	Cancel a scan after this long with no progress.
`TIGERSTRIKE_MAX_SCAN_TIMEOUT`	`12h`	Hard ceiling on any single scan’s wall-clock.
`TIGERSTRIKE_SANDBOX_IMAGE`	`tigergate/tigerstrike-sandbox-block:0.0.1`	Per-scan sandbox image — point at your mirror for a private registry.
`TIGERSTRIKE_SANDBOX_PULL_TIMEOUT`	`20m`	Grace for the sandbox image pull.

Service flags (tigerstrike-service, passed as command/args):

Flag	Default	Purpose
`--port`	`8085`	Local health / API port.
`--workers`	`4`	Max concurrent scans on this host (sample manifests set `2`).
`--mode`	`standard`	`standard`, or `internal` to lock down egress when scanning customer infra.
`--output-root`	`$TIGERSTRIKE_OUTPUT_ROOT`	Artifact directory.
`--api-key`	`$TIGERGATE_API_KEY`	Worker token (prefer the env var / secret).

Multiple workers / fleets

You can register multiple workers with the same org — give each a unique TIGERSTRIKE_WORKER_NAME in .env. The dashboard’s Pentest → Scanners page shows the fleet; when you create a scan, you pick which worker (or “any available”) runs it. Useful when:

You have multiple isolated networks and want one worker per network.
You want to scale by spinning up more workers; each pulls jobs independently.
You want a primary + standby for the same network.

​When to use it

​What the worker does

​What stays on your host

​What you need

​Run it

​Configuration options

​Multiple workers / fleets

When to use it

What the worker does

What stays on your host

What you need

Run it

Configuration options

Multiple workers / fleets