There is a fast way to build "distributed recon" and a right way. The fast way is a shell script that SSHes into a few boxes and runs other people's tools in a loop. It demos well and falls apart the moment a box dies, a tool version drifts, two people share a fleet, or you need to know what a run actually cost. We took the slow path and built the stack from the runtime up. Nine layers, each one earning its place. This post walks all nine and says plainly why each exists instead of being glued together.
The dividing line throughout: which engines and the node agent are open source and run standalone, while the orchestration, scheduling, and control plane are the hosted platform. The layers below the engines exist so the engines can be driven as a fleet instead of one terminal at a time.
Layer 1: distributed node runtime
The bottom layer is a runtime that turns any Linux or macOS box into a node: a supervised worker that pulls operations, runs engines, streams results back, and reports a heartbeat. It survives reboots because it installs as an OS service.
Why it matters: a process you started over SSH dies with the session. A runtime is a durable participant in a fleet. That single difference is what makes everything above this layer possible.
Layer 2: node provisioning
Turning a fresh box into a trusted node is one command: crossfyre node init with a key from the dashboard. That enrols the host, installs the selected engines, provisions the local database, sets up the OS service, and hands the node scoped credentials rather than a master key.
Why it matters: the real trust boundary in a distributed system is per-node credentials, not in-binary checks. Scoped creds mean a compromised or retired node can be cut off without touching the rest of the fleet. One-command enrolment means you actually do it instead of hand-configuring boxes and getting it subtly wrong.
Layer 3: package management
Engines and extensions are packages the CLI manages across the fleet: crossfyre extension install, update, remove. Every binary is checksum-verified against a signed release manifest before it runs, and you can pin and update versions deliberately.
Why it matters: "it works on my node" is the distributed version of version hell. When ten boxes silently run three different builds of a scanner, your results are not comparable and your bugs are not reproducible. Fleet-wide, signed, pinnable packages make every node run the engine you think it is running.
Layer 4: networking
The networking layer is two things at once: the control bus and egress control. The bus is NATS JetStream, a persistent acknowledged message stream that carries operations to nodes and results back. Egress is the proxy chains and VPN-isolated tunnels that decide where scan traffic actually leaves from.
Why it matters: a durable bus is what makes work survivable (an unacknowledged operation gets redelivered) and what makes the fleet coordinate without a fragile central poller. Egress control is what keeps an authorized test in-scope, leaving from exactly the IP you intend with no DNS leaks.
Layer 5: the tooling ecosystem
The engines are the part that touches the target. They are open source, written in Rust, stateful, and resumable, and they run standalone or orchestrated:
- voyage: subdomain enumeration, passive sources plus active brute-forcing.
- pulse: host and port scanning with service detection.
- mach: HTTP content discovery (paths, parameters, virtual hosts), resumable.
- extensions: the same plug-in shape, so the catalog grows beyond the core three.
Why it matters: owning the engines means they speak the platform's native result types and persist resumable state, so the layers above can pipe, distribute, and crash-recover them. A wrapped third-party binary that only emits text on stdout can do none of that.
Layer 6: the workflow engine
A workflow composes engines into repeatable, parametrized steps: a .cfx playbook picks targets, calls engines, pipes one stage's output into the next, branches on results, and exports. Run it locally with crossfyre run or launch it across the fleet.
Why it matters: recon is a pipeline, not a single tool invocation. The workflow layer is where "enumerate, then validate, then scan, then discover" becomes one artifact you can version and rerun, instead of tribal knowledge in someone's terminal history.
Layer 7: orchestration
Orchestration is the layer that takes a workflow and makes it happen across many nodes: it decomposes the work into operations, distributes them, keeps crash-safe state on the durable queue, and runs things on a schedule for recurring scans.
Why it matters: this is the difference between a fleet and a pile of boxes. Distribution turns a four-hour scan into a forty-minute one. Crash-safe state means a reclaimed node costs you the handful of operations in flight, not the whole run. Scheduling means your surface re-maps itself instead of waiting on you to remember.
Layer 8: the control plane
The control plane is the hosted brain: accounts, teams and RBAC, billing, and the API. Teams share nodes, wordlists, and findings. Roles run from the system roles Leader and Member up to custom roles built from a granular permission catalog: execute workflows, deploy nodes, manage extensions, upload or delete wordlists, view activity. An activity log records who did what.
Why it matters: a shell-script fleet has no notion of "who" or "how much." The moment two people share infrastructure you need access control, and the moment you bill real work you need accounting. Billing here is reserve-then-reconcile (charged for work that actually completed) with credits that never expire, so you pay for finished recon, not for crashing boxes.
Layer 9: visualization and results
The top layer is where raw output becomes something a human acts on: a dashboard with live telemetry on running scans, and a Findings explorer that filters by severity, active or passive discovery, and host, then exports to CSV, JSON, or Markdown. Notifications push the moment a finding lands.
Why it matters: recon that produces a wall of text produces nothing you will read. Prioritized, filterable, exportable findings are how all eight layers below actually turn into a bug you report and a dollar you earn.
Why nine layers instead of a script
Any one of these layers is something you could bodge for a weekend project. The reason they exist as real layers is that they compose: scoped provisioning is what makes RBAC trustworthy, the durable bus is what makes orchestration crash-safe, owning the engines is what makes workflows pipeable, and reserve-then-reconcile billing is only honest because orchestration knows exactly which operations completed.
Gluing tools together gets you a demo. Building the stack gets you a platform that survives a dead node, a shared team, a version drift, and a long-running scan, and still tells you what it cost. That is the difference we built for. See how the layers feel in practice on the docs, or compare the approach on Crossfyre vs Axiom.
Enrol a node and run a workflow across the whole stack on a free account.
Start free