Home / Documentation
Documentation
Updated 20 October 2026
Install Vardion on your own server, see your first ranked findings the same day and connect the tools your team already uses. Prefer not to run a server? Start on the hosted console with its first steps.
Contents
- Install
- First steps
- Publish the console
- The hosted console
- How scanning works
- Connect your tools
- Software inventory
- API
- Command line
- Backup and updates
- Support
Install
The server needs Docker. From the Vardion folder, create the settings file from its example and start the console:
cp .env.example .env
docker compose up -d --build
Commands, variables and the compose service use the codename meridian.
The console listens on 127.0.0.1:8080 only. On a server, reach it through an SSH tunnel:
ssh -L 8080:127.0.0.1:8080 user@your-server
Open http://127.0.0.1:8080 and finish first-run setup, which creates the owner account and names your organisation and first workspace. From then on every page asks for a sign-in.
First steps
- Scope: declare your domains.
- Scans: run discovery, or the express run, which does the first pass in one go. The express run approves the addresses that show no sign of shared infrastructure (a CDN, WAF or cloud range, or a third party's reverse name) and leaves the rest for you; Approvals lists what it approved.
- Scope > Approvals: approve the addresses that are yours.
- Scans: run the internet-facing scan, then read Findings and the fix plan.
- Compliance > Which rules apply: classify the organisation, then apply a package under Programme.
The console's Getting started page, in the account menu, walks through every part in order, and the demo workspace shows each one with three months of sample data.
Publish the console
To reach the console over the internet with HTTPS, point a hostname at the server and start it with the bundled Caddy configuration, which fetches the certificate:
MERIDIAN_DOMAIN=console.yourcompany.com docker compose -f docker-compose.yml -f docker-compose.public.yml up -d --build
Publishing switches active scanning off, because many hosting providers forbid scanning from their servers. Where your provider allows it, change MERIDIAN_SCAN_DISABLED to "0" in docker-compose.public.yml. Until the first account exists, only a health check is served. Make the owner account inside the container:
docker compose exec meridian node src/cli.ts user add <name> --role owner
Every request then needs a sign-in. Two-step verification, password rules and single sign-on through OpenID Connect are set under Admin.
The hosted console
The hosted console runs your security programme from day one: compliance assessments, registers, policies, incident deadlines, email and DNS checks, repository checks and imported scan results. It keeps active scanning switched off, so it sends no scan to your servers. Your Tenable, Qualys or Defender findings are ranked here with a fix plan. For Vardion's own port and vulnerability scans, run the whole console on your own server, so scans leave from an address you control.
First steps on the hosted console
- Compliance > Which rules apply: classify the organisation, then apply a package under Programme.
- Compliance > Assessments: start the ΕΑΚ gap analysis, the ΕΑΚ self-assessment or a maturity assessment, and hand each section to the colleague who answers it.
- Scope: declare your domains. Discovery and the email and DNS checks run without scanning.
- Findings > Imported: connect Tenable, Qualys or Microsoft Defender, or import a Nessus, OpenVAS or Burp file, so its findings join the ranked list.
How scanning works
- Discovery finds the names under your domains and the addresses they resolve to. Each new address waits in Approvals until you decide it.
- An address is scanned only after it is approved, or when it sits in a range or cloud account you declared as yours. Private addresses are never part of an internet-facing scan.
- The default depth is the high-risk service ports. A full scan can also cover the 100 or 1,000 most common ports or every port, and the console states the time each one takes on your estate.
- Scans leave out denial-of-service, intrusive and fuzzing checks. A scan window keeps unattended scans to the hours you choose.
- Email security, DNS, domain expiry, lookalike domains and leaked credentials are checked without scanning anything.
- An internal network is checked only when you declare its range, with a gentler profile and its own score.
Scan profile
| Setting | Default |
|---|---|
| Port scan (naabu) | Connect scan at 133 probes a second across the scan, 1.2 second timeout, 3 attempts per port, about 160 connections open at once |
| Port depth | 39 high-risk service ports; the 100 or 1,000 most common ports or every port on request |
| Vulnerability checks (nuclei) | At most 50 requests a second to any one host, lower for hosts you name; up to 25 hosts are checked side by side; templates tagged dos, intrusive or fuzz never run in monitoring scans |
| Web scan (OWASP ZAP, optional) | Passive only: a crawl capped in depth, duration and threads that submits no forms; the active scanner is never called |
| Industrial control ports | Recognised from the port scan and sent no further probe |
| User-Agent | Vardion-ASM/1.0 (internal attack-surface monitor) by default, on every web request |
Connect your tools
- Alerts: Slack, Microsoft Teams or any webhook, under Settings > Notifications.
- Tickets: Jira Cloud or GitHub issues opened from a finding or by a rule, under Settings > Integrations. Status and assignee sync back, and a finding closes only when a scan confirms the fix.
- SIEM: new, returning and fixed findings after each run, as JSON lines, Splunk HEC, CEF or Wazuh events, set per workspace so each client's events reach its own collector. Wazuh comes with a rules file that sets alert levels by severity and known exploitation. Findings also export as STIX 2.1 for OpenCTI and MISP.
- Cloud and identity: AWS, Azure, Google Cloud, Cloudflare, Microsoft 365 and Google Workspace, read with read-only credentials.
- Repositories: JavaScript and Python dependencies in GitHub or GitLab under Assets > Repositories, once the npm and PyPI tables are switched on under Reference data. A GitHub fine-grained token with read access to Contents and Metadata, or a GitLab token with the read_api scope.
- Scanners you already run: Tenable, Qualys and Microsoft Defender accounts, or Nessus, OpenVAS, Burp and a tester's CSV, under Findings > Imported.
- Sign-in: OpenID Connect and SCIM 2.0.
Software inventory
Agents for Linux, Docker and Windows report each host's operating system and packages once a day, and Vardion matches them against OSV and NVD. Create an enrolment token under Settings > Enrolment tokens, open the inventory listener to your hosts (docker-compose.ingest.yml, with TLS) and install the agent with the token. Linux and Docker packages are matched against OSV, and common Windows software against NVD. A software bill of materials in CycloneDX or SPDX can be imported under Assets > Inventory. Hosts a Wazuh manager already watches need no Vardion agent: their packages are read from the manager.
API
A read-only REST API answers at /api/v1 with a bearer token made under your account. Add ?workspace=<id> to read one workspace, and limit and offset to page through up to 5,000 rows a request. A token reads only the workspaces its account can open, and never writes.
| Endpoint | Returns |
|---|---|
/api/v1/findings | Findings, with the same filters as the console |
/api/v1/findings/{id} | One finding |
/api/v1/assets | Hosts and services |
/api/v1/approvals | Addresses and their decisions |
/api/v1/runs | Runs and their outcomes |
/api/v1/score | The risk score of each surface |
curl -H "Authorization: Bearer $TOKEN" https://console.yourcompany.com/api/v1/findings
Command line
Every command runs inside the container and acts on one workspace, the first unless --workspace <id> names another.
docker compose exec meridian node src/cli.ts run-now --dry-run
| Command | What it does |
|---|---|
run-now [--discovery | --quick | --express] | Starts a run |
passive | Runs the checks that scan nothing |
approve-ip, reject-ip | Decides an address |
list, report | Prints findings or the report |
user add <name> --role owner | Makes an account |
backup, restore | Saves or restores the configuration and data |
build | Prints the fingerprint of the code that is running |
Backup and updates
State lives on mounted volumes, so recreating the container keeps everything. One command writes the configuration and data as a single archive, with credentials only when you ask for them:
docker compose exec meridian node src/cli.ts backup --out vardion-backup.tar.gz
To update, run sh scripts/deploy.sh in the Vardion folder on the server: it rebuilds the image and restarts the console, and needs only Docker. On a published console, first put MERIDIAN_COMPOSE_EXTRA=docker-compose.public.yml in .deploy.env, so the update keeps the published settings. npm run tools:update, which needs Node 26, moves the scanners to their newest releases, and the console says when one is available.
Support
Write to support@getvardion.com. The security page sets out how Vardion is deployed and every outbound connection it makes.