UniFi Controller auf einem VPS betreiben

Was ein UniFi-Controller auf einem VPS tatsächlich macht

Ein UniFi-Controller auf einem VPS ist ein zentraler Verwaltungsserver, der erreichbar bleibt, wenn die von ihm verwalteten Standorte ausfallen. Die Software ist Ubiquitis UniFi Network Application: ein Java-Programm mit einer MongoDB-Datenbank im Hintergrund. Sie konfiguriert Ihre Access Points und Switches, speichert deren Statistiken und stellt die Administrationsoberfläche bereit. Client-Datenverkehr wird nicht über den Controller geleitet.

Dieser letzte Punkt bestimmt, wo der Controller betrieben werden sollte. Wenn Sie den Controller auf einem Rechner innerhalb des von ihm verwalteten Büros betreiben, verlieren Sie im selben Moment sowohl das Netzwerk als auch das Werkzeug zur Überwachung dieses Netzwerks. Auf einem VPS mit stabiler öffentlicher Adresse bleibt der Controller hingegen aktiv, sammelt weiterhin Daten und kann Geräte an mehreren Standorten von einer Stelle aus adoptieren. Entscheidend ist Verfügbarkeit, nicht Rechenleistung.

Wenn der Controller offline ist, leiten adoptierte Access Points und Switches den Datenverkehr weiterhin mit der bereits auf sie übertragenen Konfiguration weiter. Sie verlieren das Dashboard und die Statistiken sowie alle Funktionen, die einen aktiven Controller benötigen: beispielsweise die Anmeldung über ein Gästeportal oder RADIUS (Remote Authentication Dial-In User Service), wenn der Controller als RADIUS-Server dient. Die Clients bleiben verbunden.

Wie viel RAM benötigt ein UniFi-Controller?

2 GB sind das Minimum, 4 GB sind die passende Größe. In einem System gibt es zwei Speicherverbraucher: Java und MongoDB. Beide dimensionieren ihren Speicher unabhängig voneinander.

Der Java-Heap wird durch MEM_LIMIT begrenzt. Das Container-Image setzt diesen Wert standardmäßig auf 1024 MB. MongoDB ist der zweite große Verbraucher. Die WiredTiger-Storage-Engine dimensioniert ihren Cache auf die Hälfte des RAM oberhalb von 1 GB oder auf 256 MB, je nachdem, welcher Wert größer ist. Auf einem VPS mit 2 GB sind das ungefähr 512 MB Cache, 1 GB Heap, der eigene Non-Heap-Speicher der JVM und der Speicherbedarf des Betriebssystems. Das reicht bis zu einem stark ausgelasteten Tag. Dann beendet der Out-of-Memory-Killer des Kernels einen der beiden Prozesse. Nach jedem unerklärlichen Neustart können Sie mit dmesg -T | grep -i 'killed process' prüfen, ob das passiert ist. Wenn nur 2 GB verfügbar sind, legen Sie eine Swap-Datei an.

CPU und Speicherplatz stellen geringe Anforderungen. Eine oder zwei vCPU reichen für einige Dutzend Geräte. Beginnen Sie mit 20 GB Speicherplatz und überwachen Sie die Belegung. Die Datenbank wächst mit der Anzahl der erkannten Clients und mit der Dauer der Statistikaufbewahrung. Ein allein betriebener Controller lässt den größten Teil eines Systems mit 4 GB ungenutzt. Wenn Sie einen weiteren Dienst auf demselben System betreiben möchten, dimensionieren Sie zuerst für diesen Dienst. PhotoPrism und Immich haben sehr unterschiedliche RAM-Mindestanforderungen, und beide benötigen mehr RAM als der Controller.

Eine CPU-Funktion ist relevant und wird bei günstigen Tarifen leicht übersehen:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 und höher benötigt AVX (Advanced Vector Extensions) auf x86_64-Hardware. Wenn dieser Befehl keine Ausgabe erzeugt, beendet sich mongod während des Starts und der Container wird in einer Schleife neu gestartet. Der Grund ist, dass die Binärdatei eine Instruktion ausführt, die die CPU nicht unterstützt. Ältere Intel-Celeron- und Pentium-Hosts sind eine häufige Ursache. Dasselbe gilt für Hypervisoren, die CPU-Flags gegenüber dem Gast ausblenden. MongoDB 4.4 benötigt AVX nicht und ist der einzige Fallback. Für diese Datenbankversion veröffentlicht der Upstream jedoch keine Patches mehr. Der Wechsel auf einen Host mit einer neueren CPU ist die bessere Lösung. Auf einem ARM-VPS stellt sich diese Frage nicht, weil AVX ein x86-Instruktionssatz ist und beide Images arm64-Builds veröffentlichen. Wenn Sie zwischen beiden Optionen wählen, gehen die Unterschiede zwischen ARM- und x86-VPS-Tarifen über den Preis hinaus.

