How to use
Every feature, in the order you normally use it
The short version
Register a machine, request a scan, wait for the agents to pull the units, then read the results. Define programs and matching rules to attribute IPs automatically, and work the findings with scope decisions. Nothing scans on its own: machines pull queued work, and matching runs as a queued task — the only thing that runs by itself is a scan schedule you create.
Register a machineRequest a scanImport resultsAttribute to programsTriage findings
- 1Open Machines and click Add machine.
- 2Give it a name and the host label you will recognise (the VM's address). Capacity is the maximum concurrent connections the agent may use.
- 3Copy the token that appears — it is shown once. Use Rotate token later if you lose it.The token authenticates the agent on registration and on every heartbeat.
- 4On the VM, install the agent with the copy-paste command shown in the onboarding panel.The agent runs as a container with host networking and needs outbound access to this app's URL.
- 5Watch the machine flip to Ready after its first heartbeat, then open the row to run onboarding checks and read the checklist.
What the status values mean
SuccessfulTLS handshake completed and the HTTP response was read.
PartialThe port answered but the full response could not be collected.
TimeoutNo response within the probe timeout — often a firewall, not a dead host.
TLS failedThe port answered but the handshake did not complete.
No metadataOpen, but certificate or HTTP detail was missing at scan time.
UnreviewedNo scope decision has been made for this host yet.
In scopeConfirmed as part of the program you are working.
Out of scopeConfirmed as not part of the program.
Needs reviewFlagged for a second look before acting.
Operational notes
- Machines pull work. The app never connects to a scanner, so there is no SSH credential anywhere in the system.
- Scan requests and matching runs are queued tasks; a request stays Queued until a machine claims its first unit.
- A rescan action only creates a queued request — it does not start scanning by itself.
- A scan schedule is the one thing that queues requests on its own; the request it creates is an ordinary Node scan and appears in Jobs like any other.
- Every list is server-side paged and sorted; the rows-per-page selector (10 by default) applies per table.
- Data lives in two stores: scan results in the columnar store, programs, rules, jobs and machines in the relational store.