Jak zainstalować kontroler UniFi na serwerze VPS

Rola kontrolera UniFi na serwerze VPS

Kontroler UniFi na serwerze VPS to serwer zarządzający, który pozostaje dostępny nawet w przypadku awarii zarządzanych przez niego lokalizacji. Oprogramowanie to stanowi UniFi Network Application firmy Ubiquiti: aplikacja Java korzystająca z bazy danych MongoDB. Kontroler konfiguruje punkty dostępowe i przełączniki, przechowuje ich statystyki oraz udostępnia interfejs administracyjny. Nie obsługuje on ruchu sieciowego klientów.

Ten ostatni punkt determinuje miejsce instalacji. Umieszczenie kontrolera na maszynie wewnątrz zarządzanego biura powoduje utratę sieci oraz narzędzia do jej monitorowania w tym samym momencie. Umieszczenie go na serwerze VPS ze stałym publicznym adresem IP zapewnia ciągłość działania, nieprzerwane zbieranie danych oraz możliwość adopcji urządzeń z wielu lokalizacji z jednego miejsca. Kontroler wymaga wysokiej dostępności, a nie dużej mocy obliczeniowej.

Gdy kontroler jest offline, zaadoptowane punkty dostępowe i przełączniki kontynuują przesyłanie ruchu zgodnie z wgraną konfiguracją. Użytkownik traci dostęp do pulpitu nawigacyjnego i statystyk, a także do funkcji wymagających aktywnego kontrolera: logowania do portalu gościnnego lub usługi RADIUS (remote authentication dial-in user service), jeśli kontroler pełni rolę serwera RADIUS. Połączenia klientów pozostają aktywne.

Ile pamięci RAM potrzebuje kontroler UniFi?

Dwa GB to absolutne minimum, a 4 GB to zalecana ilość. Wewnątrz jednej instancji znajdują się dwa procesy zużywające pamięć: Java oraz MongoDB, które ustalają swój rozmiar niezależnie od siebie.

Stos (heap) Javy jest ograniczony przez MEM_LIMIT, co w obrazie kontenera domyślnie ustawiono na 1024 MB. Drugą połowę zajmuje MongoDB. Silnik pamięci masowej WiredTiger ustala rozmiar pamięci podręcznej (cache) na połowę dostępnej pamięci RAM powyżej 1 GB lub 256 MB, w zależności od tego, która wartość jest większa. Na serwerze VPS z 2 GB RAM daje to około 512 MB pamięci podręcznej, 1 GB stosu, dodatkową pamięć niebędącą stosem (non-heap) środowiska JVM oraz pamięć zajmowaną przez system operacyjny. Taka konfiguracja działa do momentu większego obciążenia, kiedy to mechanizm OOM (out-of-memory) killera jądra systemu kończy jeden z tych dwóch procesów. Po każdym niewyjaśnionym restarcie należy uruchomić dmesg -T | grep -i 'killed process', aby sprawdzić, czy to właśnie było przyczyną. Jeśli dysponujesz tylko 2 GB RAM, dodaj plik wymiany (swap).

Wymagania dotyczące procesora i dysku są niskie. Jeden lub dwa vCPU wystarczą do obsługi kilkudziesięciu urządzeń. Zacznij od 20 GB miejsca na dysku i monitoruj jego zajętość, ponieważ baza danych rośnie wraz z liczbą klientów oraz okresem przechowywania statystyk. Sam kontroler pozostawia większość zasobów serwera 4 GB w stanie bezczynności. Jeśli planujesz uruchomić na nim inne usługi, dobierz zasoby pod kątem tych dodatkowych aplikacji, ponieważ PhotoPrism i Immich mają znacznie wyższe wymagania minimalne RAM i każda z nich wymaga więcej pamięci niż sam kontroler.

Jedna funkcja procesora ma kluczowe znaczenie i łatwo ją przeoczyć w tanich planach:

grep -m1 -o avx /proc/cpuinfo

