Private runners
Private runners execute eligible ZeroQuarry scans from Docker hosts inside networks you control. Use them when the assessment must reach an internal application, or clone source without moving the repository through a hosted worker.
Private runner pools are an Enterprise capability. They support remote scans and Git-backed source scans; binary uploads and source file uploads continue to use ZeroQuarry Cloud.
Private runners start by defining a network boundary. Setup then selects the scan modes the pool may run.
Choose a private runner for the right reason
| Need | Private-runner behavior |
|---|---|
| Test an internal application | Remote workers can reach RFC1918, loopback, link-local, and internal-DNS targets from the customer network. |
| Keep Git cloning on your infrastructure | Git source is cloned directly by the runner. Source uploads are rejected for private execution. |
| Control network ingress | Runners initiate outbound HTTPS; no inbound firewall rule is required. |
| Separate trust zones | Create distinct pools for environments such as a production VPC, staging network, or lab. |
A private runner is not a standalone or air-gapped ZeroQuarry deployment. SaaS remains the control plane, while the customer-controlled host performs the scan and calls each selected LLM provider directly. Every selected scan, review, and artifact model must have an account-managed API key.
Choose where each part runs
| Component | Location |
|---|---|
| Account, project policy, job assignment, and centralized reporting | ZeroQuarry SaaS control plane |
| Git clone or active target testing | Customer-controlled runner host |
| LLM calls | Directly from the runner to the selected provider, using account-managed keys |
| Findings, logs, and artifacts | Returned to SaaS so the normal report and evidence workflows work |
The runner initiates outbound HTTPS connections. ZeroQuarry does not require an inbound firewall rule into the customer network.
Scan results return in full: findings, descriptions, exploit proofs, review history, logs, and generated artifacts reach the control plane so reports, verification tests, and the Evidence Room work the same as for cloud scans. The source code the runner cloned stays local — cloned repositories do not transit the control plane, which is why source views are not available for private-runner source scans.
Supported scans
Private pools support:
- Git-backed source scans, where the runner clones the repository directly
- authorized remote-target scans, including internal DNS and private address ranges reachable from the Docker host
Browser source uploads, archives, and binary uploads continue to use ZeroQuarry Cloud. Uploaded inputs cannot become private-runner jobs because they would pass through the SaaS control plane before execution.
Private reachability does not expand authorization. Remote scans still require explicit scope, approved test credentials, and non-destructive operating constraints.
Project assignment and failure behavior
Pools are not automatically available to every project. An owner or admin allows compatible pools under the project's Execution environments settings and chooses a default. Scan creators can select only an environment allowed for that project and scan type.
A private job remains pinned to its selected pool. If a runner or network connection fails, ZeroQuarry expires the attempt and requeues it to the same pool. It never falls back to ZeroQuarry Cloud automatically.