Installer un contrôleur UniFi sur un VPS

Ce que fait réellement un contrôleur UniFi sur un VPS

Un contrôleur UniFi sur un VPS est un serveur de gestion qui reste accessible lorsque les sites qu’il gère deviennent indisponibles. Le logiciel est l’UniFi Network Application d’Ubiquiti : un programme Java avec une base de données MongoDB. Il configure vos points d’accès et vos switches, stocke leurs statistiques et fournit l’interface d’administration. Il ne transporte pas le trafic des clients.

Ce dernier point détermine où l’installer. Si vous placez le contrôleur sur une machine située dans le bureau qu’il gère, vous perdez le réseau et l’outil permettant d’examiner ce réseau au même moment. Si vous le placez sur un VPS avec une adresse publique stable, il continue de fonctionner et de collecter les données, et peut adopter des équipements sur plusieurs sites depuis un emplacement unique. Il a besoin de disponibilité, pas de puissance de calcul.

Lorsque le contrôleur est hors ligne, les points d’accès et les switches adoptés continuent de transférer le trafic avec la configuration qui leur a déjà été poussée. Vous perdez le tableau de bord et les statistiques, ainsi que toute fonction qui nécessite que le contrôleur soit actif : l’authentification via un portail captif ou RADIUS (remote authentication dial-in user service) si le contrôleur est votre serveur RADIUS. Les clients restent connectés.

De combien de RAM un contrôleur UniFi a-t-il besoin ?

Deux GB constituent le minimum, et 4 GB est la capacité à choisir. Une seule machine héberge deux consommateurs de mémoire : Java et MongoDB. Ils dimensionnent leur consommation indépendamment l’un de l’autre.

La heap Java est plafonnée par MEM_LIMIT, que l’image du conteneur définit par défaut à 1024 MB. MongoDB constitue l’autre moitié. Son moteur de stockage WiredTiger dimensionne son cache à la moitié de la RAM au-delà de 1 GB, ou à 256 MB si cette valeur est supérieure. Sur un VPS de 2 GB, cela représente environ 512 MB de cache, une heap de 1 GB, la mémoire non-heap propre à la JVM et le système d’exploitation. Cela fonctionne jusqu’à une journée chargée, puis l’oom-killer du kernel arrête l’un des deux processus. Après tout redémarrage inexpliqué, exécutez dmesg -T | grep -i 'killed process' pour vérifier si c’est ce qui s’est produit. Ajoutez un fichier swap si vous ne disposez que de 2 GB.

Le CPU et le disque sont peu sollicités. Un ou deux vCPU suffisent pour quelques dizaines d’équipements. Commencez avec 20 GB de disque et surveillez son utilisation, car la base de données grossit selon le nombre de clients visibles et la durée de conservation des statistiques. Un contrôleur seul laisse la majeure partie d’une machine de 4 GB inutilisée. Si vous prévoyez de lui ajouter un autre service, dimensionnez d’abord la machine pour ce service, car PhotoPrism et Immich ont des besoins minimaux en RAM très différents et chacun demande plus de mémoire que le contrôleur.

Une fonctionnalité du CPU est importante et facile à manquer avec une offre bon marché :

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 et les versions ultérieures nécessitent AVX (advanced vector extensions) sur le matériel x86_64. Si cette commande n’affiche rien, mongod s’arrête pendant le démarrage et le conteneur redémarre en boucle, car le binaire exécute une instruction absente du CPU. Les hôtes équipés d’anciens Intel Celeron et Pentium sont la cause habituelle. Les hyperviseurs qui masquent les flags CPU au guest sont également concernés. MongoDB 4.4 est la dernière release à fonctionner sans AVX. L’image accepte aussi les versions plus anciennes, jusqu’à 3.6, mais 4.4 est arrivée en fin de vie en février 2024. MongoDB a bien publié des builds 4.4 pour son correctif de décembre 2025 concernant CVE-2025-14847, mais rien ne garantit la même prise en charge pour la prochaine vulnérabilité. Les releases plus anciennes sont encore plus en retard. Migrer vers un hôte équipé d’un CPU plus récent est la meilleure solution. Sur un VPS ARM, la question ne se pose pas, car AVX est un jeu d’instructions x86 et les deux images publient des builds arm64. Si vous devez choisir entre les deux, les différences entre les offres de VPS ARM et x86 vont au-delà du prix.