MongoDB w wersji 5.0 i nowszych wymaga instrukcji AVX (advanced vector extensions) na architekturze x86_64. Jeśli to polecenie nie zwraca żadnego wyniku, proces mongod ulegnie awarii podczas uruchamiania, a kontener będzie restartował się w pętli, ponieważ plik binarny próbuje wykonać instrukcję nieobsługiwaną przez procesor. Przyczyną są zazwyczaj starsze procesory Intel Celeron i Pentium lub hypervisory, które ukrywają flagi procesora przed systemem gościa. MongoDB 4.4 nie wymaga AVX i jest jedyną alternatywą, jednak jest to wersja bazy danych, która nie otrzymuje już poprawek od producenta. Przeniesienie usługi na serwer z nowszym procesorem jest lepszym rozwiązaniem. W przypadku VPS z architekturą ARM problem ten nie występuje, ponieważ AVX jest zestawem instrukcji x86, a obrazy są dostępne w wersjach arm64. Jeśli wybierasz między tymi dwiema architekturami, różnice między planami VPS ARM i x86 wykraczają poza samą cenę.

Instalacja UniFi Network Application przy użyciu Docker Compose

Docker jest rozwiązaniem generującym najmniej problemów, ponieważ pozwala na przypięcie wersji MongoDB obsługiwanej przez aplikację, zamiast polegania na wersji dostarczanej przez dystrybucję. Jeśli Docker nie jest jeszcze zainstalowany na serwerze, najpierw zainstaluj Docker na VPS.

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

MongoDB wymaga utworzenia użytkownika, zanim aplikacja będzie mogła się zalogować. Oficjalny obraz MongoDB przy pierwszym uruchomieniu wykonuje każdy skrypt znajdujący się w /docker-entrypoint-initdb.d. Zapisz poniższą treść jako ~/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

Ten skrypt uruchamia się tylko wtedy, gdy katalog bazy danych jest pusty. Jeśli uruchomisz stos z błędnym hasłem, użytkownik zostanie utworzony z tym hasłem, a późniejsza edycja pliku compose nic nie zmieni, ponieważ skrypt nie zostanie wykonany ponownie. Objawem jest logowanie przez kontener aplikacji błędów uwierzytelniania MongoDB, podczas gdy interfejs webowy nigdy się nie pojawia. W przypadku świeżej instalacji rozwiązaniem jest zatrzymanie stosu, usunięcie ~/unifi/db i ponowne uruchomienie.

Następnie utwórz plik ~/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

Oba tagi obrazów zostały przypięte celowo. 10.5.67-ls141 było aktualnym wydaniem aplikacji w sierpniu 2026 roku, dlatego sprawdź listę wydań obrazu i przypnij wersję aktualną w momencie instalacji. Taga bazy danych dotyczy to w większym stopniu. MongoDB nie aktualizuje samodzielnie plików danych pomiędzy głównymi wersjami, więc mongo:latest pewnego dnia pobierze nową wersję główną, odmówi otwarcia istniejących plików i wpadnie w pętlę restartów. Przypnij wersję główną i aktualizuj ją świadomie. UniFi Network 8.1 i nowsze obsługują MongoDB od 3.6 do 7.0, a wersja 9.0 dodała wsparcie dla MongoDB 8.0.

PUID oraz PGID muszą odpowiadać rzeczywistemu użytkownikowi w systemie hosta, w przeciwnym razie pliki w ./config będą własnością tożsamości, która nie ma uprawnień do zapisu. Uruchom id, aby sprawdzić swoje wartości. jak działają PUID i PGID w obrazach kontenerów wyjaśnia, jak objawia się niedopasowanie tych parametrów.

Uruchom stos i obserwuj logi:

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

docker compose ps powinno pokazać oba kontenery ze statusem running. Kontener unifi-db zawieszony w stanie restarting oznacza albo problem z instrukcjami AVX, albo problem z uprawnieniami do ./db. Gdy logi się ustabilizują, sprawdź dwa porty nasłuchujące:

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

