Config File Location
The main config file is~/.vigolium/vigolium-configs.yaml. It is created automatically on first run with sensible defaults.
Vigolium searches for configuration in this order:
- Path specified via the
--configflag (error if not found) ~/.vigolium/vigolium-configs.yaml./vigolium-configs.yaml(current working directory)
Config Precedence
Settings are resolved from highest to lowest precedence:- CLI flags -e.g.
--concurrency 100,--rate-limit 50 - Environment variables -e.g.
VIGOLIUM_API_KEY,VIGOLIUM_PROJECT_UUID - Scanning profile -loaded via
--scanning-profile <name>(from~/.vigolium/profiles/) - Project-level config -per-project overlay at
~/.vigolium/projects/<uuid>/config.yaml - Main config file -
~/.vigolium/vigolium-configs.yaml - Built-in defaults -hardcoded in the Go source
${VAR} or $VAR syntax and are expanded at load time.
Environment Variables
VIGOLIUM_DB_PATH
Set it once and every command in that shell reads and writes the same database file, without repeating --db:
--silent, -j, and --ci-output-format).
The variable carries one deliberate asymmetry. Reads additionally treat the file as a standalone source — project scoping is turned off, so every row in the file is listed regardless of the project_uuid it carries, exactly as -S --db <file> behaves. Writes do not: a scan into the pinned database still records its own project. This means you can point the variable at a colleague’s export and query all of it, while your own scans stay properly attributed.
An explicit
--db always wins. The variable is skipped until the file exists, so the first read of a not-yet-written session doesn’t fail. And it never sets --stateless for you: on scan / scan-url / scan-request / run that flag means “scan into a throwaway temp database” and is mutually exclusive with --db — passing -S explicitly on one of those commands makes the variable a no-op.vigolium-configs.yaml:
CLI Config Overrides
Usevigolium config set to update individual config values using dot-notation keys:
Config Sections
scanning_strategy
Controls which scan phases run for each strategy preset.
Phase aliases:For source-aware whitebox analysis, usedynamic-assessmentis the canonical name for active/passive vulnerability scanning.audit,dast, andassessmentare accepted aliases on--only/--skipflags.discoveryacceptsdeparos/discover;spideringacceptsspitolas;extensionacceptsext.
vigolium agent swarm --source <path> or vigolium agent audit --source <path> instead of a native scan strategy. See Agent Mode.
scanning_pace
Centralized speed control. Common values serve as baselines; per-phase subsections override them.
discovery
Content discovery (directory/file brute-forcing).
discovery.engine.disable_kingfisher is gone — secret scanning is in-process Go now (no external kingfisher binary). The replacement key is disable_secret_scan.spidering
Browser-based crawling.
max_depth and max_states default to 6 and 1500 — they were unlimited before v0.3.8. Both bound how the crawl spends its max_duration: without a depth bound a link-dense site can sink the whole budget into one deep branch and never revisit the breadth near the seed, and without a state bound a template that mints a state per row (a paginated table, a calendar) spends it on near-identical pages. Set either to 0 to restore unlimited.self_register lets the crawl complete a public signup form and continue as the account it creates — on an app with open registration, that is the difference between crawling the marketing shell and crawling the product. It runs at most once per host, only submits to an in-scope host, and reuses the identity it creates at any later login form. It stays off by default because registering is a write; --intensity deep turns it on, and setting this key to true forces it on at any intensity.
graph_output_dir writes the finished crawl graph into a directory (one file per host). Captured traffic records what was requested; the graph records how the crawler got there — which action on which state, with which form values, and the selector to find that element again — which is what makes a run reproducible and lets a later pass re-reach a specific state. It is a directory rather than a path because one browser session reuses a single config across all of a host’s seeds.
dynamic-assessment
Controls which scanner modules run and JavaScript extension settings. (Formerly audit.)
scope
Defines what is in scope for scanning. Exclude rules take priority over include rules.
server
REST API server settings.
--view-only, --no-agent, --demo-only, --alternative-ingest-key, --disable-warm-session — are CLI-only; see Narrowing the Exposed Surface.
agent
AI agent integration. Every agent invocation is dispatched through the in-process olium runtime, there are no subprocess SDK or ACP backends.
autopilot_mode is opt-in: legacy keeps one growing conversation and writes findings directly, shadow adds bounded context rotation while mirroring candidates, and enforced promotes only fresh-context verifier-confirmed candidates. Only shadow and enforced support agent autopilot --resume <agentic-scan-uuid>.
Provider quick reference:
CLI flags
--provider, --model, --oauth-cred, --oauth-token, --llm-api-key, --base-url, --bridge-bin override these per-invocation. The REST API does not mirror these overrides, server-side workloads use the YAML config exclusively. See Setting Up the Agent for a step-by-step walkthrough or Olium Agent for full provider details.
database
Storage backend. SQLite is the default; PostgreSQL is supported for multi-user deployments.
known_issue_scan
Known-issue scanning powered by the Nuclei template engine.
vigolium config ls known_issue_scan.group_by_value to print the full built-in module lists for your build.
mutation_strategy
Controls how parameter values are mutated during active scanning.
external_harvester
Pre-scan intelligence gathering from public data sources.
oast
Out-of-Band Application Security Testing via interactsh callbacks.
source_aware
Storage location for cloned source repositories. Used when --source receives a git URL (autopilot, swarm, audit, query). Static analysis tooling (ast-grep, semgrep, etc.) has been removed, for AI-driven code audit, use vigolium agent audit or vigolium agent swarm --source --code-audit.
storage
Cloud storage integration for source code upload/download and scan result archival. Uses an S3-compatible API, supports GCS (via HMAC), AWS S3, and MinIO.
--upload-results archive their session bundle to <bucket>/<project-uuid>/agentic-scans/<run-uuid>/results.tar.gz. Native scans use <bucket>/<project-uuid>/native-scans/<scan-uuid>/results.tar.gz. See Storage API for upload/download endpoints.
notify
Real-time finding notifications via Telegram or Discord.
Scanning Profiles
Scanning profiles are YAML files stored in~/.vigolium/profiles/ that override subsets of the main config. They can tune any combination of: scanning_strategy, scanning_pace, discovery, spidering, known_issue_scan, audit, external_harvester, mutation_strategy, and scope.
Apply a profile with:
~/.vigolium/profiles/aggressive.yaml and overlays it onto the active config. Only non-zero fields in the profile override the base config; unspecified fields are left unchanged.
Built-in profiles are bundled in public/presets/profiles/. See native-scan/scanning-modes-overview for details.
Project-Level Config
Each project can have its own config overlay at~/.vigolium/projects/<uuid>/config.yaml. This uses the same format as scanning profiles and is automatically applied when the project is active.
Manage project configs with:
