Come eseguire un controller UniFi su un VPS

Cosa fa realmente un controller UniFi su un VPS

Un controller UniFi su un VPS è un unico server di gestione che rimane raggiungibile anche quando i siti gestiti non sono disponibili. Il software è UniFi Network Application di Ubiquiti: un programma Java con un database MongoDB. Configura gli access point e gli switch, memorizza le relative statistiche e fornisce l'interfaccia di amministrazione. Non trasporta il traffico dei client.

Questo aspetto determina dove deve essere eseguito. Se installi il controller su una macchina all'interno dell'ufficio che gestisce, perdi la rete e lo strumento per monitorarla nello stesso momento. Se lo installi su un VPS con un indirizzo pubblico stabile, il controller continua a funzionare, a raccogliere dati e ad adottare dispositivi presenti in più siti da un unico punto. Ha bisogno di disponibilità elevata, non di molta potenza di calcolo.

Quando il controller è offline, gli access point e gli switch adottati continuano a inoltrare il traffico usando la configurazione già inviata. Perdi il dashboard e le statistiche, oltre a tutte le funzioni che richiedono il controller attivo: l'accesso tramite captive portal per gli ospiti oppure RADIUS (remote authentication dial-in user service) se il controller svolge il ruolo di server RADIUS. I client restano connessi.

Quanta RAM richiede un controller UniFi?

2 GB è il minimo e 4 GB è la quantità consigliata. In un unico sistema ci sono due componenti che consumano memoria: Java e MongoDB. Le rispettive esigenze vengono dimensionate in modo indipendente.

L'heap Java è limitato da MEM_LIMIT, che l'immagine del container imposta a 1024 MB per impostazione predefinita. MongoDB costituisce l'altra parte. Il relativo motore di storage WiredTiger dimensiona la cache a metà della RAM oltre 1 GB, oppure a 256 MB, scegliendo il valore maggiore. Su una VPS da 2 GB si tratta di circa 512 MB di cache, 1 GB di heap, la memoria non-heap utilizzata dalla JVM e la memoria del sistema operativo. Il sistema regge fino a una giornata di carico elevato; poi il kernel OOM killer termina uno dei due processi. Dopo un riavvio inspiegabile, esegui dmesg -T | grep -i 'killed process' per verificare se è successo questo. Se disponi di 2 GB, aggiungi un file di swap.

CPU e disco non richiedono molte risorse. Una o due vCPU sono sufficienti per alcune decine di dispositivi. Inizia con 20 GB di spazio disco e controlla l'utilizzo, perché il database cresce in base al numero di client rilevati e al periodo di conservazione delle statistiche. Un controller da solo lascia inutilizzata gran parte di un sistema da 4 GB. Se prevedi di affiancargli un altro servizio, dimensiona prima le risorse per quest'ultimo, perché PhotoPrism e Immich hanno requisiti RAM minimi molto diversi ed entrambi richiedono più memoria del controller.

Una caratteristica della CPU è importante ed è facile non considerarla in un piano economico:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 e versioni successive richiedono AVX (advanced vector extensions) su hardware x86_64. Se il comando non stampa nulla, mongod termina durante l'avvio e il container si riavvia continuamente, perché il binario esegue un'istruzione non supportata dalla CPU. La causa più comune sono gli host Intel Celeron e Pentium meno recenti, oltre agli hypervisor che nascondono i flag della CPU al guest. MongoDB 4.4 è la versione più recente eseguibile senza AVX e l'immagine accetta anche versioni precedenti fino alla 3.6, ma MongoDB 4.4 ha raggiunto il termine del supporto nel February 2024. MongoDB ha pubblicato build 4.4 anche per la correzione di December 2025 relativa a CVE-2025-14847, ma non c'è alcuna garanzia che accada lo stesso per la prossima vulnerabilità; le versioni precedenti sono ancora più arretrate. La soluzione migliore è passare a un host con una CPU più recente. Su una VPS ARM il problema non si pone, perché AVX è un instruction set x86 e entrambe le immagini pubblicano build arm64. Se devi scegliere tra le due architetture, le differenze tra i piani VPS ARM e x86 vanno oltre il prezzo.