Jakikolwiek kod statusu HTTP oznacza, że usługa jest powiązana z portem i odpowiada. Connection refused oznacza, że aplikacja wciąż się uruchamia (co przy pierwszym starcie na małym VPS może potrwać minutę lub dwie) albo że w ogóle nie wystartowała.

Dostęp do interfejsu administratora bez jego wystawiania

Port 8443 jest opublikowany na 127.0.0.1 w powyższym pliku, więc żaden podmiot spoza VPS nie może uzyskać dostępu do interfejsu administratora. Przekieruj go przez SSH, aby uruchomić kreator konfiguracji:

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

Pozostaw tę sesję otwartą i przejdź pod adres https://127.0.0.1:8443. Certyfikat jest podpisany samodzielnie, więc przeglądarka wyświetli jednorazowe ostrzeżenie. Utwórz konto administratora, nadaj nazwę witrynie i na razie pomiń dodawanie urządzeń.

Tunel SSH jest wystarczający dla jednego administratora. W przypadku zespołu nadaj VPS prywatny adres i powiąż interfejs z tym adresem. Zarówno WireGuard VPN na własnym VPS, jak i router podsieci Tailscale zapewniają adres, do którego dostęp mają tylko uprawnieni użytkownicy. Zmień opublikowany port na 10.8.0.1:8443:8443 dla WireGuard lub na adres przypisany przez Tailscale. Uwaga: Docker nie może opublikować portu na adresie, który jeszcze nie istnieje, więc interfejs tunelu musi zostać podniesiony przed uruchomieniem kontenera, w przeciwnym razie kontener nie wystartuje z powodu błędu powiązania (bind error).

Dlaczego zdalne urządzenie UniFi nie chce się zaadoptować

Fabrycznie nowe urządzenie UniFi odnajduje kontroler poprzez rozgłaszanie w sieci lokalnej na porcie UDP 10001. Rozgłoszenia nie opuszczają sieci LAN, więc urządzenie w biurze w innym mieście nigdy nie wykryje kontrolera działającego na VPS. Jest to adopcja w warstwie 3 (Layer 3) i to właśnie tutaj pojawia się najwięcej problemów. Urządzenie jest sprawne, kontroler również. Brakuje jedynie informacji, gdzie urządzenie ma szukać kontrolera.

Najpierw należy wskazać kontrolerowi, jaki adres ma przekazywać urządzeniom. W ustawieniach kontrolera, w sekcji System, znajduje się ustawienie inform host z opcją override. Należy ustawić je na publiczną nazwę hosta lub adres IP serwera VPS. Bez tego kontroler reklamuje adres, który widzi na własnym interfejsie, co wewnątrz sieci typu Docker bridge skutkuje adresem prywatnym, takim jak 172.18.0.3. Urządzenie otrzymuje ten adres, nie potrafi do niego wytrasować połączenia i wraca do stanu wyszukiwania.

Następnie należy wskazać urządzeniu ten adres. Połącz się przez SSH z urządzeniem w zdalnej sieci LAN. Urządzenie z ustawieniami fabrycznymi akceptuje nazwę użytkownika ubnt oraz hasło ubnt:

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

Nowsze oprogramowanie układowe urządzeń zamiast powłoki uruchamia menu. Wykonaj to samo jako pojedyncze polecenie:

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

Urządzenie pojawi się teraz w kontrolerze jako gotowe do adopcji. Kliknij Adopt, a stan zmieni się na Adopting. W tym miejscu pojawia się sytuacja, która zaskakuje większość użytkowników: zazwyczaj należy uruchomić set-inform po raz drugi. Urządzenie restartuje się do fazy provisioning i wraca do adresu URL inform zapisanego w jego własnej konfiguracji, której kontroler jeszcze nie zdążył nadpisać. Ponowne uruchomienie polecenia, gdy stan wskazuje Adopting, finalizuje przekazanie. Wpisz info na urządzeniu, aby sprawdzić aktualnie zapisany adres URL inform oraz stan urządzenia.

