SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor

UniFi Controller auf einem VPS betreiben

Erfahren Sie, wie viel RAM ein UniFi VPS braucht, wie Docker mit MongoDB funktioniert, Layer-3-Adoption mit set-inform gelingt und welche Ports privat bleiben.

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 ist die sinnvolle Größe. In einem Container verbrauchen Java und MongoDB Speicher. Beide verwalten ihren Speicher unabhängig voneinander.

Der Java-Heap ist durch MEM_LIMIT begrenzt. Das Container-Image setzt diesen Wert standardmäßig auf 1024 MB. MongoDB ist der zweite große Speicherverbraucher. Die WiredTiger-Storage-Engine verwendet als Cache die Hälfte des RAM oberhalb von 1 GB oder 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 funktioniert, bis die Auslastung an einem arbeitsreichen Tag steigt. 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 die Ursache war. Wenn Ihnen nur 2 GB zur Verfügung stehen, legen Sie eine Swap-Datei an.

CPU und Datenträger stellen geringe Anforderungen. Ein oder zwei vCPU reichen für einige Dutzend Geräte aus. Beginnen Sie mit 20 GB Speicherplatz und überwachen Sie den Verbrauch. Die Datenbank wächst mit der Anzahl der Clients und mit dem Zeitraum, über den Sie Statistiken aufbewahren. Ein Controller allein 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, weil PhotoPrism und Immich sehr unterschiedliche RAM-Mindestanforderungen haben und beide mehr Speicher benötigen 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. Gibt der Befehl nichts aus, beendet sich mongod beim Start. Anschließend startet der Container in einer Schleife neu, weil die Binärdatei eine Instruktion ausführt, die der Prozessor nicht unterstützt. Ältere Intel-Celeron- und Pentium-Hosts sind eine häufige Ursache. Dasselbe gilt für Hypervisoren, die CPU-Flags vor dem Gast verbergen. MongoDB 4.4 ist das jüngste Release, das ohne AVX läuft. Das Image akzeptiert auch ältere Versionen bis zurück zu 3.6. MongoDB 4.4 hat jedoch im Februar 2024 das Ende des Lebenszyklus erreicht. MongoDB hat zwar 4.4-Builds für den im Dezember 2025 veröffentlichten Fix für CVE-2025-14847 bereitgestellt. Für die nächste Schwachstelle gibt es dafür aber keine Garantie. Die älteren Releases sind noch weiter im Rückstand. Der Wechsel zu einem Host mit einer neueren CPU ist die bessere Lösung. Auf einem ARM-VPS stellt sich diese Frage nicht, weil AVX ein x86-Befehlssatz ist und beide Images arm64-Builds veröffentlichen. Wenn Sie zwischen den 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 unter Docker Engine 28.0.0 oder höher nichts außerhalb der VPS die Administrationsoberfläche erreichen. In älteren Releases können andere Hosts im selben L2-Segment, beispielsweise Rechner am selben Netzwerk-Switch, auf Ports zugreifen, die an localhost veröffentlicht wurden. Führen Sie daher docker version aus und aktualisieren Sie den Server zuerst, falls eine ältere Version gemeldet wird. 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 im Browser auf. Das Zertifikat ist selbstsigniert, daher zeigt der Browser einmalig eine Warnung an. Erstellen Sie das Administratorkonto, vergeben Sie einen Namen für die Site und überspringen Sie die Geräteaufnahme zunächst.

Ein SSH-Tunnel reicht für eine einzelne Administration aus. Für ein Team weisen Sie der VPS eine private Adresse zu 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 Mitarbeiter erreichen 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. Beachten Sie: Docker kann keinen Port an eine Adresse veröffentlichen, die noch nicht vorhanden ist. Die Tunnel-Schnittstelle muss daher 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 Sie öffnen sollten und welche privat bleiben müssen

Für Adoption und die tägliche Verwaltung müssen zwei Ports von einem entfernten Standort aus erreichbar sein.

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

Einige Funktionen benötigen weitere Ports. Die Ubiquiti-Portreferenz nennt TCP 5671 für Traffic-Flow-Protokolle von UXG-Gateways, die in L2- oder L3-Netzwerken adoptiert wurden. Wenn ein Standort mit einem UXG an diesen Controller berichtet und Sie diese Protokolle benötigen, öffnen Sie TCP 5671 ebenfalls für diesen Standort.