Installare UniFi Network Application con Docker Compose

Docker è la soluzione che riduce maggiormente gli imprevisti, perché consente di bloccare MongoDB su una versione supportata dall'applicazione invece di utilizzare quella fornita dalla distribuzione. Se Docker non è ancora installato sul server, installare Docker su un VPS prima di procedere.

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

MongoDB richiede un utente prima che l'applicazione possa autenticarsi. L'immagine ufficiale di MongoDB esegue ogni script presente in /docker-entrypoint-initdb.d al primo avvio. Salvare questo contenuto come ~/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

Lo script viene eseguito solo quando la directory del database è vuota. Se si avvia lo stack una volta con la password errata, l'utente viene creato con quella password. Modificare successivamente il file Compose non cambia nulla, perché lo script non viene più eseguito. Il sintomo è che il container dell'applicazione registra errori di autenticazione MongoDB, mentre l'interfaccia web non viene mai visualizzata. In una nuova installazione, la soluzione consiste nell'arrestare lo stack, eliminare ~/unifi/db e riavviarlo.

Quindi scrivere ~/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

Entrambi i tag delle immagini sono bloccati intenzionalmente. 10.5.67-ls141 era la release corrente dell'applicazione ad agosto 2026. Controllare quindi l'elenco delle release dell'immagine e bloccare la versione corrente al momento dell'installazione. Il tag del database è ancora più importante. MongoDB non aggiorna autonomamente i file dati tra versioni principali. Di conseguenza, mongo:latest prima o poi scaricherà una nuova versione principale, rifiuterà di aprire i file presenti e si riavvierà in un ciclo continuo. Bloccare la versione principale e aggiornarla deliberatamente. UniFi Network 8.1 e versioni successive supportano MongoDB dalla 3.6 alla 7.0. La versione 9.0 ha aggiunto il supporto per MongoDB 8.0.

PUID e PGID devono corrispondere a un utente reale sul server. In caso contrario, i file sotto ./config verranno assegnati a un'identità che non può scriverli. Eseguire id per ottenere i propri valori. come funzionano PUID e PGID nelle immagini container spiega come riconoscere un'incoerenza.

Avviarlo e monitorare i log:

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

docker compose ps dovrebbe mostrare entrambi i container nello stato running. Un unifi-db bloccato in restarting indica un problema AVX, descritto sopra, oppure un problema di permessi su ./db. Quando i log si stabilizzano, controllare i due 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

Qualsiasi codice di stato HTTP indica che il listener è associato alla porta e risponde. Connection refused indica che l'applicazione è ancora in avvio. Al primo avvio, su un VPS di piccole dimensioni, questa operazione richiede uno o due minuti. In alternativa, indica che l'applicazione non è mai stata avviata.

Accedere all’interfaccia di amministrazione senza esporla

La porta 8443 è pubblicata su 127.0.0.1 nel file precedente. Con Docker Engine 28.0.0 o versioni successive, quindi, dall’esterno del VPS non è possibile raggiungere l’interfaccia di amministrazione. Nelle versioni precedenti, altri host dello stesso segmento L2, ad esempio macchine collegate allo stesso switch di rete, possono raggiungere le porte pubblicate su localhost. Esegui docker version e aggiorna prima il server se risulta installata una versione precedente. Inoltra la porta tramite SSH per eseguire la procedura guidata di configurazione:

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

Lascia aperta la sessione e apri https://127.0.0.1:8443 nel browser. Il certificato è autofirmato, quindi il browser mostra un avviso una sola volta. Crea l’account amministratore, assegna un nome al sito e, per ora, ignora l’adozione dei dispositivi.

Un tunnel SSH è sufficiente per un singolo amministratore. Per un team, assegna al VPS un indirizzo privato e configura l’interfaccia affinché sia in ascolto su quell’indirizzo. Una VPN WireGuard sul tuo VPS e un router subnet Tailscale forniscono entrambe un indirizzo raggiungibile solo dagli utenti autorizzati. Modifica la porta pubblicata impostandola su 10.8.0.1:8443:8443 per WireGuard oppure sull’indirizzo assegnato da Tailscale. C’è una limitazione: Docker non può pubblicare una porta su un indirizzo che non esiste ancora. L’interfaccia del tunnel deve quindi essere attiva prima dell’avvio del container, altrimenti il container non si avvia e restituisce un errore di bind.

