Axiom: Distributing Security Scans Across Hundreds of Cloud Instances With Shell Scripts

Hook

What if you could spin up 100 cloud instances running nuclei, nmap, and ffuf in under 60 seconds, distribute a million-line wordlist across them, then destroy everything with a single command?

Context

Traditional security scanning faces a brutal tradeoff: thoroughness versus time. Running comprehensive scans with tools like masscan, nuclei, or nmap against large attack surfaces can take days on a single machine. Bug bounty hunters operating on tight time windows and penetration testers with limited engagement periods need results faster. The obvious solution—throwing more compute at the problem—has historically required significant DevOps overhead: provisioning servers, installing dependencies, distributing workloads, aggregating results, and cleaning up afterwards.

Axiom emerged from the offensive security community to eliminate this friction. Created by @pry0cc, it treats cloud infrastructure as truly disposable commodity hardware optimized for burst scanning operations. Rather than maintaining persistent scanning infrastructure, Axiom embraces the immutable infrastructure pattern: pre-bake images with every tool you need, deploy fleets in seconds, run your scans, collect results, and destroy everything. It's infrastructure-as-cattle taken to the extreme, where your entire scanning environment exists for minutes or hours, not months.

Technical Insight

Axiom's architecture revolves around three core components: image building with Packer, fleet management through a unified CLI, and distributed scanning via axiom-scan modules. The brilliance lies in how these pieces work together to eliminate setup time.

The foundation is Packer-based image creation. When you initialize Axiom, it builds a base image for your chosen cloud provider containing every security tool in the ecosystem—subfinder, httpx, nuclei, ffuf, masscan, nmap, gowitness, and dozens more. This one-time build process takes 15-30 minutes but creates an immutable snapshot you can clone infinitely. Here's how you'd initialize Axiom for DigitalOcean:

# Install and configure Axiom
axiom-configure --config digitalocean

# Build your base image (one-time setup)
axiom-build

# This creates a snapshot with ~50+ security tools pre-installed
# Next deployments from this image take 30-60 seconds instead of 30 minutes

Fleet management happens through axiom-fleet, which abstracts multi-cloud APIs into simple commands. Want 50 droplets for a bug bounty recon sprint? A single command handles provisioning, SSH key distribution, and instance naming:

# Spin up 50 instances named recon01 through recon50
axiom-fleet recon -i 50

# Check fleet status
axiom-ls

# SSH into any instance
axiom-ssh recon23

# Destroy everything when done
axiom-rm 'recon*' -f

The real power emerges with axiom-scan, which distributes workloads across your fleet without requiring manual orchestration. Say you're scanning 10,000 subdomains for web services and want to screenshot everything. Axiom automatically chunks your input file, distributes it across available instances, runs the tools in parallel, and aggregates results:

# Distribute subdomain list across fleet, run httpx, collect results
cat subdomains.txt | axiom-scan -m httpx -o live-hosts.txt

# Chain operations: find live hosts, then screenshot them
cat subdomains.txt | 
  axiom-scan -m httpx -o live.txt && 
  cat live.txt | 
  axiom-scan -m gowitness -o screenshots/

# Run nuclei across 100 instances with custom templates
cat targets.txt | 
  axiom-scan -m nuclei -o vulns.txt --templates custom-checks/

Under the hood, axiom-scan uses a surprisingly elegant distribution strategy. It splits your input file into chunks matching your fleet size, uploads each chunk to a different instance via SCP, executes the scanning module remotely via SSH, and uses inotify to stream results back as they're generated. The implementation is pure shell script with heavy use of GNU Parallel and tmux for coordination:

# Simplified version of how axiom-scan distributes work
instances=$(axiom-ls)
total=$(echo "$instances" | wc -l)

# Split input into chunks
split -n l/$total targets.txt chunk-

# Distribute and execute
i=0
for instance in $instances; do
  scp chunk-$(printf "%02d" $i) $instance:/tmp/targets
  ssh $instance "nuclei -l /tmp/targets -o /tmp/output" &
  i=$((i+1))
done

wait

# Collect results
for instance in $instances; do
  scp $instance:/tmp/output results-$instance.txt
done

Axiom modules are just shell scripts in ~/.axiom/modules/ that define how to run specific tools. Creating a custom module for a new tool takes minutes—you define input handling, tool execution, and output formatting. This extensibility explains why Axiom became popular: the community can add support for new security tools faster than any monolithic solution could adapt.

The framework also includes smart cost-saving features. Axiom can automatically select the cheapest instance types that meet your requirements across providers, use spot/preemptible instances for additional savings, and includes built-in warnings when fleets have been running for extended periods. It's designed by practitioners who've experienced the pain of $2,000 cloud bills from forgotten instances.

Gotcha

The elephant in the room: Axiom is in maintenance mode. The project README explicitly states development has shifted to the 'Ax Framework,' a successor being built from scratch. This means bug fixes only, no new features, and potential compatibility breaks as cloud provider APIs evolve. Shell scripts are notoriously brittle when external dependencies change—a breaking update to the DigitalOcean API could render portions of Axiom non-functional until someone volunteers a patch.

The shell-based architecture, while enabling rapid development and easy customization, creates debugging nightmares. Error messages are often cryptic, stack traces don't exist, and tracing execution flow through nested scripts with global state mutations requires patience. If you're accustomed to strongly-typed languages with proper error handling, Axiom's codebase will frustrate you. There's also the cost management risk: spinning up 100 instances is dangerously easy, and cloud bills can escalate quickly if you forget to run axiom-rm. The framework includes warnings, but ultimately relies on user discipline. A single overnight mistake with a 50-instance fleet can cost hundreds of dollars, especially on AWS or Azure where pricing is less transparent than DigitalOcean.

Verdict

Use if: You need to perform large-scale distributed security scans right now, you're comfortable with command-line tools and shell scripting quirks, and you're operating in the bug bounty or penetration testing space where time-to-results matters more than infrastructure elegance. Axiom excels at one-off scanning campaigns where you need massive parallelization for hours or days, then complete teardown. It's also valuable if you're already proficient with the included security tools and want orchestration without learning Kubernetes. Skip if: You're building long-term infrastructure that needs support and active development, you require enterprise-grade reliability with proper error handling and logging, you're inexperienced with cloud cost management, or you're starting a new project from scratch—in which case, monitor the Ax Framework's development or invest time in learning Terraform/Ansible for more maintainable infrastructure-as-code. Also skip if your organization has compliance requirements around infrastructure management, as Axiom's disposable nature and shell-script foundation won't pass most security audits.