Jeśli urządzenie było wcześniej zaadoptowane przez inny kontroler, samo set-inform nie wystarczy, ponieważ urządzenie nadal posiada poświadczenia poprzedniego kontrolera. Należy najpierw przywrócić ustawienia fabryczne za pomocą przycisku reset lub polecenia set-default przez SSH, używając starych poświadczeń.

W przypadku większej liczby urządzeń lepiej użyć DHCP. Opcja 43 protokołu DHCP (dynamic host configuration protocol) przenosi wartość specyficzną dla producenta, a urządzenia UniFi odczytują adres URL inform z podopcji 2. Wygeneruj ciąg szesnastkowy na dowolnym systemie Linux:

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

Dla http://192.168.3.10:8080/inform, czyli 31-bajtowego ciągu, polecenie to wypisze 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Wklej wynik do pola opcji 43 DHCP w swoim routerze jako wartość szesnastkową. Każde urządzenie uruchamiające się w tej sieci otrzyma adres kontrolera wraz z dzierżawą adresu IP, bez konieczności używania SSH. Starsze poradniki wskazują na podopcję 1, 0104, po której następują cztery bajty adresu IPv4 w formacie szesnastkowym; urządzenia nadal akceptują ten format.

Istnieje trzecia droga, jeśli w danej lokalizacji zarządzasz serwerem DNS. Urządzenie UniFi podczas startu próbuje rozwiązać nazwę hosta unifi, więc rekord typu A dla unifi wskazujący na adres Twojego VPS pozwoli zaadoptować urządzenia bez żadnej pracy przy każdym z nich z osobna. Metoda ta działa tylko wtedy, gdy masz kontrolę nad serwerem DNS, z którego faktycznie korzystają urządzenia.

Które porty UniFi otworzyć, a które zachować jako prywatne

Tylko dwa porty muszą być dostępne z lokalizacji zdalnej.

• TCP 8080 to kanał informacyjny, z którym łączy się każde zaadoptowane urządzenie. Dane wewnątrz są szyfrowane algorytmem AES przy użyciu klucza przekazanego urządzeniu przez kontroler podczas adopcji, dlatego standardowym ustawieniem jest tu zwykłe HTTP.
• UDP 3478 to STUN (session traversal utilities for NAT), którego urządzenia używają do utrzymywania ścieżki powrotnej do kontrolera.

Wszystkie pozostałe porty na VPS powinny pozostać zamknięte.

• TCP 8443 to interfejs administracyjny. Jest to port, który nigdy nie może być publicznie dostępny. Przechowuje on konfigurację wszystkich witryn zarządzanych przez kontroler, zabezpieczoną jednym hasłem.
• UDP 10001 oraz UDP 1900 służą do wykrywania rozgłoszeniowego (broadcast discovery). Pakiety rozgłoszeniowe nie przechodzą przez Internet, więc ich otwieranie nie przynosi żadnych korzyści.
• TCP 8880 oraz TCP 8843 to przekierowania portalu gościnnego. Należy je otwierać tylko w przypadku korzystania z portalu gościnnego.
• TCP 6789 służy do testów prędkości w aplikacji mobilnej, a UDP 5514 do zdalnego syslogu. Należy je dodać w razie potrzeby.
• TCP 27117 to MongoDB. W powyższym pliku compose baza danych nie publikuje żadnych portów, więc istnieje ona wyłącznie wewnątrz sieci Docker. Należy zachować ten stan.

Jeśli witryny posiadają statyczne adresy publiczne, należy zezwolić na ruch tylko z nich:

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

podstawy ufw dla firewalla na VPS omawiają domyślną politykę odmowy (deny), na której opierają się te reguły.

Istnieje pułapka, w którą użytkownicy wpadają regularnie. Opublikowane porty Docker omijają ufw. Publikacja portu zapisuje reguły NAT i przekierowania bezpośrednio w iptables, a ruch ten jest filtrowany w łańcuchu Docker, a nie w łańcuchu INPUT zarządzanym przez ufw. W rezultacie ufw deny 8443 wygląda poprawnie w ufw status, podczas gdy port pozostaje otwarty dla świata. Test należy przeprowadzić z innej maszyny, nigdy z poziomu samego VPS:

nc -vz vps.example.com 8443

Pożądany wynik to odmowa połączenia lub przekroczenie czasu oczekiwania. Jeśli połączenie zostanie nawiązane, port jest publiczny, niezależnie od ustawień ufw. Niezawodnym rozwiązaniem jest to zastosowane w pliku compose: publikacja portu na 127.0.0.1 lub na adresie tunelu, dzięki czemu Docker nigdy nie wiąże go z interfejsem publicznym. Reguła w łańcuchu DOCKER-USER również zadziała, jednak wiązanie adresu jest prostsze i błąd w kolejności reguł nie może go unieważnić.

Co z oficjalnymi instalatorami Ubiquiti?

Ubiquiti udostępnia pakiet Debian dla Network Application. Działa on poprawnie, jednak w przypadku aktualnych wersji Ubuntu pojawia się problem z MongoDB, którego dystrybucja już nie rozwiązuje: Ubuntu 22.04 oraz 24.04 nie zawierają pakietu serwera MongoDB, co wymusza ręczne dodanie repozytorium MongoDB i dopasowanie wersji. Powyższy kontener realizuje to dopasowanie w ramach jednej przypiętej wersji (tagu), dlatego jest to zalecana ścieżka.

Nowszym produktem typu self-hosted od Ubiquiti jest UniFi OS Server, który uruchamia aplikacje UniFi w kontenerach Podman, zapewniając ten sam system UniFi OS, co w konsolach sprzętowych producenta. Według stanu na sierpień 2026 wymaga on systemu Ubuntu 22.04 lub 24.04 na architekturze x86_64, Podman w wersji 4.3.1 lub nowszej z slirp4netns, a także minimum 2 vCPU i 4 GB pamięci RAM (rekomendowane 4 vCPU i 8 GB). Instalator jest dostępny po zalogowaniu na darmowe konto Ubiquiti na stronie pobierania, dlatego nie istnieje jeden stabilny adres URL, który można wkleić do poradnika. Instalator tworzy użytkownika systemowego o nazwie uosserver i uruchamia kontenery w jego kontekście. Wybierz to rozwiązanie, jeśli preferujesz oficjalne pakiety producenta. Wybierz stos kontenerowy, jeśli chcesz samodzielnie zarządzać wersjami i zachować zasoby serwera do innych zadań.

Gdzie przechowywane są kopie zapasowe UniFi i jak je pobrać z serwera

Kontroler tworzy własne kopie zapasowe zgodnie z harmonogramem ustawionym w sekcji Settings, w zakładce backup, gdzie określa się również liczbę przechowywanych plików. Pliki trafiają do /config/data/backup/autobackup wewnątrz kontenera, co odpowiada ścieżce ~/unifi/config/data/backup/autobackup na hoście, a ich nazwy mają format autobackup_10.5.67_20260813_1200_1755086400004.unf.

Należy sprawdzić, czy pliki faktycznie się pojawiają:

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

Pusty katalog dzień po ustawieniu harmonogramu to znany problem w świeżych instalacjach kontenerowych. Aplikacja oczekuje, że katalog autobackup istnieje, ale nie tworzy go automatycznie, przez co zaplanowane zadanie kończy się niepowodzeniem bez komunikatu o błędzie. Należy utworzyć go ręcznie z uprawnieniami użytkownika, na którym działa kontener, a następnie poczekać na kolejne uruchomienie zadania:

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

Plik .unf zawiera konfigurację witryny oraz konta administratorów, dlatego należy traktować go jak klucz kryptograficzny. Kopie należy pobrać na zarządzaną przez siebie maszynę i zapewnić im poufność:

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

Przywracanie danych to operacja jednokrokowa. Pierwsza strona kreatora konfiguracji w nowej instalacji oferuje opcję przywrócenia z pliku kopii zapasowej, a działający kontroler pozwala na to z poziomu tej samej strony ustawień. Przywracanie musi odbywać się do tej samej lub nowszej wersji oprogramowania. Kopia zapasowa utworzona przez nowszą wersję aplikacji niż ta, do której jest przywracana, zostanie odrzucona, dlatego należy zapisywać numer wersji wraz z plikiem kopii.

