VardrRunner
The local automation runner for the VardrSec product family.
VardrRunner runs your security tooling on your machine and syncs the results to a VardrSec backend (today: VardrMap) over HTTP. It is a thin, fast, dependency-light client: it polls the backend for queued scan jobs, claims them atomically, executes the tool locally, streams live progress back, uploads results, and heartbeats so the backend always knows which machines are online.
Why local? Recon and scanning tools belong on the operator's box — their bandwidth, their IP, their tool versions. The backend orchestrates and stores; the runner does the work. The two are fully decoupled and only ever exchange JSON.
Features
- Job queue worker — poll, atomically claim, execute, and report scan jobs
- Daemon mode —
daemon startruns a continuous background worker (poll every 5 s, heartbeat every 60 s) with detached mode, PID file, and graceful shutdown - Tool runners —
httpx,subfinder,nuclei,nmap,dnsx,naabu(more coming), each capturing output into a timestamped run directory, every run bounded by a timeout - Recon pipelines — chain tools in one command:
recon(subfinder → httpx → nuclei),deep(adds dnsx resolution),ports(subfinder → dnsx → naabu),quick - VardrGate authorization tests —
vardrgate_api_testjobs drive the localvardrgatebinary over a CLI/JSON contract and attach the sanitized result to the job. Identity credentials may reference a secret (value_env/value_keychain) that is resolved on the runner at execution time, so the secret never reaches the backend - Importers — pull existing
nuclei/httpxoutput files into the backend - Real heartbeat — reports hostname, version, OS, and per-tool availability so the backend's Bridge shows live machine status
- Live job events — emits
started → targets_resolved → running → uploaded → done/failedso the backend Terminal shows real-time logs - Preflight (
doctor) — one command validates the whole machine (creds, URL, perms, auth, daemon, disk, tools, pipelines) and exits non-zero on actionable failures, for scripting unattended/VPS provisioning - Safe by default — missing tools fail the job loudly, targets are normalized before use, and the API key is stored locally with restrictive permissions
Requirements
- Python 3.10+
- The external tools you intend to run, on your
PATH(e.g.httpx,subfinder,nuclei,nmap,dnsx,naabu) — plusvardrgateif you runvardrgate_api_testjobs - A VardrSec backend URL and an API key (
vmap_…for VardrMap) - VardrMap ≥ v0.22.0 as the backend — the runner calls
/engagements/*(see CHANGELOG v0.27.0)
Install
pipx install vardrrunner
That's it — pipx puts vardrrunner on your PATH in its own
isolated environment, which is what you want for a CLI. pip install vardrrunner also
works if you're already inside a virtualenv you manage yourself.
No Python on the machine?
Common on a fresh VPS or a clean Windows box. uv is a single static binary that downloads its own CPython, so it needs nothing preinstalled:
# install uv itself
curl -LsSf https://astral.sh/uv/install.sh | sh # macOS / Linux
powershell -c "irm https://astral.sh/uv/install.ps1 | iex" # Windows
uv tool install vardrrunner
uvx vardrrunner <command> runs it without installing at all — handy for a one-shot job on
a box you don't intend to keep.
Other options
From a GitHub Release — every tag ships a wheel, an sdist, a CycloneDX SBOM, and a build-provenance attestation. Use this when you need to verify the artifact before installing it:
pipx install ./vardrrunner-<version>-py3-none-any.whl
From source, for development:
git clone https://github.com/VardrSec/VardrRunner.git
cd VardrRunner
python -m venv venv
.\venv\Scripts\Activate.ps1 # Windows (macOS/Linux: source venv/bin/activate)
pip install -e ".[dev]"
Note that a clone alone does not give you the vardrrunner command — it has to be
installed into an environment on your PATH, which is what the pip install -e step
above does. Inside a venv you'll need it activated; pipx/uv avoid that entirely.
Homebrew / Scoop formulae are planned once there's demand.
Quick start
vardrrunner login vardrmap # prompts for backend URL + API key; key goes to your OS keychain
vardrrunner status # show config, version, and which tools are detected
vardrrunner heartbeat # confirm the backend can see this machine
vardrrunner daemon start # run the continuous worker (poll jobs + heartbeat)
One-shot usage
vardrrunner engagements # list your engagements
vardrrunner scope <engagement-id> # show in/out-of-scope items
vardrrunner jobs list # show the backend queue
vardrrunner jobs run # claim + execute all pending jobs once
vardrrunner run subfinder --engagement <engagement-id> # run a single tool and upload results
vardrrunner import nuclei --engagement <engagement-id> -f out.jsonl
--engagement takes the engagement UUID; --program and -p are accepted as aliases.
See docs/cli.md for the full command reference.
Configuration
Desktop / dev: vardrrunner login stores your API key in the OS keychain (macOS
Keychain, Windows Credential Locker, Linux Secret Service), leaving only the backend URL in
~/.vardrmap/config.json. Where no keyring backend is available it falls back to writing
the key in cleartext to that same file, warning you when it does — so on headless boxes and
containers prefer VARDRMAP_API_KEY below. vardrrunner status reports which source is
actually in use, and vardrrunner logout removes the key from both.
CI / servers / containers: set credentials via environment variables (no keychain
needed). The key resolves in this order — VARDRMAP_API_KEY env → OS keychain → config
file:
| Variable | Purpose |
|---|---|
VARDRMAP_URL |
Backend base URL (must be https://, except localhost) |
VARDRMAP_API_KEY |
Your vmap_ API key |
VARDRRUNNER_TOOL_TIMEOUT |
Per-tool run timeout in seconds (default 1800); a hung tool is killed and the job marked failed |
VARDRRUNNER_ALLOW_INSECURE |
Set to 1 to permit a plain-HTTP backend URL (not recommended) |
The runner refuses to send your API key over plain HTTP to a non-local host, so a mistyped
http:// URL can't leak your key.
Documentation
- docs/architecture.md — how the runner is structured and how it talks to the backend
- docs/development.md — local setup, testing, and contribution workflow
- docs/cli.md — complete command and flag reference
- docs/adr/ — Architecture Decision Records
- CHANGELOG.md — version history
Development & testing
pip install -e ".[dev]" # editable install + dev tools (pytest, ruff, mypy)
ruff check vardrrunner tests # lint
ruff format --check vardrrunner tests # formatting
mypy vardrrunner # type check
pytest tests # 463 tests; all subprocess + HTTP calls are mocked
CI runs ruff (lint + format), mypy, and a bandit security scan, then the test suite at a
95% coverage floor on Python 3.10/3.11/3.12 (Linux) plus a 3.12 smoke on Windows and
macOS, and a pip-audit dependency audit — on every push and PR to main.
Contributions follow the Engineering Charter in CLAUDE.md: clean code,
tests in the same commit, docs updated, and the suite always green.
License
MIT © 2026 Jorge Aquino.
Part of the VardrSec product family — VardrMap · VardrRunner · VardrVault.
Metadata
Release files for vardrrunner 0.28.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| vardrrunner-0.28.1.tar.gz | 80.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| vardrrunner-0.28.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 131.7 kB
Release files / vardrrunner-0.28.1.tar.gz
| Download URL | vardrrunner-0.28.1.tar.gz |
|---|---|
| Size | 80.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
ec85d19626cfb4da7fced81360d8730c1343b4310e2292bc58bedbaf57ee7d3a
|
|
BLAKE2b-256 checksum How to use checksums |
ec38d3d97f8b75ef2291274733d9d60b0451f0ca81704f6af8685e6b5c22b19a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 18, 2026.
Transparency logRelease files / vardrrunner-0.28.1-py3-none-any.whl
| Download URL | vardrrunner-0.28.1-py3-none-any.whl |
|---|---|
| Size | 51.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
b0f2767a67e488bee3e322c621c2e499437eef48d0051309fe365de5a090ee7c
|
|
BLAKE2b-256 checksum How to use checksums |
ff24e97bec2223541d9f104fc2a084b1b62642cb0fb6fc7b4b2cc5c8ca7311f1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 18, 2026.
Transparency log