✅Existing Users

We are deeply committed to maintaining continuity for Axiom Classic users, carefully preserving many of the core principles you may rely on. Most importantly, your existing automation, scripts, and modules should continue to function without any need for modifications.

Upgrading from Axiom Classic

Before proceeding with the upgrade, it is highly recommended that you back up your existing Axiom Classic folder to a safe location:

mkdir ~/axiom-classic && cd ~/axiom-classic && zip -r axiom-classic-bak.zip ~/.axiom/

Next, backup any custom modules you might have created.

mkdir ~/axiom-classic/custom-modules && cp ~/.axiom/modules/custom.json ~/.axiom/modules/custom2.json ~/axiom-classic/custom-modules/

After backing up, you can delete your current Axiom Classic folder and proceed with installing the Ax Framework. Ensure that the ~/.axiom/ folder does not exist before installing the Ax Framework.

Once Ax is installed and configured, simply copy your custom modules back into the ~/.axiom/modules/ directory.

And that’s it! You are now fully prepared to use the Ax Framework. If you ever need to revert to Axiom Classic, just delete the new ~/.axiom/ folder and restore your Axiom Classic backup folder.

Syntax Changes

We've placed a strong emphasis on ensuring that existing Axiom Classic users can quickly transition to the new Ax Framework with minimal syntax changes. Here are some key changes to be aware of:

ax Wrapper: The new ax wrapper seamlessly passes additional arguments to the appropriate axiom-* script in the background (located in ~/.axiom/interact/axiom-*). This means you can fully control all aspects of the new framework without ever leaving ax. While this wrapper simplifies control, using it is optional—you can still run axiom-* scripts directly as you did before.

ax configure: Previously, running axiom-configure without any arguments would start the configuration flow to install dependencies. Now, it shows the help menu instead. To start the installation flow, you’ll need to add the --run argument to ax configure.

ax account-setup: Now officially supports Hetzner and GCP as additional cloud providers.

ax build: Previously, running axiom-build without any arguments would automatically start the Packer image builder. Now, this command shows the help menu. To start the image build, you’ll need to add the --run argument to ax build.

ax init: Earlier, running axiom-init without arguments would initialize a single instance with a random name. Now, it brings up the help menu instead. To spin up one instance with a random name, use axiom-init --run. This change helps ensure you don’t miss out on the helpful options available, which were often overlooked in Axiom Classic.

ax fleet: Similarly, running axiom-fleet without arguments used to create a fleet of three instances automatically. Now, it displays the help menu for the same reasons as above. To spin up a fleet of three instances, use ax fleet -i 3.

ax rm: To avoid accidental deletions of instances, now all cloud providers support the optional -f argument to forcefully delete instances, avoiding confirmation prompts (previously only Digital Ocean, IBM Cloud and Azure supported -f).

ax images create: In Axiom Classic, creating a snapshot of an existing instance for future fleets was done using axiom-backup. This functionality has now been moved to ax images create.

ax scp: Now, ax scp supports optionally splitting a file across a fleet of instances, equally distributing the file (--split)

ax sizes: The new ax sizes scripts allows you to list all instance sizes the cloud provider has to offer. Select the default instance size to use for ax fleet and ax init. To restore to the default instance size, use ax sizes default.

vars.sh: You can now control the Go Lang version installed on the Ax controller and remote instances by specifying the GolangVersion in vars.sh. You will need to rebuild (ax build --run) if this is changed.

ax scan: Key Updates and Enhancements

• New Options and Refactoring: We've added several new options to ax scan, and some existing options have been refactored.

FOLDER

• New _folder_ Variable Replacement: In Axiom Classic, the path to Nuclei templates was treated as a wordlist (using the _wordlist_ variable replacement). Now, the options --local-folder and --remote-folder have been introduced. To upload a local folder, use --local-folder, which utilizes the _folder_ variable replacement. For backward compatibility, --nuclei-templates with _wordlist_ is still supported, but you will receive a warning about the syntax.

ONE-SHOT

• Track Finished Targets: When using One-Shot modules with the ax scan option --track-finished, it now tracks which targets have been scanned and stores them in a file named finished.txt on the remote instances

OPTIMIZATIONS

• File Uploads and Downloads: Before a scan starts, you can now upload an arbitrary file to the remote scan working directory at runtime using --upload. Additionally, after the scan finishes, you can download an arbitrary file from the remote scan working directory with --download.

• anew Option: The --anew argument has been moved from being an output type to a standalone option. Previously, you would use it like this: axiom-scan input -m module -anew anew-output.txt. Now, the syntax is ax scan input -m module -o anew-output.txt --anew. Note that this also requires the extension "ext":"txt", "ext":"oG", or "ext":"csv" to be included in the module.

OUTPUT

• -oT / -txt: Previously, this output type and module extension "ext":"txt" would automatically sort and deduplicate results. Now, instead of sorting, the results are simply concatenated into a single file without further processing.
• -oG: This new output type and module extension "ext":"oG" now handles sorting and deduplication of results.
• -jsonl: A new output type and module extension "ext":"jsonl" that supports merging JSON Lines.
• --no-logs: This flag disables all logging. It prevents the storage of logs and terminal output. Additionally, it deletes all log files, including unmerged output files located in ~/.axiom/logs/$module+$timestamp/output.

• Filename Format: In Axiom Classic, if you didn’t specify an output filename for axiom-scan, it would generate one using the format scan+$timestamp. Now, this has been updated to $module+$timestamp, where $module represents the specific module used during the scan.

FLEET

• --shutdown-when-done: Now initiates the shutdown of instances without waiting for all the scanners to complete.

EXTRA ARGS

• Explicit Extra Arguments: Axiom has always automatically interpolated user-provided command-line arguments into the module, combining them with the module's command and executing them on remote instances in parallel. This core behavior remains unchanged. However, with the new Ax Framework, you now have the option to explicitly define extra arguments to be passed to the module, rather than relying solely on automatic interpolation.

  The --extra-args flag must be used with commands wrapped in either single or double quotes, depending on whether you want variable expansion to occur locally (double quotes) or remotely (single quotes).