Perché un dispositivo UniFi remoto non esegue l'adozione

Per impostazione predefinita, un dispositivo UniFi individua il controller tramite broadcast sulla rete locale, sulla porta UDP 10001. Un broadcast non oltrepassa la LAN, quindi un dispositivo in un ufficio di un'altra città non individuerà mai un controller su un VPS. Questa è l'adozione Layer 3 ed è il punto in cui la maggior parte degli utenti si blocca. Il dispositivo funziona e anche il controller funziona. Nessuno ha indicato al dispositivo dove cercare.

Per prima cosa, indica al controller quale indirizzo distribuire. Nelle impostazioni del controller, nella sezione System, è disponibile l'impostazione inform host con un'opzione di override. Impostala sul nome host pubblico o sull'indirizzo IP del tuo VPS. Senza questa impostazione, il controller pubblicizza l'indirizzo rilevato sulla propria interfaccia, che all'interno di una rete Docker bridge è un indirizzo privato come 172.18.0.3. Il dispositivo riceve quell'indirizzo, non può instradare il traffico verso di esso e riprende la ricerca.

Poi configura il dispositivo affinché utilizzi quell'indirizzo. Connettiti via SSH al dispositivo sulla LAN remota. Un dispositivo con le impostazioni di fabbrica accetta il nome utente ubnt con la password ubnt:

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

Il firmware più recente del dispositivo apre un menu invece di una shell. Esegui lo stesso comando in un'unica riga:

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

Il dispositivo ora appare nel controller ed è pronto per l'adozione. Fai clic su Adopt; lo stato passa a Adopting. Questo è il passaggio che spesso sorprende: di solito devi eseguire set-inform una seconda volta. Il dispositivo si riavvia per eseguire il provisioning e torna all'URL inform salvato nella propria configurazione, che il controller non ha ancora finito di sostituire. Eseguire di nuovo il comando mentre lo stato è Adopting completa il passaggio di consegne. Digita info sul dispositivo per visualizzare l'URL inform e lo stato attualmente memorizzati.

Se il dispositivo era stato adottato in precedenza da un altro controller, set-inform da solo non completa l'operazione, perché il dispositivo conserva ancora le credenziali di quel controller. Ripristina prima le impostazioni di fabbrica, utilizzando il pulsante di reset oppure set-default tramite SSH con le vecchie credenziali.

Per più di una manciata di dispositivi, utilizza invece DHCP. L'opzione 43 del DHCP (dynamic host configuration protocol) trasporta un valore specifico del produttore e i dispositivi UniFi leggono l'URL inform dalla sottoopzione 2. Crea la stringa esadecimale su un qualsiasi sistema 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"

Per http://192.168.3.10:8080/inform, una stringa di 31 byte, il comando stampa 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Incolla il risultato nel campo dell'opzione DHCP 43 del router come valore esadecimale. Ogni dispositivo che si avvia su quella rete apprende quindi l'indirizzo del controller dalla propria lease, senza alcun accesso SSH. Le guide più datate indicano invece la sottoopzione 1, 0104 seguita dai 4 byte di un indirizzo IPv4 in formato esadecimale; i dispositivi accettano ancora questa forma.

Esiste una terza possibilità se gestisci il DNS del sito. Durante l'avvio, un dispositivo UniFi tenta di risolvere il nome host unifi; un record A per unifi che punti all'indirizzo del VPS consente di adottare i dispositivi senza intervenire singolarmente su ciascuno. Questa soluzione funziona solo se controlli il resolver effettivamente utilizzato dai dispositivi.

Quali porte UniFi aprire e quali mantenere private

Per l'adozione e la gestione quotidiana, due porte devono essere raggiungibili da un sito remoto.

• TCP 8080 è il canale inform e ogni dispositivo adottato si connette a questa porta. Il payload è crittografato con AES usando una chiave che il controller ha fornito al dispositivo durante l'adozione. Per questo l'impostazione normale prevede HTTP semplice.
• UDP 3478 è STUN (session traversal utilities for NAT). I dispositivi lo usano per mantenere un percorso verso il controller.