Co może ulec awarii podczas aktualizacji kontrolera

Przed każdą aktualizacją wykonaj ręczną kopię zapasową i pobierz ją na dysk lokalny. Następnie:

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

Baza danych jest pierwszym elementem, który ulega awarii. Zmiana tagu mongo na nową wersję główną w tej samej edycji co aplikacja to najszybsza droga do sytuacji, w której kontroler nie uruchomi się. MongoDB nie otworzy plików danych z innej wersji głównej bez przeprowadzenia etapowej aktualizacji. Aktualizuj aplikację oddzielnie. Migruj MongoDB osobno, zwiększając wersję o jeden stopień, posiadając zawsze świeżą kopię zapasową.

Pamięć operacyjna jest kolejnym krytycznym zasobem. Nowsze wydania wymagają większego stosu (heap). Jeśli aplikacja uruchamia się, działa przez kilka minut, a następnie kończy pracę, zwiększ MEM_LIMIT oraz MEM_STARTUP do wartości 1536 lub 2048 i zrestartuj usługę. Polecenie dmesg -T | grep -i 'killed process' na hoście potwierdzi, czy proces został zakończony przez jądro systemu.

Oprogramowanie układowe urządzeń to ryzyko, o którym często się zapomina. Po aktualizacji kontrolera oferuje on aktualizacje firmware dla zaadoptowanych urządzeń. Nie akceptuj ich w tej samej sesji. Jeśli aktualizacja urządzenia i kontrolera nałożą się na siebie, a połączenie między nimi zostanie przerwane, urządzenie może pozostać w stanie częściowego skonfigurowania. W takim przypadku konieczne będzie użycie set-inform przez SSH na sprzęcie znajdującym się w innym budynku.

Okno serwisowe jest mniej uciążliwe, niż mogłoby się wydawać. Urządzenia kontynuują przesyłanie ruchu podczas restartu kontrolera, więc użytkownicy nie odczuwają przerwy. Przestaje natomiast działać portal gościnny oraz RADIUS, jeśli kontroler je obsługuje, dlatego wybierz czas, w którym te usługi nie są używane. Warto wiedzieć o kontrolerze, który wyłączył się w nocy, dlatego skieruj monitor statusu Uptime Kuma na port 8080, aby otrzymywać powiadomienia.

Uczciwa alternatywa: hostowana konsola Ubiquiti

Ubiquiti oferuje tę samą usługę w modelu komercyjnym. Według stanu na sierpień 2026 r. oficjalna usługa UniFi Cloud Console kosztuje od 29 USD miesięcznie i pozwala zarządzać maksymalnie 500 urządzeniami UniFi, przy czym Ubiquiti odpowiada za aktualizacje i kopie zapasowe. Samodzielnie hostowana aplikacja, którą właśnie zainstalowano, jest bezpłatna i nie wymaga subskrypcji.

Wybierz hostowaną konsolę, jeśli zarządzasz jedną lokalizacją i wolisz zapłacić niż samodzielnie przeprowadzać aktualizacje. Wybierz VPS, jeśli zarządzasz wieloma lokalizacjami lub jeśli chcesz, aby kontroler znajdował się w sieci pod Twoją kontrolą i współdzielił zasoby z innymi uruchomionymi usługami. Różnica w kosztach przy małej skali jest zauważalna, ale nie jest to jedyny czynnik decydujący: hostowana konsola oznacza poleganie na dostępności usług dostawcy, natomiast VPS jest w pełni pod Twoją opieką, łącznie z sytuacją, w której w nocy zapełni się dysk. Jeśli serwer ma być wykorzystywany do różnych zadań, co jeszcze można uruchomić na VPS to lista, którą warto przeczytać w następnej kolejności.

FAQ