Installieren der UniFi Network Application mit Docker Compose

Docker verursacht die wenigsten Überraschungen, weil Sie damit MongoDB auf eine von der Anwendung unterstützte Version festlegen können, statt die von Ihrer Distribution bereitgestellte Version zu übernehmen. Wenn Docker auf dem System noch nicht installiert ist, installieren Sie zuerst Docker auf einem VPS.

mkdir -p ~/unifi/config ~/unifi/db
cd ~/unifi

MongoDB benötigt einen Benutzer, bevor sich die Anwendung anmelden kann. Das offizielle MongoDB-Image führt beim ersten Start jedes Skript aus, das es in /docker-entrypoint-initdb.d findet. Speichern Sie Folgendes als ~/unifi/init-mongo.sh:

#!/bin/bash
if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    "clusterMonitor",
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_restore", role: "dbOwner" }
  ]
})
EOF

Dieses Skript wird nur ausgeführt, wenn das Datenbankverzeichnis leer ist. Starten Sie den Stack einmal mit dem falschen Passwort, wird der Benutzer mit diesem falschen Passwort angelegt. Eine spätere Änderung der Compose-Datei ändert daran nichts, weil das Skript nicht erneut ausgeführt wird. Das Symptom besteht darin, dass der Anwendungscontainer MongoDB-Authentifizierungsfehler protokolliert, während die Weboberfläche nicht erscheint. Bei einer neuen Installation besteht die Lösung darin, den Stack zu stoppen, ~/unifi/db zu löschen und ihn anschließend erneut zu starten.

Schreiben Sie anschließend ~/unifi/compose.yaml:

services:
  unifi-db:
    image: docker.io/mongo:8.0
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-this-root-password
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - ./db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls141
    container_name: unifi-network-application
    depends_on:
      - unifi-db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - ./config:/config
    ports:
      - "8080:8080"
      - "3478:3478/udp"
      - "127.0.0.1:8443:8443"
    restart: unless-stopped

Beide Image-Tags sind absichtlich festgelegt. 10.5.67-ls141 war im August 2026 die aktuelle Anwendungsfreigabe. Prüfen Sie daher die Liste der Image-Releases und legen Sie bei der Installation die dann aktuelle Version fest. Der Datenbank-Tag ist noch wichtiger. MongoDB aktualisiert seine Datendateien nicht selbstständig über Hauptversionen hinweg. Deshalb wird mongo:latest eines Tages eine neue Hauptversion abrufen, das vorgefundene Datenformat nicht öffnen können und in einer Neustartschleife laufen. Legen Sie die Hauptversion fest und führen Sie das Upgrade bewusst durch. UniFi Network 8.1 und höher unterstützen MongoDB 3.6 bis 7.0. Mit 9.0 wurde die Unterstützung für MongoDB 8.0 hinzugefügt.

PUID und PGID müssen einem realen Benutzer auf dem Host entsprechen. Andernfalls gehören die Dateien unter ./config einer Identität, die nicht in sie schreiben kann. Führen Sie id aus, um Ihre Werte zu ermitteln. Wie PUID und PGID in Container-Images funktionieren erklärt, wie sich eine falsche Zuordnung auswirkt.

Starten Sie den Stack und überwachen Sie die Ausgabe:

docker compose up -d
docker compose ps
docker compose logs -f unifi-network-application

docker compose ps sollte beide Container als running anzeigen. Ein unifi-db, der in restarting feststeckt, weist entweder auf das oben beschriebene AVX-Problem oder auf ein Berechtigungsproblem bei ./db hin. Sobald sich das Log stabilisiert hat, prüfen Sie die beiden Listener:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8443/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/inform

Jeder HTTP-Statuscode bedeutet, dass der Listener gebunden ist und antwortet. Connection refused bedeutet, dass die Anwendung noch startet. Das dauert beim ersten Start auf einem kleinen VPS ein bis zwei Minuten. Es kann auch bedeuten, dass die Anwendung überhaupt nicht gestartet wurde.