Alcune funzioni richiedono altre porte. Il riferimento alle porte di Ubiquiti indica anche TCP 5671 per il logging di Traffic Flow dai gateway UXG adottati su reti L2 o L3. Se un sito contiene un UXG che invia dati a questo controller e vuoi raccogliere questi log, apri anche la porta 5671 verso quel sito.

Su un VPS, tutte le altre porte devono rimanere chiuse.

• TCP 8443 è l'interfaccia di amministrazione. Questa porta non deve mai essere pubblica. Contiene la configurazione di tutti i siti gestiti dal controller, protetta da un'unica password.
• UDP 10001 e UDP 1900 sono usate per il rilevamento tramite broadcast. I broadcast non attraversano Internet, quindi aprirle non serve.
• TCP 8880 e TCP 8843 gestiscono i redirect del portale ospiti. Aprile solo se utilizzi un portale ospiti.
• TCP 6789 è usata dal test di velocità mobile e UDP 5514 dal syslog remoto. Aggiungile quando utilizzi queste funzioni.
• TCP 27117 è MongoDB. Nel file compose precedente il database non pubblica alcuna porta, quindi esiste soltanto sulla rete Docker interna. Mantieni questa configurazione.

Se i tuoi siti hanno indirizzi pubblici statici, consenti soltanto quelli:

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

le nozioni di base su ufw per un firewall VPS descrive la configurazione con deny predefinito richiesta da queste regole.

Qui esiste un problema che spesso viene trascurato. Le porte pubblicate da Docker aggirano ufw. La pubblicazione di una porta scrive direttamente regole NAT e di forwarding in iptables, e il traffico viene filtrato nella catena gestita da Docker, non nella catena INPUT gestita da ufw. Di conseguenza, ufw deny 8443 può sembrare corretto in ufw status mentre la porta resta aperta a Internet. Verifica da un'altra macchina, mai dal VPS stesso:

nc -vz vps.example.com 8443

Un rifiuto della connessione o un timeout è il risultato atteso. Se la connessione riesce, la porta è pubblica indipendentemente da ciò che indica ufw. La correzione affidabile è già presente nel file compose: pubblica la porta su 127.0.0.1 oppure su un indirizzo del tunnel, così Docker non la associa mai all'interfaccia pubblica. Funziona anche una regola nella catena DOCKER-USER, ma l'associazione è più semplice e un errore nell'ordine delle regole non può annullarla.

Informazioni sugli installer ufficiali di Ubiquiti

Ubiquiti pubblica un pacchetto Debian per Network Application. A ottobre 2026, il relativo help center definisce però questo percorso legacy e indica UniFi OS Server come nuovo standard per il self-hosting. Il pacchetto funziona, ma sulle versioni attuali di Ubuntu introduce una questione relativa a MongoDB a cui la distribuzione non fornisce più una risposta: Ubuntu 22.04 e 24.04 non includono alcun pacchetto per il server MongoDB. Di conseguenza, è necessario aggiungere manualmente il repository di MongoDB e verificare la compatibilità tra le versioni. Il container riportato sopra esegue questo abbinamento in un unico tag bloccato. Per questo è il percorso utilizzato qui.

Il prodotto self-hosted più recente di Ubiquiti è UniFi OS Server. Esegue le applicazioni UniFi in container Podman e fornisce lo stesso UniFi OS presente nelle console hardware dell'azienda. A ottobre 2026, Ubiquiti indica come requisiti una CPU x86-64, Ubuntu 24.04 o versioni successive oppure Debian 13 o versioni successive, Podman 4.9.3 o versioni successive con slirp4netns 1.2 o versioni successive, almeno 2 GB di RAM e 10 GB di spazio libero. Il link dell'installer nella pagina Releases o Download di Ubiquiti è specifico per la versione: fai clic con il pulsante destro sul download, copia l'indirizzo del link e scaricalo con curl -O o wget. Ogni release ha un URL distinto. Una guida può quindi fissare una versione, ma non può fornire un link che punti sempre all'ultima versione. L'installer configura un servizio systemd chiamato uosserver, che puoi arrestare e avviare con systemctl. Sceglilo se vuoi usare il packaging ufficiale del fornitore. Scegli lo stack di container se vuoi bloccare autonomamente le versioni e mantenere il server disponibile per altre attività.

