Skip to content
All posts

Inside the Go scanner orchestrator that runs every NANOTESTING scan

2 min readgo · architecture · queue · fly.io · engineering

Every NANOTESTING scan flows through a single Go service - nano-testing-worker - that pulls jobs from a Postgres advisory-lock queue and orchestrates 40+ sub-checks per run. Here is how the architecture holds up under load.

Job pickup: Postgres, not Redis

The queue lives in scan_jobs with status + locked-at columns. The worker leases a job by a SELECT ... FOR UPDATE SKIP LOCKED query inside a transaction. We get exactly-once delivery, durable retries on crash, and audit-log-quality history for free. No Redis, no SQS, one moving part.

Sub-check fan-out

A single scan is 40+ named steps: validate target URL, DNS public-IP guard, HTTP availability, TLS chain, security headers, cookie audit, JWT static analysis, robots + sitemap, redirect audit, passive tech fingerprint, mixed content, JavaScript libraries, SRI, COOP/COEP/CORP, passive SSRF surface, Referrer-Policy, HTTP methods audit, rate-limit headers, excessive data exposure, API health probes, JWKS hygiene, sensitive paths, subdomain inventory, CORS, email DNS, adaptive probes, open redirect, TLS support, GraphQL introspection, API discovery, OWASP ZAP, Nuclei, port scan, deep TLS, OpenAPI fuzz, BFLA probe, mass-assignment, rate-limit replay probe, webhook signature verification, subdomain takeover, IDOR cross-account, deep repo scan, on-chain audit. Each step writes its own scan_job_steps row with status + duration + findings_count + error_message so the UI can show live progress.

Tool isolation via Fly sidecars

We bundle Nuclei, osv-scanner, gitleaks, Trivy, Slither, Schemathesis, Semgrep, ZAP, Naabu, Tlsx, Prowler, Kubescape, CloudFox, and mobsfscan directly into the worker image (debian-slim, glibc for the OCaml semgrep-core). Echidna is the one AGPL exception: it runs as an isolated Fly sidecar (nano-testing-echidna.fly.dev) and the worker speaks to it over Fly's private network with a single POST per contract.

Step recorder + Sentry breadcrumbs

Every step goes through a StepRecorder helper that writes the start/end markers and pushes a Sentry breadcrumb. A scan that fails mid-flight has a perfect trail: which step failed, how long it took, what the error message was. Postmortems take five minutes.

The whole worker is one Go module, ~30k LOC, deployed as a single Fly machine in fra. Open the capabilities page to see every scanner module currently active.