Installer l’application UniFi Network avec Docker Compose

Docker est la solution qui réserve le moins de surprises, car il permet de verrouiller MongoDB sur une version prise en charge par l’application au lieu d’utiliser celle fournie par votre distribution. Si Docker n’est pas encore installé sur le serveur, installez Docker sur un VPS au préalable.

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

MongoDB a besoin d’un utilisateur pour que l’application puisse s’y connecter. L’image officielle MongoDB exécute au premier démarrage tout script trouvé dans /docker-entrypoint-initdb.d. Enregistrez ce contenu dans ~/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

Ce script s’exécute uniquement lorsque le répertoire de la base de données est vide. Si vous démarrez la stack une première fois avec le mauvais mot de passe, l’utilisateur est créé avec ce mauvais mot de passe. Modifier ensuite le fichier Compose ne change rien, car le script ne s’exécute plus. Le symptôme est que le conteneur de l’application journalise des échecs d’authentification MongoDB, tandis que l’interface web n’apparaît jamais. Sur une installation neuve, arrêtez la stack, supprimez ~/unifi/db, puis redémarrez-la.

Écrivez ensuite ~/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

Les deux tags d’image sont verrouillés volontairement. 10.5.67-ls141 était la version actuelle de l’application en août 2026. Consultez donc la liste des releases de l’image et verrouillez la version disponible au moment de votre installation. Le tag de la base de données est plus important. MongoDB ne met pas automatiquement à niveau ses fichiers de données entre versions majeures. mongo:latest finira donc par télécharger une nouvelle version majeure, refuser d’ouvrir les fichiers existants, puis redémarrer en boucle. Verrouillez la version majeure et faites évoluer MongoDB volontairement. UniFi Network 8.1 et les versions ultérieures prennent en charge MongoDB 3.6 à 7.0. La version 9.0 a ajouté la prise en charge de MongoDB 8.0.

PUID et PGID doivent correspondre à un utilisateur réel sur l’hôte. Sinon, les fichiers sous ./config appartiennent à une identité qui ne peut pas les modifier. Exécutez id pour obtenir vos valeurs. fonctionnement de PUID et PGID dans les images de conteneur explique à quoi ressemble un problème de correspondance.

Démarrez la stack et surveillez les journaux :

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

docker compose ps doit afficher les deux conteneurs avec l’état running. Un unifi-db bloqué dans restarting indique soit le problème AVX décrit plus haut, soit un problème de permissions sur ./db. Une fois les journaux stabilisés, vérifiez les deux listeners :

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

N’importe quel code d’état HTTP indique que le listener est lié et répond. Connection refused signifie que l’application est encore en cours de démarrage. Sur un petit VPS, ce premier démarrage peut prendre une à deux minutes. Il peut aussi indiquer que l’application n’a jamais démarré.

Accéder à l’interface d’administration sans l’exposer

Le port 8443 est publié sur 127.0.0.1 dans le fichier ci-dessus. Avec Docker Engine 28.0.0 ou une version ultérieure, rien en dehors du VPS ne peut donc atteindre l’interface d’administration. Dans les versions antérieures, d’autres hôtes du même segment L2, par exemple des machines connectées au même switch réseau, peuvent atteindre les ports publiés sur localhost. Exécutez donc docker version et effectuez d’abord la mise à niveau si le serveur indique une version antérieure. Transférez ensuite l’interface via SSH pour lancer l’assistant de configuration :

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

Laissez cette session ouverte et accédez à https://127.0.0.1:8443. Le certificat est auto-signé, donc le navigateur affiche un avertissement une seule fois. Créez le compte administrateur, nommez le site et ignorez pour l’instant l’adoption des appareils.

Un tunnel SSH convient pour un seul administrateur. Pour une équipe, attribuez une adresse privée au VPS et liez plutôt l’interface à cette adresse. Un VPN WireGuard sur votre propre VPS et un routeur de sous-réseau Tailscale fournissent tous deux une adresse accessible uniquement par vos utilisateurs. Remplacez le port publié par 10.8.0.1:8443:8443 pour WireGuard, ou par l’adresse attribuée par Tailscale. Attention : Docker ne peut pas publier un port sur une adresse qui n’existe pas encore. L’interface du tunnel doit donc être active avant le démarrage du conteneur, sinon celui-ci échoue avec une erreur de bind.