Dove si trovano i backup di UniFi e come copiarli fuori dal server

Il controller crea i propri backup secondo la pianificazione configurata in Settings, nella sezione dei backup, insieme al numero di copie da conservare. I file vengono salvati in /config/data/backup/autobackup all’interno del container, che sul server host corrisponde a ~/unifi/config/data/backup/autobackup, con nomi simili a autobackup_10.5.67_20260813_1200_1755086400004.unf.

Verificate che i file vengano effettivamente creati:

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

Una directory vuota il giorno successivo alla configurazione della pianificazione indica un problema noto nelle nuove installazioni del container. L’applicazione si aspetta che esista la directory autobackup, ma non la crea. Di conseguenza, il job pianificato non scrive alcun file senza generare errori visibili. Create la directory con lo stesso utente utilizzato dal container, quindi attendete la successiva esecuzione:

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

Un file .unf contiene la configurazione dei siti e gli account amministrativi, quindi va trattato come una chiave crittografica. Copiate i backup su una macchina sotto il vostro controllo e manteneteli riservati:

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

Il ripristino richiede un solo passaggio. La prima pagina della procedura guidata di configurazione di una nuova installazione permette di ripristinare un file di backup; un controller in esecuzione offre la stessa funzione nella relativa pagina delle impostazioni. Ripristinate il backup sulla stessa versione o su una versione più recente. Un backup creato da un’applicazione più recente rispetto a quella in cui lo state ripristinando viene rifiutato. Per questo motivo, registrate il numero di versione insieme al file.

Cosa può compromettere un aggiornamento del controller

Esegui un backup manuale e scaricalo prima di ogni aggiornamento. Poi:

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

Il database è il primo componente a cedere. Modificare il tag mongo impostandolo su una nuova versione principale nella stessa modifica in cui aggiorni l'applicazione è il modo più rapido per ottenere un controller che non si avvia, perché MongoDB non apre i file di dati di una versione principale diversa senza un aggiornamento pianificato per fasi. Aggiorna l'applicazione separatamente. Aggiorna MongoDB in un secondo momento, una versione principale alla volta, dopo aver preparato un backup recente.

La memoria è il problema successivo. Una release più recente richiede un heap più grande. Se l'applicazione si avvia, funziona per alcuni minuti e poi si arresta, aumenta MEM_LIMIT e MEM_STARTUP a 1536 o 2048, quindi riavvia. dmesg -T | grep -i 'killed process' sull'host conferma se è stato il kernel a terminarla.

Il firmware dei dispositivi è il rischio che spesso viene dimenticato. Dopo essersi aggiornato, il controller propone gli aggiornamenti del firmware per i dispositivi adottati. Non accettarli nella stessa sessione. Se un aggiornamento del dispositivo e uno del controller si sovrappongono e il collegamento tra i due viene interrotto, il dispositivo può restare parzialmente configurato. In questo caso dovrai tornare a set-inform tramite SSH su hardware situato in un altro edificio.

La finestra di aggiornamento è meno problematica di quanto possa sembrare. I dispositivi continuano a inoltrare il traffico mentre il controller si riavvia, quindi gli utenti non notano interruzioni. Si interrompono invece il portale guest e RADIUS, se sono erogati dal controller. Scegli quindi un orario in cui nessuno dei due sia in uso. È utile sapere se un controller si arresta senza messaggi alle 3 del mattino. Configura quindi un monitor di stato Uptime Kuma sulla porta 8080 e lascia che sia lui a segnalartelo.

L’alternativa trasparente: la console in hosting di Ubiquiti

Ubiquiti offre la stessa funzione come servizio. A ottobre 2026, il negozio statunitense di Ubiquiti propone il servizio come Official UniFi Hosting, a partire da $29 al mese, con la gestione di un massimo di 1,000 dispositivi UniFi Network su un server gestito da Ubiquiti. L’applicazione self-hosted appena installata è gratuita e non prevede alcun abbonamento.

