Database pruning, config reapply, doctor diagnostics, keygen, metrics, and the bundled benchmark.
Shortest commands
Database
mxnode db operates on the per-node db/ directory under each workdir.
Trim old data
Wipe a node’s database
The node will resync from peers on next start. --yes is required.
Reseed from genesis
Equivalent to db remove followed by an immediate restart.
db reseed can take many hours for an out-of-sync mainnet node. Run it in a screen / tmux session.
Reapply config
Walks every node, re-stamps prefs.toml (display name, observer pins, your prefs overrides) and config.toml (DbLookupExtensions, your config overrides), and writes them back. Use after editing [overrides.prefs] or [overrides.config] in ~/.config/mxnode/config.toml.
reapply-config does not touch RedundancyLevel — that’s an install-time choice via --backup.
Doctor
One-shot host diagnostic. Exits non-zero on any Error finding.
JSON for monitoring stacks:
Use as a CI gate before start --all:
Keygen
Standalone wrapper around mx-chain-go’s keygenerator. Generates validatorKey.pem (the BLS key) into the chosen output directory.
The keygenerator binary is built and placed at <custom_home>/elrond-utils/keygenerator during the first mxnode install. mxnode does not pre-generate observer keys at install time — observers auto-generate on first start.
Keys check
Verifies <node_keys>/node-{i}.zip exists for every validator node. Observer / multikey nodes are skipped.
For an observer-only or multikey-only install:
Benchmark
Roughly 30 seconds. Prints CPU, memory, disk IOPS, and network latency measurements with pass/fail thresholds derived from MultiversX validator requirements. Use before committing to running validators on a new host.
Configuration commands
Already covered in configuration, summarized here:
Version
The JSON form includes the schema version so monitoring stacks can detect upgrades. 