Pourquoi un appareil UniFi distant ne s’adopte pas

Par défaut, un appareil UniFi trouve son contrôleur en diffusant sur le réseau local, via le port UDP 10001. Une diffusion ne quitte pas le LAN. Un appareil installé dans un bureau situé dans une autre ville ne découvrira donc jamais un contrôleur exécuté sur un VPS. Il s’agit de l’adoption de couche 3, et c’est là que la plupart des utilisateurs restent bloqués. L’appareil fonctionne et le contrôleur fonctionne. Rien n’a indiqué à l’appareil où chercher.

Commencez par indiquer au contrôleur quelle adresse transmettre. Dans les Settings du contrôleur, dans la section System, vous trouverez le paramètre inform host avec une option override. Définissez-le sur le hostname public ou l’adresse IP de votre VPS. Sinon, le contrôleur annonce l’adresse qu’il voit sur sa propre interface. Dans un réseau Docker bridge, il s’agit d’une adresse privée comme 172.18.0.3. L’appareil reçoit cette adresse, ne peut pas l’atteindre par routage, puis recommence sa recherche.

Indiquez ensuite cette adresse à l’appareil. Connectez-vous en SSH à l’appareil depuis le LAN distant. Un appareil avec sa configuration d’usine accepte le nom d’utilisateur ubnt et le mot de passe ubnt :

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

Les versions récentes du firmware de l’appareil vous placent dans un menu au lieu d’ouvrir un shell. Exécutez la même commande en une seule ligne :

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

L’appareil apparaît alors dans le contrôleur et peut être adopté. Cliquez sur Adopt. Son état passe à Adopting. Voici le point qui surprend la plupart des utilisateurs : vous devez généralement exécuter set-inform une deuxième fois. L’appareil redémarre pour lancer le provisioning et utilise de nouveau l’URL inform enregistrée dans sa propre configuration, que le contrôleur n’a pas encore fini de remplacer. Exécutez à nouveau la commande lorsque l’état indique Adopting pour terminer le transfert. Saisissez info sur l’appareil pour afficher l’URL inform et l’état actuellement enregistrés.

Si l’appareil a déjà été adopté par un autre contrôleur, set-inform ne suffit pas, car il contient encore les identifiants de cet ancien contrôleur. Rétablissez d’abord sa configuration d’usine, avec le bouton de reset ou avec set-default en SSH, en utilisant les anciens identifiants.

Pour plus de quelques appareils, utilisez plutôt DHCP. DHCP (dynamic host configuration protocol) utilise l’option 43 pour transmettre une valeur spécifique au constructeur. Les appareils UniFi lisent l’URL inform dans la sous-option 2. Construisez la chaîne hexadécimale sur n’importe quelle machine 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"

Pour http://192.168.3.10:8080/inform, une chaîne de 31 octets, cette commande affiche 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Collez le résultat dans le champ DHCP option 43 de votre routeur en tant que valeur hexadécimale. Chaque appareil qui démarre sur ce réseau apprend ensuite l’adresse du contrôleur depuis son lease, sans aucune connexion SSH. Les anciens guides indiquent plutôt la sous-option 1, 0104 suivie des 4 octets d’une adresse IPv4 en hexadécimal. Les appareils acceptent encore ce format.

Une troisième méthode consiste à utiliser le DNS du site. Au démarrage, un appareil UniFi tente de résoudre le hostname unifi. Un enregistrement A pour unifi, pointant vers l’adresse de votre VPS, permet donc d’adopter les appareils sans intervention sur chaque appareil. Cette méthode ne fonctionne que si vous contrôlez le resolver effectivement utilisé par les appareils.

Ports UniFi à ouvrir et ports à garder privés

Deux ports doivent être accessibles depuis un site distant pour l’adoption et l’administration quotidienne.

• TCP 8080 est le canal inform, auquel chaque équipement adopté se connecte. La charge utile est chiffrée en AES avec une clé que le controller a fournie à l’équipement pendant l’adoption. C’est pourquoi HTTP simple est le réglage normal ici.
• UDP 3478 est utilisé par STUN (session traversal utilities for NAT). Les équipements l’utilisent pour maintenir un chemin vers le controller.