Alle übrigen Ports bleiben auf einem VPS geschlossen.

  • TCP 8443 ist die Administrationsoberfläche. Dieser Port darf niemals öffentlich erreichbar sein. Dahinter liegt die Konfiguration für jeden vom Controller verwalteten Standort, geschützt durch ein einziges Passwort.
  • UDP 10001 und UDP 1900 dienen der Broadcast-Erkennung. Broadcasts überschreiten das Internet nicht. Das Öffnen dieser Ports bewirkt daher nichts.
  • TCP 8880 und TCP 8843 dienen den Weiterleitungen des Guest Portals. Öffnen Sie sie nur, wenn Sie ein Guest Portal betreiben.
  • TCP 6789 wird für den mobilen Geschwindigkeitstest verwendet, UDP 5514 für Remote-Syslog. Fügen Sie diese Ports hinzu, wenn Sie die jeweiligen Funktionen verwenden.
  • TCP 27117 ist MongoDB. In der obigen Compose-Datei veröffentlicht die Datenbank überhaupt keine Ports. Sie ist daher nur im internen Docker-Netzwerk vorhanden. Belassen Sie es dabei.

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 UFW-Grundlagen für eine VPS-Firewall behandeln die standardmäßige Deny-Konfiguration, von der diese Regeln ausgehen.

Hier gibt es eine Falle, in die Anwender immer wieder geraten. Von Docker veröffentlichte Ports umgehen ufw. Beim Veröffentlichen eines Ports schreibt Docker NAT- und Weiterleitungsregeln direkt in iptables. Dieser Datenverkehr wird in der eigenen Docker-Kette gefiltert, nicht in der INPUT-Kette, die ufw verwaltet. Deshalb sieht ufw deny 8443 in ufw status korrekt aus, während der Port weiterhin für die ganze Welt offen ist. 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 unabhängig von den Angaben von ufw öffentlich erreichbar. Die zuverlässige Lösung ist bereits in der Compose-Datei vorgesehen: 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 DOCKER-USER-Kette funktioniert ebenfalls. Das Binden ist jedoch einfacher, und ein Fehler bei der Reihenfolge der Regeln kann diese Einstellung nicht unwirksam machen.

Was ist mit den eigenen Installationsprogrammen von Ubiquiti?

Ubiquiti veröffentlicht ein Debian-Paket für die Network Application. Seit Oktober 2026 bezeichnet das Help Center diesen Weg als veraltet und nennt UniFi OS Server den neuen Standard für Self-Hosting. Das Paket funktioniert. Unter aktuellen Ubuntu-Versionen entsteht jedoch eine offene MongoDB-Frage, die die Distribution nicht mehr beantwortet: Ubuntu 22.04 und 24.04 enthalten kein MongoDB-Serverpaket. Sie müssen daher das eigene Repository von MongoDB hinzufügen und die passenden Versionen manuell aufeinander abstimmen. Der obige Container erledigt diese Abstimmung mit einem festen Tag. Deshalb wird hier dieser Weg verwendet.