Zugriff auf die Administrationsoberfläche ohne öffentliche Freigabe

Port 8443 wird in der obigen Datei auf 127.0.0.1 veröffentlicht. Daher kann nichts außerhalb der VPS die Administrationsoberfläche erreichen. Leiten Sie den Port über SSH weiter, um den Einrichtungsassistenten auszuführen:

ssh -L 8443:127.0.0.1:8443 you@vps.example.com

Lassen Sie diese Sitzung geöffnet und rufen Sie https://127.0.0.1:8443 auf. Das Zertifikat ist selbst signiert, daher zeigt der Browser einmalig eine Warnung an. Erstellen Sie das Administratorkonto, benennen Sie die Site und überspringen Sie die Geräteaufnahme zunächst.

Ein SSH-Tunnel reicht für einen einzelnen Administrator aus. Für ein Team geben Sie der VPS eine private Adresse und binden Sie die Oberfläche stattdessen an diese Adresse. Ein WireGuard-VPN auf Ihrer eigenen VPS und ein Tailscale-Subnetzrouter stellen jeweils eine Adresse bereit, die nur Ihre Benutzer routen können. Ändern Sie den veröffentlichten Port für WireGuard in 10.8.0.1:8443:8443 oder verwenden Sie die von Tailscale zugewiesene Adresse. Es gibt eine Einschränkung: Docker kann keinen Port an eine Adresse veröffentlichen, die noch nicht existiert. Daher muss die Tunnel-Schnittstelle gestartet sein, bevor der Container startet. Andernfalls schlägt der Container mit einem Bind-Fehler fehl.

Warum ein entferntes UniFi-Gerät nicht adoptiert wird

Standardmäßig findet ein UniFi-Gerät seinen Controller über einen Broadcast im lokalen Netzwerk auf UDP-Port 10001. Ein Broadcast verlässt das LAN nicht. Ein Gerät in einem Büro in einer anderen Stadt findet einen Controller auf einem VPS daher niemals auf diesem Weg. Das ist eine Layer-3-Adoption. An dieser Stelle bleiben die meisten Benutzer stecken. Das Gerät ist funktionsfähig, und der Controller ist ebenfalls funktionsfähig. Dem Gerät wurde lediglich nicht mitgeteilt, wo es suchen soll.

Teilen Sie dem Controller zuerst mit, welche Adresse er verteilen soll. In den Einstellungen des Controllers gibt es im Bereich System eine Einstellung für den Inform-Host mit einer Überschreibungsoption. Setzen Sie sie auf den öffentlichen Hostnamen oder die öffentliche IP-Adresse Ihres VPS. Ohne diese Einstellung gibt der Controller die Adresse aus, die er an seiner eigenen Schnittstelle sieht. In einem Docker-Bridge-Netzwerk ist das eine private Adresse wie 172.18.0.3. Das Gerät empfängt diese Adresse, kann sie nicht routen und beginnt erneut mit der Suche.

Verweisen Sie das Gerät anschließend auf diese Adresse. Stellen Sie per SSH eine Verbindung zum Gerät im entfernten LAN her. Ein Gerät mit Werkseinstellungen akzeptiert den Benutzernamen ubnt mit dem Passwort ubnt:

ssh ubnt@192.168.1.20
set-inform http://vps.example.com:8080/inform

Neuere Gerätefirmware öffnet statt einer Shell ein Menü. Führen Sie denselben Vorgang als einzelnen Befehl aus:

ssh ubnt@192.168.1.20 mca-cli-op set-inform http://vps.example.com:8080/inform

Das Gerät wird nun im Controller als bereit zur Adoption angezeigt. Klicken Sie auf Adopt. Der Status ändert sich in Adopting. An dieser Stelle gibt es häufig eine Überraschung: Sie müssen set-inform normalerweise ein zweites Mal ausführen. Das Gerät startet für die Provisionierung neu und verwendet wieder die in seiner eigenen Konfiguration gespeicherte Inform-URL. Der Controller hat diese URL noch nicht vollständig ersetzt. Führen Sie den Befehl erneut aus, während der Status Adopting lautet, um die Übergabe abzuschließen. Geben Sie auf dem Gerät info ein, um die aktuell gespeicherte Inform-URL und den aktuellen Status anzuzeigen.