Certaines fonctionnalités nécessitent d’autres ports. La référence des ports d’Ubiquiti ajoute TCP 5671 pour la journalisation Traffic Flow des gateways UXG adoptées sur des réseaux L2 ou L3. Si un site possède un UXG qui envoie ses données à ce controller et que vous voulez ces journaux, ouvrez également 5671 vers ce site.

Tous les autres ports restent fermés sur un VPS.

• TCP 8443 est l’interface d’administration. Ce port ne doit jamais être public. Il contient la configuration de tous les sites gérés par le controller, protégée par un seul mot de passe.
• UDP 10001 et UDP 1900 servent à la découverte par broadcast. Les broadcasts ne traversent pas Internet. Les ouvrir ne sert donc à rien.
• TCP 8880 et TCP 8843 servent aux redirections du guest portal. Ouvrez-les uniquement si vous utilisez un guest portal.
• TCP 6789 sert au speed test mobile et UDP 5514 au syslog distant. Ajoutez-les lorsque vous les utilisez.
• TCP 27117 est MongoDB. Dans le fichier compose ci-dessus, la base de données ne publie aucun port. Elle existe donc uniquement sur le réseau Docker interne. Conservez cette configuration.

Si vos sites disposent d’adresses publiques statiques, n’autorisez que celles-ci :

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

les bases d’ufw pour le firewall d’un VPS expliquent la configuration de refus par défaut supposée par ces règles.

Un piège revient régulièrement. Les ports publiés par Docker contournent ufw. La publication d’un port écrit directement des règles de NAT et de forwarding dans iptables. Ce trafic est filtré dans la propre chaîne de Docker, et non dans la chaîne INPUT gérée par ufw. Ainsi, ufw deny 8443 semble correct dans ufw status, alors que le port reste ouvert à tout Internet. Testez depuis une autre machine, jamais depuis le VPS lui-même :

nc -vz vps.example.com 8443

Un refus de connexion ou un timeout est le résultat attendu. Si la connexion aboutit, le port est public, quelle que soit la configuration d’ufw. La correction fiable est déjà présente dans le fichier compose : publiez le port sur 127.0.0.1 ou sur l’adresse d’un tunnel, afin que Docker ne le lie jamais à l’interface publique. Une règle dans la chaîne DOCKER-USER fonctionne également, mais le binding est plus simple et une erreur d’ordre des règles ne peut pas l’annuler.

Et les installateurs d’Ubiquiti ?

Ubiquiti publie un paquet Debian pour la Network Application. Depuis octobre 2026, son centre d’aide considère toutefois cette méthode comme ancienne et présente UniFi OS Server comme la nouvelle méthode standard pour l’auto-hébergement. Le paquet fonctionne, mais il pose une question concernant MongoDB sur les versions récentes d’Ubuntu. Ubuntu 22.04 et 24.04 ne fournissent plus de paquet serveur MongoDB. Vous devez donc ajouter le dépôt de MongoDB et faire correspondre les versions manuellement. Le conteneur ci-dessus effectue cette correspondance dans un tag figé. C’est pourquoi cette méthode est utilisée ici.

Le nouveau produit d’Ubiquiti pour l’auto-hébergement est UniFi OS Server. Il exécute les applications UniFi dans des conteneurs Podman et fournit le même UniFi OS que les consoles matérielles de la marque. Depuis octobre 2026, Ubiquiti indique comme prérequis un processeur x86-64, Ubuntu 24.04 ou une version ultérieure, ou Debian 13 ou une version ultérieure, Podman 4.9.3 ou une version ultérieure avec slirp4netns 1.2 ou une version ultérieure, au moins 2 GB de RAM et 10 GB d’espace de stockage libre. Le lien vers l’installateur présent sur la page Releases ou Download d’Ubiquiti dépend de la version. Faites un clic droit sur le téléchargement, copiez l’adresse du lien, puis récupérez le fichier avec curl -O ou wget. Chaque version possède sa propre URL. Un guide peut donc figer une version, mais ne peut pas fournir un lien qui pointe toujours vers la dernière version. L’installateur configure un service systemd appelé uosserver. Vous pouvez l’arrêter et le démarrer avec systemctl. Choisissez cette méthode si vous voulez utiliser le packaging fourni par l’éditeur. Choisissez la stack de conteneurs si vous préférez figer vous-même les versions et conserver le serveur disponible pour d’autres tâches.