Dlaczego urządzenie UniFi nie chce się zaadoptować do kontrolera na VPS?

Urządzenia wykrywają kontrolery poprzez rozgłaszanie (broadcast) na porcie UDP 10001. Komunikat rozgłoszeniowy nie opuszcza sieci lokalnej, więc urządzenie w zdalnej lokalizacji nie odnajdzie kontrolera w publicznym Internecie. Ustaw w ustawieniach systemowych kontrolera adres hosta inform (inform host override) na nazwę hosta swojego VPS, a następnie wskaż go urządzeniu za pomocą ssh ubnt@<device-ip>, po czym wykonaj set-inform http://vps.example.com:8080/inform. Jeśli urządzenie pozostaje w stanie Adopting, uruchom set-inform ponownie, gdy jest w tym stanie. Jeśli urządzenie zostało wcześniej zaadoptowane przez inny kontroler, najpierw przywróć je do ustawień fabrycznych, ponieważ nadal przechowuje poświadczenia starego kontrolera.

Ile pamięci RAM potrzebuje samodzielnie hostowany kontroler UniFi?

2 GB to absolutne minimum, a 4 GB zapewnia komfortową pracę. Aplikacja składa się z Java oraz MongoDB, które zarządzają pamięcią oddzielnie: obraz kontenera domyślnie ogranicza stertę Java do 1024 MB, podczas gdy pamięć podręczna WiredTiger w MongoDB zajmuje połowę pamięci RAM powyżej 1 GB. Na architekturze x86_64 upewnij się również, że procesor obsługuje instrukcje AVX za pomocą grep -m1 -o avx /proc/cpuinfo, ponieważ MongoDB w wersji 5.0 i nowszych nie uruchomi się bez nich, co spowoduje zapętlenie restartów kontenera bazy danych.

Czy powinienem wystawiać port 8443 do Internetu?

Nie. Port 8443 to interfejs administracyjny, który zawiera konfigurację wszystkich witryn zarządzanych przez kontroler. Opublikuj go na 127.0.0.1 i uzyskuj do niego dostęp przez ssh -L 8443:127.0.0.1:8443 you@vps.example.com lub powiąż go z adresem WireGuard albo Tailscale. Tylko porty TCP 8080 oraz UDP 3478 muszą być dostępne z Twoich lokalizacji; możesz ograniczyć dostęp do nich tylko do publicznych adresów IP tych lokalizacji, jeśli są one statyczne. Pamiętaj, że port opublikowany w Docker nie jest filtrowany przez ufw, więc przetestuj dostęp z zewnętrznej maszyny, zamiast polegać wyłącznie na ufw status.

Czy moja sieć przestanie działać, jeśli kontroler na VPS ulegnie awarii?

Nie. Zaadoptowane punkty dostępowe i przełączniki kontynuują przesyłanie ruchu zgodnie z konfiguracją przesłaną wcześniej przez kontroler, więc klienci pozostają połączeni, a sieć Wi-Fi działa. Przestaje działać jedynie zarządzanie. Tracisz dostęp do pulpitu nawigacyjnego i zbierania statystyk, a także do funkcji działających w czasie rzeczywistym, takich jak uwierzytelnianie w portalu gościnnym lub RADIUS, jeśli kontroler pełni rolę serwera RADIUS.

Gdzie kontroler UniFi przechowuje automatyczne kopie zapasowe?

W używanym tutaj obrazie kontenera trafiają one do /config/data/backup/autobackup, co mapuje się na ścieżkę danych oraz data/backup/autobackup na hoście, jako pliki .unf nazwane zgodnie z wersją i znacznikiem czasu. W niektórych świeżych instalacjach katalog autobackup nie istnieje, przez co zaplanowana kopia zapasowa nie zapisuje niczego, nie zgłaszając przy tym błędu. Sprawdź zawartość tego katalogu dzień po ustawieniu harmonogramu i utwórz go samodzielnie, jeśli jest pusty. Kopiuj pliki poza VPS, ponieważ .unf zawiera konfigurację witryny oraz konta administratorów.