Skip to main content

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:
  1. Path specified via the --config flag (error if not found)
  2. ~/.vigolium/vigolium-configs.yaml
  3. ./vigolium-configs.yaml (current working directory)
If no config file is found, built-in defaults are used.

Config Precedence

Settings are resolved from highest to lowest precedence:
  1. CLI flags -e.g. --concurrency 100, --rate-limit 50
  2. Environment variables -e.g. VIGOLIUM_API_KEY, VIGOLIUM_PROJECT_UUID
  3. Scanning profile -loaded via --scanning-profile <name> (from ~/.vigolium/profiles/)
  4. Project-level config -per-project overlay at ~/.vigolium/projects/<uuid>/config.yaml
  5. Main config file -~/.vigolium/vigolium-configs.yaml
  6. Built-in defaults -hardcoded in the Go source
Higher-precedence sources override lower ones. Within the config file, environment variables can be referenced using ${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:
Each run prints a one-line notice naming the resolved database (suppressed under --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.
Any environment variable can also be interpolated inside vigolium-configs.yaml:

CLI Config Overrides

Use vigolium config set to update individual config values using dot-notation keys:
These commands modify the main config file directly. For one-off overrides during a scan, use CLI flags instead.

Config Sections

scanning_strategy

Controls which scan phases run for each strategy preset.
Available strategies and their default phases:
Phase aliases: dynamic-assessment is the canonical name for active/passive vulnerability scanning. audit, dast, and assessment are accepted aliases on --only / --skip flags. discovery accepts deparos / discover; spidering accepts spitolas; extension accepts ext.
For source-aware whitebox analysis, use 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.
The narrowing flags — --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.
Run 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.
When enabled, agent runs invoked with --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:
This loads ~/.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:
See projects for full project management documentation.