Wenn das Gerät zuvor von einem anderen Controller adoptiert wurde, reicht set-inform allein nicht aus. Das Gerät besitzt weiterhin die Zugangsdaten dieses Controllers. Setzen Sie es zuerst auf die Werkseinstellungen zurück. Verwenden Sie dazu entweder die Reset-Taste oder führen Sie über SSH mit den alten Zugangsdaten set-default aus.

Bei mehr als einer Handvoll Geräten sollten Sie stattdessen DHCP verwenden. DHCP (Dynamic Host Configuration Protocol) überträgt mit Option 43 einen herstellerspezifischen Wert. UniFi-Geräte lesen die Inform-URL aus Suboption 2. Erzeugen Sie die Hex-Zeichenfolge auf einem beliebigen Linux-System:

URL="http://vps.example.com:8080/inform"
HEX=$(printf '%s' "$URL" | od -An -tx1 | tr -d ' \n')
printf '02%02x%s\n' "${#URL}" "$HEX"

Für http://192.168.3.10:8080/inform, eine 31 Byte lange Zeichenfolge, gibt dieser Befehl 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d aus. Fügen Sie das Ergebnis als Hex-Wert in das Feld für DHCP-Option 43 Ihres Routers ein. Jedes Gerät, das in diesem Netzwerk startet, übernimmt die Controller-Adresse anschließend aus seinem DHCP-Lease. SSH ist dafür nicht erforderlich. Ältere Anleitungen zeigen stattdessen Suboption 1: 0104 gefolgt von den 4 Bytes einer IPv4-Adresse in Hexadezimaldarstellung. Geräte akzeptieren dieses Format weiterhin.

Eine dritte Möglichkeit besteht darin, DNS am betreffenden Standort zu betreiben. Ein UniFi-Gerät versucht beim Start, den Hostnamen unifi aufzulösen. Ein A-Record für unifi, der auf die Adresse Ihres VPS zeigt, adoptiert Geräte ohne Konfiguration auf jedem einzelnen Gerät. Das funktioniert jedoch nur, wenn Sie den Resolver kontrollieren, den die Geräte tatsächlich verwenden.

Welche UniFi-Ports geöffnet werden müssen und welche privat bleiben

Nur zwei Ports müssen von einem entfernten Standort aus erreichbar sein.

• TCP 8080 ist der Inform-Kanal, über den sich jedes adoptierte Gerät verbindet. Die darin übertragenen Daten sind mit einem AES-Schlüssel verschlüsselt, den der Controller dem Gerät während der Adoption übergibt. Deshalb ist Plain HTTP hier die normale Einstellung.
• UDP 3478 ist STUN (Session Traversal Utilities for NAT). Die Geräte verwenden es, um einen Pfad zurück zum Controller aufrechtzuerhalten.

Auf einem VPS bleiben alle anderen Ports geschlossen.

• TCP 8443 ist die Administrationsoberfläche. Dieser Port darf niemals öffentlich erreichbar sein. Dort liegt die Konfiguration für alle Standorte, die der Controller verwaltet, geschützt durch ein einziges Passwort.
• UDP 10001 und UDP 1900 dienen der Broadcast-Erkennung. Broadcasts überqueren das Internet nicht. Das Öffnen dieser Ports bringt daher nichts.
• TCP 8880 und TCP 8843 dienen den Weiterleitungen des Gästeportals. Öffnen Sie sie nur, wenn Sie ein Gästeportal betreiben.
• TCP 6789 ist der mobile Geschwindigkeitstest, und UDP 5514 dient dem Remote-Syslog. Fügen Sie diese Ports hinzu, wenn Sie sie verwenden.
• TCP 27117 ist MongoDB. In der obigen Compose-Datei veröffentlicht die Datenbank überhaupt keine Ports. Sie existiert daher nur im internen Docker-Netzwerk. Behalten Sie diese Konfiguration bei.

Wenn Ihre Standorte statische öffentliche Adressen haben, erlauben Sie nur diese:

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.4 to any port 8080
sudo ufw allow proto udp from 203.0.113.4 to any port 3478
sudo ufw enable
sudo ufw status verbose

die Grundlagen von ufw für eine VPS-Firewall behandelt die von diesen Regeln vorausgesetzte Standardkonfiguration mit standardmäßiger Ablehnung.