Das neuere Self-Hosted-Produkt von Ubiquiti ist UniFi OS Server. Es führt die UniFi-Anwendungen in Podman-Containern aus und stellt dasselbe UniFi OS bereit wie die Hardware-Konsolen von Ubiquiti. Seit Oktober 2026 nennt Ubiquiti eine x86-64-CPU, Ubuntu 24.04 oder neuer beziehungsweise Debian 13 oder neuer, Podman 4.9.3 oder neuer mit slirp4netns 1.2 oder neuer, mindestens 2 GB RAM und 10 GB freien Speicher als Voraussetzungen. Der Installationslink auf der Releases- oder Download-Seite von Ubiquiti ist versionsabhängig: Klicken Sie mit der rechten Maustaste auf den Download, kopieren Sie die Linkadresse und rufen Sie sie mit curl -O oder wget ab. Jede Version erhält eine eigene URL. Eine Anleitung kann daher eine Version fest vorgeben, aber keinen Link angeben, der immer auf die neueste Version verweist. Das Installationsprogramm richtet einen systemd-Dienst namens uosserver ein. Diesen Dienst beenden und starten Sie mit systemctl. Wählen Sie diese Variante, wenn Sie die Paketierung von Ubiquiti verwenden möchten. Wählen Sie den Container-Stack, wenn Sie die Versionen selbst festlegen und den Server für andere Aufgaben freihalten 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 Oktober 2026 wird sie im US-Store von Ubiquiti als Official UniFi Hosting angeboten. Die Preise beginnen bei $29 pro Monat. Auf einem von Ubiquiti betriebenen Server lassen sich damit bis zu 1,000 UniFi Network-Geräte verwalten. 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 Updates und Patches einzuspielen. Wählen Sie einen VPS, wenn Sie mehrere Standorte verwalten oder den Controller in einem von Ihnen kontrollierten Netzwerk betreiben und einen Server mit den anderen von Ihnen betriebenen Diensten gemeinsam nutzen möchten. Der Kostenunterschied bei kleinen Installationen ist real. Er ist jedoch nicht der einzige Faktor: Die Verfügbarkeit einer gehosteten Konsole hängt von jemand anderem ab. Ihr VPS gehört Ihnen, einschließlich der Nacht, in der sein Datenträger voll läuft. Wenn der Server sich in jedem Fall wirtschaftlich tragen 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 über Broadcasts auf UDP-Port 10001. Ein Broadcast verlässt das lokale Netzwerk nicht. Deshalb kann ein Gerät an einem entfernten Standort keinen Controller im öffentlichen Internet finden. Setzen Sie in den Systemeinstellungen des Controllers die Inform-Host-Überschreibung auf den Hostnamen Ihres VPS. Verweisen Sie das Gerät anschließend mit ssh ubnt@<device-ip> gefolgt von set-inform http://vps.example.com:8080/inform darauf. Wenn sich das Gerät im Zustand „Adopting“ befindet, führen Sie set-inform dort erneut aus. Wenn ein anderer Controller das Gerät zuvor übernommen hat, setzen Sie es zuerst auf die Werkseinstellungen zurück. Andernfalls enthält es weiterhin die Zugangsdaten des alten Controllers.

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

2 GB sind das Mindestmaß für den Betrieb, 4 GB bieten ausreichend Reserven. Die Anwendung besteht aus Java und MongoDB. Beide verwalten 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 wird sonst in einer Neustartschleife ausgeführt.

Sollte ich Port 8443 im Internet veröffentlichen?

Nein. Port 8443 ist die Administrationsoberfläche. Dort liegt die Konfiguration für jede Site, die der Controller verwaltet. Veröffentlichen Sie den Port mit 127.0.0.1 bei Docker Engine 28.0.0 oder höher 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. Für Adoption und Verwaltung müssen Ihre Sites TCP 8080 und UDP 3478 erreichen können. Zusätzlich ist TCP 5671 erforderlich, wenn ein UXG-Gateway Traffic-Flow-Logs an den Controller sendet. Bei statischen öffentlichen Adressen können Sie diese Zugriffe auf die öffentlichen Adressen der Sites beschränken. Beachten Sie, dass ein von Docker veröffentlichter Port nicht durch ufw gefiltert wird. Testen Sie deshalb von einem externen Rechner aus, statt ufw status zu vertrauen.

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

Nein. Übernommene Access Points und Switches leiten den Datenverkehr weiterhin anhand der Konfiguration weiter, die der Controller bereits übertragen hat. Clients bleiben verbunden, und das WLAN funktioniert weiter. Aus fällt die Verwaltung. Sie verlieren das Dashboard und die Erfassung von Statistiken. Außerdem funktionieren Live-Funktionen nicht mehr, die der Controller bereitstellt, beispielsweise die Authentifizierung am Gastportal oder RADIUS, wenn der Controller als RADIUS-Server dient.

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 werden als .unf-Dateien abgelegt, deren Namen die Version und einen Zeitstempel enthalten. Bei manchen Neuinstallationen existiert das Verzeichnis autobackup nicht. Das geplante Backup schreibt dann nichts, ohne einen Fehler zu melden. Listen Sie das Verzeichnis deshalb einen Tag nach dem Einrichten des Zeitplans auf. Erstellen Sie es selbst, wenn es leer ist. Kopieren Sie die Dateien vom VPS herunter. Ein .unf enthält die Site-Konfiguration und die Administratorkonten.

#unifi#ubiquiti#network-management#docker#self-hosting