Prerequisites¶
Recommended setup
A fresh Debian 13 in a dedicated VM just for Vesana. This is a recommendation only: Vesana runs just as well on Ubuntu or RHEL and alongside other services on the same server — a dedicated, fresh VM simply makes updates, backups and troubleshooting easier because nothing else competes for Docker, ports 80/443 or RAM.
Hardware¶
| What | Minimum | Recommended | With AI (local Ollama) |
|---|---|---|---|
| Operating system | Linux (Debian 12+, Ubuntu 22.04+, RHEL 9+) | Debian 13 | Debian 13 |
| Architecture | amd64 | amd64 | amd64 + optional NVIDIA GPU |
| RAM | 1 GB | 2 GB; 4 GB at ~50 hosts | + 4–48 GB depending on model |
| CPU | 1 core | 2 cores at ~50 hosts | 4+ cores |
| Disk | 10 GB | 50 GB SSD (for log retention) | + 20 GB for models |
Rule of thumb
Small environments (a few dozen hosts) run well on 1 GB RAM. About +500 MB per 100 additional hosts, and eventually an extra CPU core. Logs and long retention windows mostly drive disk usage.
Under 1 GB RAM
1 GB is the minimum. Below that the server starts swapping — Vesana often still runs, but noticeably slower and with occasional timeouts under load.
The setup wizard's four sizing profiles (Small/Medium/Large/XL) help you pick the right worker/database configuration once the instance is running: see Resources → Performance.
Software¶
- Docker Engine ≥ 24.0
- Docker Compose ≥ 2.20 (V2, built in)
- openssl and curl (auto-installed by setup script on Debian/Ubuntu/RHEL/AlmaLinux/SUSE/Arch)
Check:
If Docker is missing — the setup script installs it via get.docker.com. Manually:
Network¶
Inbound to the Vesana server¶
| Port | Purpose | Source |
|---|---|---|
| 80 (TCP) | HTTP → redirect to 443 | Internet / LAN |
| 443 (TCP) | Frontend, API, receiver, agent config | Agents, collectors, browsers, mobile |
| 5667 (TCP) | NSCA receiver | only if NSCA migration mode is on |
Outbound from the Vesana server¶
| Target | Purpose | Required |
|---|---|---|
Docker registry (ghcr.io) |
Image pull on install and update | Yes |
license.vesana.org |
Update check, install file distribution, feedback | Recommended |
fcm.googleapis.com, updates.push.services.mozilla.com, *.push.apple.com |
Deliver push messages to devices (each browser's own push service) | Optional (only when push is used) |
api.anthropic.com |
AI provider Anthropic | Optional |
| SMTP server | Email notifications | Optional |
| NTP pool | Time sync (license validation needs correct clock) | Required |
DNS¶
A domain pointing to the server is recommended, if only so agents/collectors and browsers have a stable address. Vesana does not automatically issue a publicly trusted certificate (e.g. Let's Encrypt) for you — on first start it generates a self-signed certificate automatically so it can serve HTTPS right away. Your browser will warn about that, and the agent installer needs --insecure. You can install your own certificate at any time afterwards: see Self-hosting → SSL/TLS.
What Vesana does NOT need¶
- No inbound port on monitored machines — the data stream is outbound HTTPS 443 from agent/collector to server.
- No VPN between server and customer network — the collector lives in the customer network and phones home.
- No external database — Postgres + Redis run inside the compose stack.
- No monitoring data leaves the instance — measurements, device and tenant names, check configurations and logs never go outbound. What does go out is the update check and the daily instance pulse against
license.vesana.org(can be switched off).
Next¶
If prerequisites check out, continue with the installation.