Où se trouvent les sauvegardes UniFi et comment les sortir du serveur

Le controller écrit ses propres sauvegardes selon la planification définie dans Settings, dans la section dédiée aux sauvegardes, ainsi que le nombre de sauvegardes à conserver. Les fichiers sont placés dans /config/data/backup/autobackup à l’intérieur du conteneur, ce qui correspond à ~/unifi/config/data/backup/autobackup sur l’hôte. Leur nom suit le format autobackup_10.5.67_20260813_1200_1755086400004.unf.

Vérifiez qu’ils sont bien créés :

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

Un répertoire vide le lendemain de la définition d’une planification est un problème connu sur les installations de conteneurs neuves. L’application attend que le répertoire autobackup existe, mais ne le crée pas. La tâche planifiée n’écrit donc rien et ne génère aucun message. Créez-le vous-même avec le même utilisateur que celui utilisé par le conteneur, puis attendez la prochaine exécution :

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

Un fichier .unf contient la configuration des sites et les comptes administrateur. Traitez-le comme une clé cryptographique. Récupérez des copies sur une machine que vous contrôlez et gardez-les privées :

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

La restauration s’effectue en une seule étape. La première page de l’assistant de configuration d’une nouvelle installation propose de restaurer une sauvegarde depuis un fichier. Un controller en fonctionnement permet également de restaurer une sauvegarde depuis la même page de paramètres. Restaurez vers la même version ou vers une version plus récente. Une sauvegarde créée par une application plus récente que celle dans laquelle vous la restaurez est refusée. C’est pourquoi vous devez enregistrer le numéro de version avec le fichier.

Ce qu’une mise à niveau du contrôleur peut interrompre

Effectuez une sauvegarde manuelle et téléchargez-la avant chaque mise à niveau. Ensuite :

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

La base de données est le premier élément susceptible de tomber en panne. Modifier le tag mongo pour utiliser une nouvelle version majeure dans la même modification que l’application est le moyen le plus rapide de se retrouver avec un contrôleur qui ne démarre plus, car MongoDB n’ouvre pas les fichiers de données d’une autre version majeure sans mise à niveau par étapes. Mettez d’abord l’application à niveau seule. Faites ensuite évoluer MongoDB séparément, une version majeure à la fois, avec une sauvegarde récente à disposition.

La mémoire est le deuxième point à surveiller. Une version plus récente nécessite un heap plus important. Si l’application démarre, fonctionne quelques minutes, puis s’arrête, augmentez MEM_LIMIT et MEM_STARTUP à 1536 ou 2048, puis redémarrez. La commande dmesg -T | grep -i 'killed process' sur l’hôte confirme si c’est bien le kernel qui l’arrête.

Le firmware des appareils est le risque que l’on oublie souvent. Après sa propre mise à niveau, le contrôleur propose des mises à niveau du firmware des appareils adoptés. Ne les acceptez pas au cours de la même session. Si une mise à niveau d’appareil et une mise à niveau du contrôleur se chevauchent et que la liaison entre eux est interrompue, l’appareil peut rester partiellement provisionné. Vous devrez alors revenir à set-inform via SSH sur un équipement situé dans un autre bâtiment.

La fenêtre de mise à niveau est moins perturbatrice qu’il n’y paraît. Les appareils continuent de transmettre le trafic pendant le redémarrage du contrôleur, de sorte que les utilisateurs ne voient rien. En revanche, le portail invité et RADIUS s’arrêtent si le contrôleur les fournit. Choisissez donc un créneau où aucun des deux n’est utilisé. Il est utile de savoir si un contrôleur s’arrête silencieusement à 3 a.m. Configurez donc un moniteur d’état Uptime Kuma pour surveiller le port 8080 et vous alerter.

L’alternative honnête : la console hébergée d’Ubiquiti

Ubiquiti propose le même service sous forme d’offre hébergée. En octobre 2026, la boutique américaine d’Ubiquiti le vend sous le nom Official UniFi Hosting, à partir de 29 dollars par mois, pour gérer jusqu’à 1,000 appareils UniFi Network sur un serveur exploité par Ubiquiti. L’application auto-hébergée que vous venez d’installer est gratuite et ne nécessite aucun abonnement.

