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 quelle quantité de RAM un contrôleur UniFi a-t-il besoin ?

2 Go est le minimum et 4 Go est la capacité à prévoir. Une même machine héberge deux consommateurs de mémoire, Java et MongoDB, qui dimensionnent chacun leur utilisation indépendamment de l’autre.

Le heap Java est plafonné 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 Go, ou à 256 MB, selon la valeur la plus élevée. Sur un VPS de 2 Go, cela représente environ 512 MB de cache, 1 Go de heap, la mémoire non-heap propre à la JVM et le système d’exploitation. Cela fonctionne jusqu’à une journée chargée, puis l’out-of-memory killer du kernel arrête l’un des deux processus. Après un 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 de swap si vous disposez de 2 Go.

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

Une fonctionnalité du CPU est importante et facile à manquer avec une offre peu coûteuse :

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 son 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 la plus fréquente, tout comme les hyperviseurs qui masquent les flags du CPU à la machine virtuelle. MongoDB 4.4 ne nécessite pas AVX et constitue le seul fallback, mais il s’agit d’une version de base de données que le projet amont ne corrige plus. 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 hésitez 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 précédent. Aucun accès depuis l’extérieur du VPS ne peut donc atteindre l’interface d’administration. Transférez-le 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 dans le navigateur. Le certificat est autosigné, le navigateur affiche donc un avertissement une seule fois. Créez le compte administrateur, donnez un nom au site, puis ignorez l’adoption des appareils pour le moment.

Un tunnel SSH convient pour un seul administrateur. Pour une équipe, attribuez une adresse privée au VPS et liez l’interface à cette adresse. Un VPN WireGuard sur votre propre VPS et un routeur de sous-réseau Tailscale fournissent tous deux une adresse vers laquelle seuls vos utilisateurs peuvent acheminer du trafic. 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 disponible 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.

Quels ports UniFi ouvrir et lesquels garder privés

Seuls deux ports doivent être accessibles depuis un site distant.

• TCP 8080 est le canal inform. Chaque équipement adopté s’y connecte. Les données qu’il transporte sont chiffrées en AES avec une clé que le controller a fournie à l’équipement lors de l’adoption. C’est pourquoi HTTP en clair est le réglage normal ici.
• UDP 3478 est utilisé par STUN (session traversal utilities for NAT). Les équipements s’en servent pour conserver un chemin vers le controller.

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 vers le guest portal. Ouvrez-les uniquement si vous utilisez un guest portal.
• TCP 6789 sert au test de débit mobile et UDP 5514 au syslog distant. Ajoutez-les si vous les utilisez.
• TCP 27117 est le port de 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. Le trafic est alors filtré dans la propre chaîne de Docker, et non dans la chaîne INPUT gérée par ufw. Ainsi, ufw deny 8443 peut sembler correcte 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 indiquée par ufw. La correction fiable est déjà appliquée 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.

Qu’en est-il des propres installateurs d’Ubiquiti ?

Ubiquiti publie un paquet Debian pour la Network Application. Il fonctionne, mais sur les versions actuelles d’Ubuntu, il soulève une question concernant MongoDB à laquelle la distribution ne répond plus : Ubuntu 22.04 et 24.04 ne fournissent aucun paquet du 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 épinglé unique. C’est pourquoi cette méthode est utilisée ici.

Le produit auto-hébergé le plus récent d’Ubiquiti est UniFi OS Server. Il exécute les applications UniFi dans des conteneurs Podman et vous fournit le même UniFi OS que leurs consoles matérielles. En août 2026, il nécessite Ubuntu 22.04 ou 24.04 sur x86_64, ainsi que Podman 4.3.1 ou version ultérieure avec slirp4netns. La configuration minimale demandée est de 2 vCPU et 4 GB de RAM. Ubiquiti recommande 4 vCPU et 8 GB. L’installateur est accessible depuis un compte Ubiquiti gratuit, sur leur page de téléchargements. Il n’existe donc pas d’URL stable à copier dans un guide. Il crée un utilisateur système appelé uosserver et exécute les conteneurs avec ce compte. Choisissez cette solution si vous voulez utiliser le packaging fourni par le constructeur. Choisissez la stack de conteneurs si vous voulez épingler 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 août 2026, la console Official UniFi Cloud Console coûte à partir de 29 $ par mois et gère jusqu’à 500 appareils UniFi. Ubiquiti prend en charge les mises à jour et les sauvegardes. L’application auto-hébergée que vous venez d’installer est gratuite et n’impose 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 correctifs. Choisissez un VPS si vous gérez plusieurs sites, si vous voulez que le contrôleur soit installé sur un réseau que vous contrôlez ou si vous souhaitez partager un serveur avec les autres services que vous exécutez. À petite échelle, la différence de coût est réelle, mais ce n’est pas le seul élément à prendre en compte : 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 arrive à saturation. Si le serveur doit être rentabilisé dans les deux cas, voici les autres services que vous pouvez exécuter sur un VPS à lire ensuite.

FAQ

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

Les équipements découvrent les contrôleurs en diffusant des paquets sur le port UDP 10001. Or 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 le remplacement 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 cette adresse à 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 dans cet état. Si un autre contrôleur l’a déjà adopté, réinitialisez d’abord l’équipement aux paramètres d’usine, car il contient encore les identifiants de l’ancien contrôleur.

De combien de RAM un contrôleur UniFi auto-hébergé a-t-il besoin ?

2 GB est le minimum fonctionnel et 4 GB offrent une marge confortable. L’application utilise 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 processeur expose AVX avec grep -m1 -o avx /proc/cpuinfo, car MongoDB 5.0 et les versions ultérieures ne démarrent pas sans cette instruction. Le conteneur de base de données redémarre alors en boucle.

Dois-je exposer le port 8443 sur Internet ?

Non. Le port 8443 est l’interface d’administration. Il contient la configuration de tous les sites gérés par le contrôleur. Publiez-le sur 127.0.0.1 et accédez-y avec ssh -L 8443:127.0.0.1:8443 you@vps.example.com, ou liez-le à une adresse WireGuard ou Tailscale. Seuls TCP 8080 et UDP 3478 doivent être accessibles depuis vos sites. Vous pouvez limiter ces ports aux adresses publiques des sites si elles sont statiques. N’oubliez pas qu’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à envoyée par le contrôleur. Les clients restent donc connectés et le Wi-Fi continue de fonctionner. C’est la gestion qui s’arrête. Vous perdez le dashboard et la collecte des statistiques, ainsi que toute fonction en 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 à votre chemin de données suivi de data/backup/autobackup sur l’hôte, sous la 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 d’une 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.