Most of the questions people ask in their first hour with Crossfyre are really the same question: what runs where? Once the relationship between the control plane, your nodes, the workflows you launch, and the findings that come back is clear, the rest of the product reads naturally. This post locks that mental model in about five minutes.
There are four nouns to know: control plane, nodes, workflows (which decompose into operations), and findings. Everything else (engines, credits, teams) hangs off those.
The split: control plane vs nodes
Crossfyre is a hosted control plane plus nodes you bring yourself. The control plane is the part we run for you: the dashboard, the API, the orchestration and scheduling logic, the findings store. The nodes are your own machines. They do the actual scanning.
The control plane never scans anything itself. It decides what work needs doing and hands it out. The nodes pull that work down and execute it on hardware you control, on networks you choose. This is the whole point of a distributed model: your traffic leaves from where you want it to, and the scanning capacity is yours to scale by adding boxes.
A node is just one of your hosts, enrolled. Turn any Linux or macOS box into a node with the crossfyre CLI: crossfyre node init installs the engines, provisions a local database, and sets up an OS service so the node survives reboots. Each node gets its own scoped credentials, so revoking one box never touches the rest.
Engines: what actually scans
A node on its own does nothing. The work is done by engines: standalone Rust scanners that install onto the node. Three ship today, and all of them are open source:
- voyage: subdomain enumeration, combining passive OSINT sources with active DNS brute-forcing against a wordlist.
- pulse: port and service scanning across hosts and CIDR ranges.
- mach: HTTP content discovery and fuzzing (paths, parameters, virtual hosts).
You can run any engine standalone on a single box if that is all you need. The control plane is what lets you orchestrate them across a whole fleet at once. Both modes use the same binaries.
Workflows decompose into operations
A workflow is what you launch: a subdomain enumeration, a port scan, a content discovery sweep. It is the high-level intent, the thing you click "run" on in the dashboard. But a workflow is not what gets sent to a node.
When you launch a workflow, Crossfyre breaks it into operations: small, durable units of work. Operations are the things actually dispatched to nodes. A four-hour subdomain sweep is not one giant job sitting on one machine; it is hundreds of operations spread across your fleet. This decomposition is what makes the platform both fast (many nodes work in parallel) and resilient.
The operations ride a NATS JetStream stream, which is a persistent, acknowledged message log. A node pulls an operation, runs it, streams results back, and only then acknowledges it. If a node dies mid-operation before acknowledging, the operation is never marked done, and JetStream redelivers it to a healthy node. That is why a dropped node does not kill the run. We go deep on that in how scans survive a crashed node.
The unit of durability is the operation, not the workflow. Losing a node costs you the handful of operations that were in flight on it, not the hours of progress already banked.
Results come back as findings
As operations complete, their results stream back to the control plane as findings. A finding is a single result: a discovered subdomain, an open port and its service, a content path that returned interesting. They land live in the Findings explorer as the run progresses, not in a dump at the end.
From there you filter by severity, by method (active versus passive discovery), and by host; you search and paginate; and you export the set to CSV, JSON, or Markdown to drop into a report or a downstream pipeline. You can also wire up notifications so a Discord channel, a Slack channel, or your inbox pings the moment a scan finishes or a finding lands.
The lifecycle, end to end
Put the nouns in order and the whole product is one loop:
- You enrol a host as a node and the CLI installs the engines onto it.
- You launch a workflow from the dashboard against an authorized target.
- The control plane decomposes it into operations and publishes them to the durable stream.
- Your nodes pull operations, run the engines, and acknowledge as each completes.
- Results stream back as findings you filter, export, and get notified about.
- Credits are reconciled against the work that actually completed.
Where teams fit
Everything above describes a single account. A team is the same model with sharing turned on. In a Team Space, nodes, wordlists, and findings are shared across the crew, with role-based access: leaders manage members and billing, members run work. Seats and the size of your shared fleet are set by your plan. It is the same nouns, just pooled, so a teammate can launch a workflow that runs on a node you enrolled and read the findings you both care about.
That is the entire mental model. Control plane decides, nodes do, workflows decompose into operations, operations produce findings. If you want the precise commands and flags behind each step, the docs have the full reference. When you are ready to feel it in practice, the next step is to go from install to your first findings.
Enrol one box, launch one workflow, and watch the loop run.
Start free