Choisissez la console hébergée si vous gérez un seul site et préférez payer plutôt que d’appliquer les mises à jour. Choisissez un VPS si vous gérez plusieurs sites, si vous voulez que le contrôleur se trouve sur un réseau que vous contrôlez ou si vous souhaitez partager une machine avec les autres services que vous exploitez. La différence de coût à petite échelle est réelle, mais ce n’est pas le seul critère : la disponibilité d’une console hébergée dépend de quelqu’un d’autre, tandis que votre VPS vous appartient, y compris la nuit où son disque se remplit. Si la machine doit être rentabilisée dans les deux cas, les autres services que vous pouvez exécuter sur un VPS est la prochaine liste à consulter.

FAQ

Pourquoi mon équipement UniFi ne s’adopte-t-il pas par un contrôleur sur un VPS ?

Les équipements découvrent les contrôleurs en diffusant sur le port UDP 10001. Une diffusion ne quitte jamais le réseau local. Un équipement situé sur un site distant ne peut donc pas trouver un contrôleur sur Internet. Définissez la surcharge de l’hôte inform dans les paramètres système du contrôleur avec le nom d’hôte de votre VPS, puis indiquez-le à l’équipement avec ssh ubnt@<device-ip> suivi de set-inform http://vps.example.com:8080/inform. Si l’équipement reste dans l’état Adopting, exécutez de nouveau set-inform pendant qu’il se trouve dans cet état. Si un autre contrôleur l’a déjà adopté, réinitialisez-le d’abord aux paramètres d’usine, car il conserve encore les identifiants de l’ancien contrôleur.

Quelle quantité de RAM faut-il à un contrôleur UniFi auto-hébergé ?

2 GB constituent le minimum fonctionnel, et 4 GB offrent une marge confortable. L’application repose sur Java et MongoDB. Chacun réserve sa mémoire séparément : l’image du conteneur limite par défaut le heap Java à 1024 MB, tandis que le cache WiredTiger de MongoDB utilise la moitié de la RAM au-delà de 1 GB. Sur x86_64, vérifiez également que le CPU expose AVX avec grep -m1 -o avx /proc/cpuinfo, car MongoDB 5.0 et les versions ultérieures ne démarrent pas sans cette fonctionnalité et le conteneur de base de données redémarre en boucle.

Dois-je exposer le port 8443 sur Internet ?

Non. Le port 8443 correspond à l’interface d’administration et contient la configuration de tous les sites gérés par le contrôleur. Publiez-le sur 127.0.0.1 avec Docker Engine 28.0.0 ou une version ultérieure et utilisez ssh -L 8443:127.0.0.1:8443 you@vps.example.com pour y accéder, ou liez-le à une adresse WireGuard ou Tailscale. Pour l’adoption et la gestion, vos sites doivent pouvoir joindre TCP 8080 et UDP 3478, ainsi que TCP 5671 si une passerelle UXG envoie des journaux Traffic Flow au contrôleur. Vous pouvez limiter ces accès aux adresses publiques des sites lorsqu’elles sont statiques. Un port publié par Docker n’est pas filtré par ufw. Testez donc depuis une machine externe au lieu de vous fier à ufw status.

Mon réseau cesse-t-il de fonctionner si le contrôleur du VPS tombe en panne ?

Non. Les points d’accès et les switches adoptés continuent de transmettre le trafic avec la configuration déjà poussée par le contrôleur. Les clients restent donc connectés et le Wi-Fi continue de fonctionner. Seule la gestion s’arrête. Vous perdez le dashboard et la collecte des statistiques, ainsi que toute fonctionnalité temps réel fournie par le contrôleur, comme l’authentification du guest portal ou RADIUS lorsque le contrôleur joue le rôle de serveur RADIUS.

Où le contrôleur UniFi stocke-t-il ses sauvegardes automatiques ?

Dans l’image de conteneur utilisée ici, elles sont enregistrées dans /config/data/backup/autobackup. Ce chemin correspond, sur l’hôte, à votre chemin de données suivi de data/backup/autobackup, sous forme de fichiers .unf nommés avec la version et un timestamp. Sur certaines installations neuves, le répertoire autobackup n’existe pas. La sauvegarde planifiée n’écrit alors rien sans signaler d’erreur. Listez donc ce répertoire le lendemain de la création de la planification et créez-le vous-même s’il est vide. Copiez les fichiers hors du VPS, car un .unf contient la configuration des sites et les comptes administrateur.