Scegli la console in hosting se gestisci un solo sito e preferisci pagare invece di occuparti delle patch. Scegli un VPS se gestisci più siti, oppure se vuoi eseguire il controller all’interno di una rete sotto il tuo controllo e condividere il server con gli altri servizi che utilizzi. Su piccola scala, la differenza di costo è concreta, ma non è l’unico fattore da valutare: la disponibilità di una console in hosting dipende da un’infrastruttura gestita da altri, mentre il VPS è sotto la tua responsabilità, anche quando il disco si riempie durante la notte. Se in ogni caso il server deve ripagare i propri costi, quali altri servizi puoi eseguire su un VPS è il prossimo elenco da consultare.

FAQ

Perché il mio dispositivo UniFi non riesce ad adottare un controller su un VPS?

I dispositivi individuano i controller trasmettendo broadcast sulla porta UDP 10001. Un broadcast non oltrepassa mai la rete locale, quindi un dispositivo in una sede remota non può trovare un controller su Internet pubblico. Imposta l'override dell'host inform nelle impostazioni di sistema del controller sul nome host del VPS, quindi indirizza il dispositivo a tale host con ssh ubnt@<device-ip> seguito da set-inform http://vps.example.com:8080/inform. Se il dispositivo resta nello stato Adopting, esegui di nuovo set-inform mentre si trova in quello stato. Se in precedenza lo ha adottato un altro controller, ripristinalo prima alle impostazioni di fabbrica, perché conserva ancora le credenziali del vecchio controller.

Quanta RAM richiede un controller UniFi self-hosted?

2 GB sono il minimo operativo; 4 GB offrono un margine adeguato. L'applicazione usa Java e MongoDB, che dimensionano la memoria separatamente: per impostazione predefinita, l'immagine del container limita l'heap Java a 1024 MB, mentre la cache WiredTiger di MongoDB utilizza metà della RAM oltre 1 GB. Su x86_64, verifica anche che la CPU esponga AVX con grep -m1 -o avx /proc/cpuinfo, perché MongoDB 5.0 e versioni successive non si avviano senza questa estensione e il container del database entra in un ciclo di riavvio.

Devo esporre la porta 8443 a Internet?

No. La porta 8443 è l'interfaccia di amministrazione e contiene la configurazione di ogni sito gestito dal controller. Pubblicala su 127.0.0.1 con Docker Engine 28.0.0 o versioni successive e raggiungila con ssh -L 8443:127.0.0.1:8443 you@vps.example.com, oppure associane l'ascolto a un indirizzo WireGuard o Tailscale. Per l'adozione e la gestione, i siti devono poter raggiungere la porta TCP 8080 e la porta UDP 3478, oltre alla porta TCP 5671 se un gateway UXG invia i log Traffic Flow al controller. Se gli indirizzi pubblici dei siti sono statici, puoi limitare l'accesso a tali indirizzi. Ricorda che una porta pubblicata da Docker non viene filtrata da ufw. Esegui quindi il test da una macchina esterna invece di affidarti a ufw status.

La rete smette di funzionare se il controller sul VPS non è disponibile?

No. Gli access point e gli switch adottati continuano a inoltrare il traffico usando la configurazione già distribuita dal controller. I client restano quindi connessi e il Wi-Fi continua a funzionare. Si interrompe soltanto la gestione. Perdi il dashboard e la raccolta delle statistiche, oltre alle funzioni in tempo reale fornite dal controller, come l'autenticazione tramite il captive portal per gli ospiti o RADIUS quando il controller svolge il ruolo di server RADIUS.

Dove salva il controller UniFi i backup automatici?

Nell'immagine del container utilizzata in questa procedura, i backup vengono salvati in /config/data/backup/autobackup. Questo percorso corrisponde al percorso dei dati più data/backup/autobackup sull'host, come file .unf denominati in base alla versione e a un timestamp. In alcune installazioni nuove la directory autobackup non esiste. In tal caso il backup pianificato non scrive nulla senza segnalare errori. Il giorno dopo aver impostato la pianificazione, elenca quindi il contenuto della directory e creala manualmente se è vuota. Copia i file fuori dal VPS, perché un .unf contiene la configurazione dei siti e gli account amministratore.