Hier gibt es eine Falle, die immer wieder Probleme verursacht. Von Docker veröffentlichte Ports umgehen ufw. Das Veröffentlichen eines Ports schreibt NAT- und Weiterleitungsregeln direkt in iptables. Dieser Datenverkehr wird in der eigenen Docker-Kette gefiltert, nicht in der INPUT-Kette, die ufw verwaltet. Daher sieht ufw deny 8443 in ufw status korrekt aus, während der Port für die ganze Welt offen bleibt. Testen Sie dies von einem anderen Rechner aus, niemals vom VPS selbst:

nc -vz vps.example.com 8443

Eine Ablehnung oder ein Timeout ist das gewünschte Ergebnis. Wenn eine Verbindung hergestellt wird, ist der Port öffentlich erreichbar, unabhängig davon, was ufw anzeigt. Die zuverlässige Lösung ist bereits in der Compose-Datei enthalten: Veröffentlichen Sie den Port auf 127.0.0.1 oder auf einer Tunneladresse, damit Docker ihn niemals an die öffentliche Schnittstelle bindet. Eine Regel in der Kette DOCKER-USER funktioniert ebenfalls. Das Binden ist jedoch einfacher, und ein Fehler bei der Reihenfolge der Regeln kann diese Einschränkung nicht aufheben.

Was ist mit den eigenen Installationsprogrammen von Ubiquiti?

Ubiquiti veröffentlicht ein Debian-Paket für die Network Application. Es funktioniert, wirft unter aktuellen Ubuntu-Versionen jedoch eine MongoDB-Frage auf, die die Distribution nicht mehr beantwortet: Ubuntu 22.04 und 24.04 enthalten kein MongoDB-Serverpaket. Deshalb müssen Sie das eigene Repository von MongoDB hinzufügen und die passenden Versionen manuell aufeinander abstimmen. Der obige Container erledigt diese Abstimmung mit einem festgelegten Tag. Deshalb wird hier dieser Weg verwendet.

Ubiquitis neueres Produkt für den Selbstbetrieb ist UniFi OS Server. Es führt die UniFi-Anwendungen in Podman-Containern aus und stellt dasselbe UniFi OS wie die Hardware-Konsolen von Ubiquiti bereit. Stand August 2026 benötigt es x86_64 Ubuntu 22.04 oder 24.04 sowie Podman 4.3.1 oder neuer mit slirp4netns. Als Mindestanforderung nennt Ubiquiti 2 vCPU und 4 GB RAM. Empfohlen werden 4 vCPU und 8 GB RAM. Das Installationsprogramm ist auf der Download-Seite hinter einem kostenlosen Ubiquiti-Konto verfügbar. Deshalb gibt es keine stabile einzeilige URL, die in eine Anleitung übernommen werden kann. Das Installationsprogramm legt einen Systembenutzer namens uosserver an und führt die Container unter diesem Benutzer aus. Wählen Sie diese Variante, wenn Sie die Paketierung des Herstellers verwenden möchten. Wählen Sie den Container-Stack, wenn Sie die Versionen selbst festlegen und den Server für weitere Aufgaben verfügbar halten möchten.

Wo UniFi-Backups liegen und wie Sie sie vom Server abrufen

Der Controller schreibt seine Backups nach einem in den Einstellungen festgelegten Zeitplan. Dort legen Sie auch fest, wie viele Backups aufbewahrt werden. Die Dateien landen unter /config/data/backup/autobackup im Container. Auf dem Host entspricht das ~/unifi/config/data/backup/autobackup. Die Dateinamen haben das Format autobackup_10.5.67_20260813_1200_1755086400004.unf.

Prüfen Sie, ob die Dateien tatsächlich erscheinen:

ls -l ~/unifi/config/data/backup/autobackup

Ein Verzeichnis, das einen Tag nach dem Einrichten des Zeitplans noch leer ist, ist bei frisch installierten Containern ein bekanntes Problem. Die Anwendung erwartet, dass das Verzeichnis autobackup bereits vorhanden ist, und legt es nicht selbst an. Der geplante Job schreibt daher stillschweigend keine Dateien. Erstellen Sie das Verzeichnis selbst als derselbe Benutzer, unter dem der Container läuft, und warten Sie auf die nächste Ausführung:

mkdir -p ~/unifi/config/data/backup/autobackup
docker compose restart unifi-network-application

Eine Datei .unf enthält die Site-Konfiguration und die Administratorkonten. Behandeln Sie sie daher wie einen kryptografischen Schlüssel. Kopieren Sie die Dateien auf einen von Ihnen kontrollierten Rechner und halten Sie sie vertraulich:

