If something’s not working, start by tailing the worker logs — most issues surface there with a clear error string: 
docker compose -f docker-compose.client.yml logs -f tigerstrike

​
Symptom → fix table

SymptomLikely causeFix
worker failed to register: 401Bad / revoked tokenRecreate the key in the dashboard, update .env, docker compose up -d
Tool server failed to startCompose changed away from network_mode: hostRestore network_mode: host — the sandbox needs it to reach the worker
port 8085 already in useSomething else on the host is on 8085Edit command: ["--port", "8090", ...] in docker-compose.client.yml
Image pull blockedDocker Hub egress blockedMirror the image internally — see Outbound endpoints
Scan stays “queued” foreverWorker not picked as runnerIn Pentest → New Scan, pick your self-hosted worker as the runner
Scan fails immediately with provider key not configuredLLM provider not set up in the dashboardOpen Pentest → Settings → AI Providers and add a key
Scan fails with budget exhaustedPer-scan or monthly budget cap reachedRaise the cap or accept the partial result. See Budgets & spend.
Worker registers, then disappears every few minutesOutbound connection unstable / proxy timing outCheck firewall keep-alive policy. Worker uses long-poll; idle connections need to survive ~60s.
Sandbox containers OOM-kill mid-scanHost RAM too lowBump VM to 16 GB, or reduce --workers to 1 in docker-compose.client.yml
docker: permission deniedUser not in docker groupsudo usermod -aG docker $USER then re-login (or run with sudo)

​
Verify outbound connectivity

If the worker can’t register, confirm it can reach the platform: 
# From the worker host, no proxies, no special routing.
# Swap in your region's API host — us1 shown.
curl -fsS https://api.tigergate.dev/health
# expected: {"status":"ok","timestamp":"..."}
If that fails, the worker won’t either — fix the firewall / proxy first. See Outbound endpoints for the exact hosts to allow, and Regions for which host is yours. If the health check passes but the worker still can’t register, the key and the region disagree: keys are region-scoped, so a tg_… key from one region is rejected by every other. Ask the host which region it is — the endpoint needs no credentials — and compare that with the region you created the key in: 
curl -fsS https://api.tigergate.dev/api/meta/region
# {"code":"us1",...}   ← must match TIGERGATE_REGION in the worker's .env

​
Verify Docker Hub access

docker pull tigergate/tigerstrike:1.0.0
If this fails, mirror the image to your internal registry and edit the image: line in docker-compose.client.yml accordingly.

​
Inspect worker state

The worker exposes a small status surface on its host port: 
curl -s http://127.0.0.1:8085/health     # liveness
curl -s http://127.0.0.1:8085/status     # registered? last poll? in-flight scans?
/status returns a JSON blob with the connected platform URL, the worker’s external name (as it shows up in Pentest → Scanners), and the scan queue depth. Useful for hooking into your own monitoring.

​
Resetting the worker

A clean reset that drops all scan artifacts and re-registers the worker: 
docker compose -f docker-compose.client.yml down -v
docker compose -f docker-compose.client.yml up -d
-v removes the tigerstrike_runs volume — historical artifacts are gone but findings already streamed to the platform are unaffected.

​
Reading verbose logs

Bump the log level if you need more detail: 
# docker-compose.client.yml
services:
  tigerstrike:
    environment:
      - TIGERSTRIKE_LOG_LEVEL=debug
Then docker compose up -d to apply. Revert when you’re done — debug logs are noisy.

​
Still stuck?

Email [email protected] with:
  1. The worker name (from .env’s TIGERSTRIKE_WORKER_NAME).
  2. The last 200 lines of docker compose logs.
  3. Output of curl -s http://127.0.0.1:8085/status.
We typically reply within one business day.