Voraussetzungen¶
Empfohlenes Setup
Ein frisches Debian 13 in einer eigenen VM nur für Vesana. Das ist eine reine Empfehlung: Vesana läuft genauso auf Ubuntu oder RHEL und auch neben anderen Diensten auf demselben Server — eine eigene, frische VM macht Updates, Backups und die Fehlersuche nur einfacher, weil nichts anderes an Docker, Ports 80/443 oder dem RAM hängt.
Hardware¶
| Was | Minimum | Empfohlen | Mit AI (Ollama lokal) |
|---|---|---|---|
| Betriebssystem | Linux (Debian 12+, Ubuntu 22.04+, RHEL 9+) | Debian 13 | Debian 13 |
| Architektur | amd64 | amd64 | amd64 + NVIDIA-GPU optional |
| RAM | 1 GB | 2 GB; 4 GB ab ~50 Hosts | + 4–48 GB je nach Modell |
| CPU | 1 Core | 2 Cores ab ~50 Hosts | 4+ Cores |
| Disk | 10 GB | 50 GB SSD (für Log-Retention) | + 20 GB für Modelle |
Faustregel
Kleine Umgebungen (ein paar Dutzend Hosts) laufen gut mit 1 GB RAM. Pro 100 zusätzliche Hosts kommen grob +500 MB dazu, plus irgendwann ein zusätzlicher CPU-Core. Logs und lange Retention-Zeiten erhöhen vor allem den Disk-Bedarf.
Unter 1 GB RAM
1 GB ist das Minimum. Darunter beginnt der Server zu swappen — Vesana läuft dann zwar oft noch, aber sichtbar langsamer und mit gelegentlichen Timeouts unter Last.
Die vier Sizing-Profile im Setup-Wizard (Klein/Mittel/Groß/XL) helfen dir bei der Wahl der passenden Worker-/Datenbank-Konfiguration, sobald die Instanz läuft: siehe Ressourcen → Leistung.
Software¶
- Docker Engine ≥ 24.0
- Docker Compose ≥ 2.20 (V2, eingebaut)
- openssl und curl (vom Setup-Script automatisch installiert auf Debian/Ubuntu/RHEL/AlmaLinux/SUSE/Arch)
Prüfen:
Falls Docker fehlt — das Setup-Script installiert es automatisch über get.docker.com. Manuell:
Netzwerk¶
Eingehend zum Vesana-Server¶
| Port | Wofür | Quelle |
|---|---|---|
| 80 (TCP) | HTTP → leitet auf 443 um | Internet / LAN |
| 443 (TCP) | Frontend, API, Receiver, Agent-Config | Agents, Collectors, Browser, Mobile |
| 5667 (TCP) | NSCA-Empfänger | nur falls NSCA-Migrations-Modus aktiv |
Ausgehend vom Vesana-Server¶
| Ziel | Wofür | Pflicht |
|---|---|---|
Docker-Registry (ghcr.io) |
Image-Pull bei Installation und Update | Pflicht |
license.vesana.org |
Update-Check, Install-File-Distribution, Feedback | Empfohlen |
fcm.googleapis.com, updates.push.services.mozilla.com, *.push.apple.com |
Push-Meldungen an Geräte zustellen (der Push-Dienst des jeweiligen Browsers) | Optional (nur wenn Push genutzt wird) |
api.anthropic.com |
AI-Provider Anthropic | Optional |
| SMTP-Server | E-Mail-Benachrichtigungen | Optional |
| NTP-Pool | Zeitsync (Lizenz-Validierung braucht korrekte Uhr) | Pflicht |
DNS¶
Eine Domain mit DNS-Eintrag auf den Server ist empfohlen, schon damit Agents/Collectors und Browser eine stabile Adresse haben. Ein öffentlich vertrauenswürdiges Zertifikat (z. B. Let's Encrypt) stellt Vesana nicht automatisch selbst aus — beim ersten Start generiert der Server stattdessen automatisch ein selbstsigniertes Zertifikat, damit sofort über HTTPS gearbeitet werden kann. Der Browser zeigt dafür eine Warnung, der Agent-Installer braucht --insecure. Ein eigenes Zertifikat lässt sich jederzeit nachträglich einspielen: siehe Self-Hosting → SSL/TLS.
Was Vesana NICHT braucht¶
- Kein Inbound-Port auf den überwachten Maschinen — der Datenstrom ist outbound HTTPS 443 vom Agent/Collector zum Server.
- Kein VPN zwischen Server und Kundennetz — der Collector läuft im Kundennetz und phone-homed selbst.
- Keine externe Datenbank — Postgres + Redis laufen im Compose-Stack.
- Keine Monitoring-Daten nach außen — Messwerte, Geräte- und Mandantennamen, Check-Konfigurationen und Logs verlassen die Instanz nie. Nach außen gehen nur der Update-Check und der tägliche Instanz-Puls gegen
license.vesana.org(abschaltbar).
Anschluss¶
Wenn die Voraussetzungen passen, weiter mit der Installation.