rsync -av you@vps.example.com:~/unifi/config/data/backup/autobackup/ ~/unifi-backups/

Das Wiederherstellen erfolgt in einem Schritt. Die erste Seite des Einrichtungsassistenten einer neuen Installation bietet die Wiederherstellung aus einer Backup-Datei an. Bei einem laufenden Controller können Sie sie auf derselben Einstellungsseite starten. Stellen Sie das Backup in derselben oder einer neueren Version wieder her. Ein Backup, das von einer neueren Anwendung erstellt wurde als der Version, in der Sie es wiederherstellen, wird abgelehnt. Deshalb sollten Sie die Versionsnummer zusammen mit der Datei dokumentieren.

Was ein Controller-Upgrade beschädigen kann

Erstellen Sie vor jedem Upgrade ein manuelles Backup und laden Sie es herunter. Führen Sie anschließend Folgendes aus:

docker compose pull
docker compose up -d
docker compose logs -f unifi-network-application

Die Datenbank verursacht als Erstes Probleme. Wenn Sie den mongo-Tag in derselben Änderung wie die Anwendung auf eine neue Hauptversion setzen, startet der Controller mit hoher Wahrscheinlichkeit nicht mehr, weil MongoDB Datendateien einer anderen Hauptversion ohne ein schrittweises Upgrade nicht öffnet. Upgraden Sie die Anwendung separat. Aktualisieren Sie MongoDB ebenfalls separat, jeweils um eine Hauptversion, und halten Sie ein aktuelles Backup bereit.

Als Nächstes ist der Arbeitsspeicher kritisch. Eine größere Version benötigt mehr Heap. Wenn die Anwendung startet, einige Minuten läuft und dann beendet wird, erhöhen Sie MEM_LIMIT und MEM_STARTUP auf 1536 oder 2048 und starten Sie sie neu. dmesg -T | grep -i 'killed process' auf dem Host zeigt, ob der Kernel den Prozess beendet.

Die Firmware der Geräte ist ein weiteres Risiko, das häufig übersehen wird. Nach dem Upgrade des Controllers bietet dieser Firmware-Upgrades für übernommene Geräte an. Akzeptieren Sie diese nicht in derselben Sitzung. Wenn sich ein Geräte-Upgrade und ein Controller-Upgrade überschneiden und die Verbindung zwischen beiden abbricht, kann das Gerät in einem unvollständig bereitgestellten Zustand bleiben. Dann müssen Sie wieder per SSH auf set-inform auf Hardware in einem anderen Gebäude zugreifen.

Das Upgrade-Fenster ist weniger problematisch, als es klingt. Die Geräte leiten den Netzwerkverkehr weiter, während der Controller neu startet. Benutzer bemerken daher nichts. Beendet werden jedoch das Gästeportal und RADIUS, wenn der Controller diese Dienste bereitstellt. Wählen Sie deshalb einen Zeitpunkt, zu dem keiner der beiden Dienste verwendet wird. Ein Controller, der um 3 a.m. unbemerkt ausfällt, sollte nicht unbemerkt bleiben. Richten Sie daher einen Uptime-Kuma-Statusmonitor auf Port 8080 und lassen Sie sich benachrichtigen.

Die ehrliche Alternative: Ubiquitis gehostete Konsole

Ubiquiti bietet dieselbe Funktion als Dienst an. Im August 2026 beginnt die Official UniFi Cloud Console bei $29 pro Monat und verwaltet bis zu 500 UniFi-Geräte. Ubiquiti übernimmt dabei Updates und Backups. Die selbst gehostete Anwendung, die Sie gerade installiert haben, ist kostenlos und erfordert kein Abonnement.

Wählen Sie die gehostete Konsole, wenn Sie einen Standort verwalten und lieber bezahlen als Patches einzuspielen. Wählen Sie einen VPS, wenn Sie mehrere Standorte verwalten oder den Controller in einem von Ihnen kontrollierten Netzwerk betreiben und mit den anderen von Ihnen ausgeführten Diensten auf einem System teilen möchten. Der Kostenunterschied ist bei kleinen Installationen tatsächlich relevant. Er ist jedoch nicht der einzige Aspekt: Die Verfügbarkeit einer gehosteten Konsole hängt von einem anderen Anbieter ab. Ihr VPS gehört Ihnen, einschließlich der Nacht, in der sein Datenträger voll läuft. Wenn sich das System unabhängig davon wirtschaftlich lohnen soll, ist was Sie sonst noch auf einem VPS betreiben können die nächste Liste, die Sie lesen sollten.

