Wer ohnehin einen Proxmox-Host im Serverschrank stehen hat, denkt beim Thema UniFi-Controller schnell: „Das ist doch nur noch eine VM mehr.“ Technisch stimmt das – Ubiquiti nennt virtuelle Maschinen ausdrücklich als mögliche Plattform für den UniFi OS Server. Praktisch entscheiden aber ein paar Details darüber, ob die Installation jahrelang unauffällig läuft oder dich regelmäßig Zeit kostet: die Netzwerkanbindung der VM, der Umgang mit Snapshots und Klonen – und die Frage, wer nachts wach ist, wenn der Host steht. Dieser Ratgeber zeigt dir den dokumentierten Weg zum UniFi OS Server unter Proxmox und benennt die Grenzen ehrlich.
Was Ubiquiti zur Virtualisierung tatsächlich sagt
Der UniFi OS Server ist die aktuelle Software zum Selbst-Hosten und löst den älteren UniFi Network Server ab. Ubiquiti beschreibt ihn als Lösung, die sich auf x86-, x64- und ARM64-Servern, in virtuellen Maschinen oder auf Edge-Appliances betreiben lässt – CPU, Arbeitsspeicher und Storage wählst du passend zur Last, und für Hochverfügbarkeit lassen sich Virtualisierungs-Cluster nutzen. Virtualisierung ist also kein Graubereich, sondern ein vorgesehener Weg.
Wichtig für die Erwartungshaltung: Ubiquiti dokumentiert die Installation pro Betriebssystem, nicht pro Hypervisor. Es gibt keine offizielle Proxmox-Anleitung und kein fertiges Proxmox-Image von Ubiquiti. Du installierst also ein unterstütztes Linux in einer VM und darin den UniFi OS Server – alles, was Proxmox selbst betrifft, liegt in deiner Verantwortung.
Anforderungen an die VM
Die Mindestanforderungen des UniFi OS Server sind überschaubar. Für eine Proxmox-VM übersetzt heißt das:
| Ressource | Vorgabe von Ubiquiti | Umsetzung in Proxmox |
|---|---|---|
| CPU | x86-64-Prozessor (ARM64 wird ebenfalls unterstützt) | 2 vCPU als praxistauglicher Startwert |
| Arbeitsspeicher | mindestens 2 GB | fest zuweisen statt Ballooning bis an die Untergrenze |
| Speicherplatz | mindestens 10 GB frei | großzügiger planen – Logs und Statistiken wachsen mit |
| Netzwerk | kabelgebundenes Ethernet, 100 Mbit/s | virtio-NIC an einer Linux-Bridge |
| Betriebssystem | Ubuntu ab 24.04, Debian ab 13 oder eine vergleichbare moderne Distribution | schlanke Server-Installation ohne Desktop |
Ubiquiti weist ausdrücklich darauf hin, dass die Ausstattung mitwachsen muss, je mehr Geräte du adoptierst und verwaltest. Nimm die Mindestwerte also als Untergrenze, nicht als Zielgröße – der Vorteil einer VM ist ja gerade, dass du RAM und Disk später nachziehen kannst.
Installation Schritt für Schritt
- VM anlegen: Debian 13 oder Ubuntu 24.04 als Server-Installation, Netzwerkkarte auf
virtio, Bridgevmbr0(mehr dazu gleich). Feste IP oder DHCP-Reservierung vergeben – die Adresse taucht später in Adoption und Firewallregeln auf. - Abhängigkeiten installieren: Der UniFi OS Server setzt Podman und slirp4netns (Version 1.2 oder neuer) voraus:
sudo apt-get update && sudo apt-get install podman slirp4netns - Installer holen: Den Download-Link für deine Architektur auf der offiziellen Ubiquiti-Downloadseite bzw. im Release-Bereich kopieren und die Datei per
curloderwgetin die VM laden. - Ausführbar machen und starten:
chmod +x <installer>sudo ./<installer> - Ersteinrichtung im Browser: Konsole aufrufen, Konto anlegen, Netzwerkanwendung einrichten, danach die Geräte adoptieren.
Plane für die VM zusätzlich, was Proxmox nicht mitliefert: automatische Sicherheitsupdates im Gast, eine verlässliche Zeitsynchronisation und ein Monitoring, das dir meldet, wenn der Dienst nicht mehr antwortet.
Netzwerk: Bridge statt NAT
Das ist der Punkt, an dem virtualisierte Controller am häufigsten scheitern. UniFi-Geräte werden im Normalfall über Layer-2-Discovery gefunden – Controller und Geräte müssen also in derselben Broadcast-Domäne liegen. Hängt die VM hinter einer NAT-Bridge oder in einem eigenen, geroutet angebundenen Netz, sehen deine Access Points den Controller schlicht nicht.
Der saubere Weg: die VM per Linux-Bridge direkt ins Management-VLAN legen, in dem auch die UniFi-Geräte stehen. Arbeitet dein Proxmox-Host mit VLAN-Tags, gibst du das passende VLAN-Tag am virtuellen Netzwerkadapter mit.
Muss der Controller aus einem anderen Subnetz erreichbar sein, greift die Layer-3-Adoption: per SSH auf dem Gerät mit set-inform http://<ip-des-hosts>:8080/inform, über DHCP-Option 43 mit der IP des Controllers oder – bei unterstützten Modellen – per Zero-Touch-Provisioning. Wie das im Detail abläuft, steht im Ratgeber zur Layer-3-Adoption von UniFi Access Points.
Ports, die offen sein müssen
Für Discovery, Adoption und Gastportal müssen auf dem Gast lokal TCP 8080, TCP 8843, UDP 3478 und UDP 10001 erreichbar sein – in der Firewall der VM und, falls du die Proxmox-Firewall nutzt, auch dort. Diese Ports gehören ins lokale Netz, nicht ins Internet.
Für die Fernverwaltung über den UniFi Site Manager braucht die VM ausgehende Verbindungen auf TCP 443 und TCP 8883. Eingehende Portfreigaben sind dafür nicht nötig. Blockiert eine Firewall oder das Gerät des Providers diesen ausgehenden Weg, erreicht der Site Manager die selbst gehostete Instanz nicht.
Die Grenzen – vier Punkte, die du kennen solltest
1. VMs mit UniFi OS Server nicht klonen
Das ist die wichtigste Proxmox-spezifische Stolperfalle, weil Klonen und Templates dort zum Alltag gehören. Ubiquiti weist ausdrücklich darauf hin, dass VMs mit UniFi OS Server nicht geklont werden sollen – außer für Hochverfügbarkeits- oder Failover-Installationen. Der Grund: Geklonte VMs verwenden dieselben Remote-Access-Token für Site Manager und Fabrics, was zu unerwartetem Verhalten führt. Brauchst du eine zweite Instanz, richte sie neu ein, statt eine bestehende zu duplizieren.
Ein Template für die reine Betriebssystem-Basis vor der UniFi-Installation ist davon nicht betroffen – klone also höchstens den leeren Gast, nie den fertig eingerichteten Controller.
2. Snapshots sind kein Backup-Ersatz
Ein Proxmox-Snapshot sichert einen Maschinenzustand auf demselben Host und hilft beim Zurückrollen eines missglückten Updates. Gegen einen Ausfall des Hosts oder des Storages schützt er nicht. Ubiquiti sieht dafür eigene System-Backups vor, die du unter Settings > Control Plane > Backups aktivierst und von dort auch wieder einspielst; automatisierte Sicherungen werden wöchentlich und vor größeren Updates erzeugt. Nutze beides – und lege die Sicherung an einen Ort, der nicht mit dem Host stirbt. Details dazu im Ratgeber zu Backup und Wiederherstellung.
3. Der Controller muss durchgehend laufen
Ubiquiti formuliert das unmissverständlich: Um adoptierte Geräte sehen und verwalten zu können, muss der UniFi OS Server dauerhaft laufen. Geht er offline, arbeiten die Geräte mit ihrer letzten Konfiguration weiter – Verwaltung, Statistiken und Änderungen sind aber weg. Wer keinen Dauerbetrieb sicherstellen kann, dem empfiehlt Ubiquiti selbst einen Cloud Key oder gehostetes UniFi als Alternative.
Für Proxmox heißt das: Der Controller erbt jedes Risiko des Hosts – Wartungsfenster, Stromausfall am Standort, ausgefallene Internetleitung. Ein Cluster mit Hochverfügbarkeit entschärft das, kostet aber wieder Hardware und Pflege.
4. Support endet an der VM-Grenze
Ubiquiti dokumentiert den UniFi OS Server für die genannten Betriebssysteme. Alles darunter – Hypervisor, Bridge, Storage, Backup-Kette, Host-Updates – ist Proxmox-Terrain und damit deins. Bei einem Problem musst du zuerst selbst einordnen, ob es an UniFi oder an der Plattform liegt. Wie sich dieser Aufwand über drei Jahre summiert, rechnet der Ratgeber zu den echten Kosten des Self-Hostings durch.
Wann Proxmox die richtige Wahl ist – und wann nicht
| Spricht für Proxmox | Spricht dagegen |
|---|---|
| Host läuft ohnehin rund um die Uhr und wird bereits gepflegt | Der Host ist ein Bastelsystem, das auch mal aus ist |
| Virtualisierungs-Know-how und Monitoring sind im Haus vorhanden | Netzwerk wird nebenbei betreut, ohne feste Zuständigkeit |
| Daten sollen bewusst on-premises bleiben | Standort hat keine verlässliche Strom- und Internetversorgung |
| Controller und UniFi-Geräte liegen im selben Netz | Mehrere Standorte ohne zentralen, dauerhaft erreichbaren Ort |
| Backup- und Restore-Prozess ist bereits etabliert und getestet | Niemand will nachts Rufbereitschaft für den Controller haben |
Fazit
Der UniFi OS Server läuft in einer Proxmox-VM gut – vorausgesetzt, du legst sie per Bridge ins richtige Netz, hältst die Ports offen, klonst die fertige Instanz nicht und behandelst Snapshots als Ergänzung, nicht als Backup. Was Proxmox dir nicht abnimmt, ist der Dauerbetrieb: Host-Updates, Monitoring, Restore-Tests und die Frage, wer reagiert, wenn am Sonntagabend niemand mehr auf die Konsole kommt.
Wenn du die Kontrolle über die Konfiguration behalten, den Betrieb aber abgeben willst: Wir hosten deinen UniFi Controller in der Cloud – in einem deutschen Rechenzentrum, DSGVO-konform, mit Updates, Backups und Monitoring im Preis. Sprich uns an, wenn du wissen willst, ob sich der Umzug für dein Netz lohnt.
Häufige Fragen
Unterstützt Ubiquiti den Betrieb in einer VM offiziell?
Ja. Ubiquiti nennt virtuelle Maschinen ausdrücklich als Plattform für den UniFi OS Server, neben x86-, x64- und ARM64-Servern sowie Edge-Appliances. Dokumentiert wird die Installation allerdings pro Betriebssystem, nicht pro Hypervisor – eine eigene Proxmox-Anleitung von Ubiquiti gibt es nicht.
Warum finden meine Access Points den Controller in der VM nicht?
Meistens liegt es am Netzwerkmodus der VM. Die Standard-Adoption läuft über Layer-2-Discovery und setzt voraus, dass Controller und Geräte in derselben Broadcast-Domäne liegen. Häng die VM per Bridge ins Management-VLAN – oder nutze die Layer-3-Adoption per set-inform, DHCP-Option 43 oder Zero-Touch-Provisioning.
Darf ich die VM als Vorlage für weitere Installationen klonen?
Nein – laut Ubiquiti sollen VMs mit UniFi OS Server nicht geklont werden, außer für Hochverfügbarkeits- oder Failover-Installationen. Geklonte VMs nutzen dieselben Remote-Access-Token für Site Manager und Fabrics, was zu unerwartetem Verhalten führt. Richte weitere Instanzen neu ein.
Reicht ein Proxmox-Snapshot als Sicherung?
Als alleinige Sicherung nicht. Ein Snapshot liegt beim Host und ist wertlos, wenn Host oder Storage ausfallen. Aktiviere zusätzlich die System-Backups unter Settings > Control Plane > Backups und bewahre sie an einem zweiten Ort auf.
Wie viele Ressourcen braucht die VM wirklich?
Die dokumentierte Untergrenze sind ein x86-64-Prozessor, 2 GB RAM, 10 GB freier Speicher und eine kabelgebundene 100-Mbit/s-Anbindung. Ubiquiti weist darauf hin, dass die Ausstattung mit der Zahl der verwalteten Geräte wachsen muss – plane RAM und Storage also von Anfang an mit Luft nach oben.