FAQ

Warum übernimmt mein UniFi-Gerät keinen Controller auf einem VPS?

Geräte erkennen Controller durch Broadcasts über UDP-Port 10001. Ein Broadcast verlässt das lokale Netzwerk jedoch nie. Deshalb kann ein Gerät an einem entfernten Standort keinen Controller im öffentlichen Internet finden. Setzen Sie in den Systemeinstellungen des Controllers den Inform-Host-Override auf den Hostnamen Ihres VPS. Verweisen Sie das Gerät anschließend mit ssh ubnt@<device-ip> und danach mit set-inform http://vps.example.com:8080/inform auf diesen Host. Wenn sich das Gerät im Status „Adopting“ befindet, führen Sie set-inform in diesem Status erneut aus. Wenn es zuvor von einem anderen Controller übernommen wurde, setzen Sie es zuerst auf die Werkseinstellungen zurück. Andernfalls verwendet es weiterhin die Zugangsdaten des alten Controllers.

Wie viel RAM benötigt ein selbst gehosteter UniFi-Controller?

2 GB sind das absolute Minimum für den Betrieb. Mit 4 GB haben Sie ausreichend Reserven. Die Anwendung besteht aus Java und MongoDB. Beide reservieren ihren Speicher unabhängig voneinander: Das Container-Image begrenzt den Java-Heap standardmäßig auf 1024 MB. Der WiredTiger-Cache von MongoDB verwendet die Hälfte des RAM oberhalb von 1 GB. Prüfen Sie auf x86_64 außerdem mit grep -m1 -o avx /proc/cpuinfo, ob die CPU AVX bereitstellt. MongoDB 5.0 und höher startet ohne AVX nicht. Der Datenbank-Container startet sonst in einer Endlosschleife neu.

Sollte ich Port 8443 im Internet veröffentlichen?

Nein. Port 8443 stellt die Administrationsoberfläche bereit. Dort befindet sich die Konfiguration für alle vom Controller verwalteten Sites. Veröffentlichen Sie den Port über 127.0.0.1 und greifen Sie mit ssh -L 8443:127.0.0.1:8443 you@vps.example.com darauf zu. Alternativ können Sie ihn an eine WireGuard- oder Tailscale-Adresse binden. Von Ihren Sites aus müssen nur TCP 8080 und UDP 3478 erreichbar sein. Bei statischen öffentlichen Adressen können Sie den Zugriff auf diese Adressen beschränken. Beachten Sie, dass ein von Docker veröffentlichter Port nicht durch ufw gefiltert wird. Testen Sie den Zugriff daher von einem externen Rechner, statt sich auf ufw status zu verlassen.

Funktioniert mein Netzwerk nicht mehr, wenn der VPS-Controller ausfällt?

Nein. Übernommene Access Points und Switches leiten den Netzwerkverkehr weiterhin anhand der Konfiguration weiter, die der Controller zuvor verteilt hat. Clients bleiben verbunden, und das WLAN funktioniert weiterhin. Ausfällt nur die Verwaltung. Sie verlieren das Dashboard und die Erfassung von Statistiken. Außerdem stehen Funktionen nicht mehr zur Verfügung, die der Controller aktiv bereitstellt, etwa die Authentifizierung im Gastportal oder RADIUS, wenn der Controller als RADIUS-Server fungiert.

Wo speichert der UniFi-Controller seine automatischen Backups?

Im hier verwendeten Container-Image werden sie in /config/data/backup/autobackup gespeichert. Dieser Pfad entspricht auf dem Host Ihrem Datenpfad plus data/backup/autobackup. Die Backups liegen als .unf-Dateien vor, deren Namen die Version und einen Zeitstempel enthalten. Bei manchen neuen Installationen ist das Verzeichnis autobackup nicht vorhanden. Der geplante Backup-Lauf schreibt dann nichts, ohne einen Fehler zu melden. Listen Sie das Verzeichnis daher einen Tag nach dem Einrichten eines Zeitplans auf. Erstellen Sie es selbst, wenn es leer ist. Kopieren Sie die Dateien vom VPS auf ein anderes System. Ein .unf enthält die Site-Konfiguration und die Administratorkonten.