Cómo instalar UniFi Network Application en un VPS

Qué hace realmente un controlador UniFi en un VPS

Un controlador UniFi en un VPS es un servidor de gestión que sigue siendo accesible cuando los sitios que administra dejan de estar disponibles. El software es UniFi Network Application de Ubiquiti: un programa Java con una base de datos MongoDB detrás. Configura los puntos de acceso y switches, almacena sus estadísticas y ofrece la interfaz de administración. No transporta el tráfico de los clientes.

Este último punto determina dónde debe ubicarse. Si instala el controlador en una máquina dentro de la oficina que administra, perderá la red y la herramienta para examinarla al mismo tiempo. Si lo instala en un VPS con una dirección pública estable, seguirá ejecutándose, recopilando datos y permitiendo adoptar dispositivos de varios sitios desde un solo lugar. Necesita disponibilidad, no potencia de procesamiento.

Cuando el controlador está fuera de línea, los puntos de acceso y switches adoptados siguen reenviando el tráfico con la configuración que ya se les envió. Perderá el panel y las estadísticas, además de cualquier función que necesite que el controlador esté activo: el inicio de sesión de un portal de invitados o RADIUS (remote authentication dial-in user service) si el controlador es su servidor RADIUS. Los clientes permanecen conectados.

¿Cuánta RAM necesita un controlador UniFi?

Dos GB es el mínimo y 4 GB es la cantidad recomendable. En un mismo sistema hay dos consumidores de memoria, Java y MongoDB, y cada uno calcula sus necesidades de forma independiente.

El heap de Java está limitado por MEM_LIMIT, que la imagen del contenedor establece en 1024 MB de forma predeterminada. MongoDB es la otra mitad. Su motor de almacenamiento WiredTiger establece su caché en la mitad de la RAM que supera 1 GB, o en 256 MB, el valor que sea mayor. En un VPS de 2 GB, eso equivale aproximadamente a 512 MB de caché, 1 GB de heap, la memoria no heap de la JVM y el sistema operativo. Funciona hasta que llega un día con mucha carga y el kernel termina uno de los dos procesos mediante el asesino de procesos por falta de memoria. Después de cualquier reinicio sin explicación, ejecute dmesg -T | grep -i 'killed process' para comprobar si eso fue lo que ocurrió. Añada un archivo de swap si sólo dispone de 2 GB.

La CPU y el disco no requieren muchos recursos. Una o dos vCPU gestionan unas pocas docenas de dispositivos. Empiece con 20 GB de disco y vigile su uso, porque la base de datos crece según el número de clientes que tenga y el tiempo durante el que conserve las estadísticas. Un controlador por sí solo deja inactiva la mayor parte de un sistema de 4 GB. Si piensa alojar otro servicio junto a él, calcule primero los recursos para ese servicio, porque PhotoPrism e Immich tienen mínimos de RAM muy diferentes y cualquiera de los dos necesita más que el controlador.

Una característica de la CPU es importante y puede pasar desapercibida en un plan económico:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 y las versiones posteriores necesitan AVX (advanced vector extensions) en hardware x86_64. Si ese comando no muestra nada, mongod termina durante el arranque y el contenedor se reinicia en un bucle, porque el binario ejecuta una instrucción que la CPU no admite. Los hosts con Intel Celeron y Pentium antiguos son la causa habitual. También lo son los hipervisores que ocultan las flags de la CPU al sistema invitado. MongoDB 4.4 es la versión más reciente que funciona sin AVX, y la imagen también acepta versiones anteriores hasta la 3.6, pero 4.4 llegó al final de su vida útil en febrero de 2024. MongoDB publicó compilaciones de 4.4 para su corrección de diciembre de 2025 para CVE-2025-14847, pero nada garantiza que ocurra lo mismo con la siguiente vulnerabilidad, y las versiones anteriores están aún más atrasadas. La mejor solución es migrar a un host con una CPU más reciente. En un VPS ARM esta cuestión no se plantea, porque AVX es un conjunto de instrucciones de x86, y ambas imágenes publican compilaciones arm64. Si tiene que elegir entre las dos opciones, las diferencias entre los planes VPS ARM y x86 van más allá del precio.

Instalar UniFi Network Application con Docker Compose

Docker es la opción que suele causar menos problemas, porque permite fijar MongoDB en una versión compatible con la aplicación en lugar de usar la versión que incluya la distribución. Si Docker todavía no está instalado en el servidor, instale Docker en un VPS primero.

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

MongoDB necesita un usuario antes de que la aplicación pueda iniciar sesión. La imagen oficial de MongoDB ejecuta cualquier script que encuentre en /docker-entrypoint-initdb.d durante el primer arranque. Guarde lo siguiente como ~/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

Ese script se ejecuta sólo cuando el directorio de la base de datos está vacío. Si inicia la pila una vez con la contraseña incorrecta, el usuario se crea con esa contraseña. Editar después el archivo compose no cambia nada, porque el script no vuelve a ejecutarse. El síntoma es que el contenedor de la aplicación registra errores de autenticación de MongoDB y la interfaz web nunca aparece. En una instalación nueva, la solución es detener la pila, eliminar ~/unifi/db y volver a iniciarla.

Después, escriba ~/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

Las dos etiquetas de imagen están fijadas de forma intencionada. 10.5.67-ls141 era la versión actual de la aplicación en agosto de 2026, así que compruebe la lista de versiones de la imagen y fije la versión que esté disponible cuando realice la instalación. La etiqueta de la base de datos es más importante. MongoDB no actualiza por sí solo los archivos de datos entre versiones principales, por lo que algún día mongo:latest descargará una nueva versión principal, se negará a abrir los archivos existentes y se reiniciará en bucle. Fije la versión principal y actualícela de forma deliberada. UniFi Network 8.1 y posteriores admiten MongoDB 3.6 a 7.0, y 9.0 añadió compatibilidad con MongoDB 8.0.

PUID y PGID deben coincidir con un usuario real del host. De lo contrario, los archivos de ./config quedarán asignados a una identidad que no puede escribir en ellos. Ejecute id para obtener los suyos. cómo funcionan PUID y PGID en las imágenes de contenedor explica cómo se manifiesta una discrepancia.

Inícielo y supervise los registros:

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

docker compose ps debe mostrar ambos contenedores como running. Un unifi-db atascado en restarting indica un problema de AVX, descrito arriba, o un problema de permisos en ./db. Cuando los registros se estabilicen, compruebe los dos servicios que escuchan:

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

Cualquier código de estado HTTP indica que el servicio está enlazado y responde. Connection refused indica que la aplicación todavía se está iniciando, lo que tarda uno o dos minutos en un VPS pequeño durante el primer arranque, o que nunca se inició.

Acceder a la interfaz de administración sin exponerla

El puerto 8443 se publica en 127.0.0.1 en el archivo anterior. Por tanto, en Docker Engine 28.0.0 o posterior, nada fuera de la VPS puede acceder a la interfaz de administración. En versiones anteriores, otros hosts del mismo segmento L2, como los equipos conectados al mismo switch de red, pueden acceder a los puertos publicados en localhost. Ejecute docker version y actualice primero si el servidor informa de una versión anterior. Reenvíe el puerto mediante SSH para ejecutar el asistente de configuración:

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

Mantenga abierta esa sesión y acceda a https://127.0.0.1:8443 con el navegador. El certificado es autofirmado, por lo que el navegador muestra una advertencia una vez. Cree la cuenta de administrador, asigne un nombre al sitio y omita por ahora la adopción de dispositivos.

Un túnel SSH es suficiente para un administrador. Para un equipo, asigne una dirección privada a la VPS y vincule la interfaz a esa dirección. Una VPN WireGuard en su propia VPS y un router de subred de Tailscale proporcionan una dirección a la que sólo pueden acceder sus usuarios. Cambie el puerto publicado a 10.8.0.1:8443:8443 para WireGuard o a la dirección que asigne Tailscale. Hay una limitación: Docker no puede publicar un puerto en una dirección que todavía no existe. Por tanto, la interfaz del túnel debe activarse antes de iniciar el contenedor; de lo contrario, el contenedor falla con un error de enlace.

Por qué un dispositivo UniFi remoto no se adopta

De forma predeterminada, un dispositivo UniFi encuentra su controlador mediante una difusión en la red local, por el puerto UDP 10001. Una difusión no sale de la LAN, por lo que un dispositivo ubicado en una oficina de otra ciudad nunca descubrirá un controlador en un VPS. Esto es una adopción de capa 3, y es donde la mayoría de las personas se bloquea. El dispositivo funciona y el controlador también. Nadie le ha indicado al dispositivo dónde buscar.

Primero, indique al controlador qué dirección debe entregar. En Settings del controlador, dentro de la sección System, hay un ajuste de inform host con una opción de override. Establézcalo con el nombre de host público o la IP de su VPS. Sin este ajuste, el controlador anuncia la dirección que ve en su propia interfaz, que dentro de una red de puente de Docker es una dirección privada como 172.18.0.3. El dispositivo recibe esa dirección, no puede enrutar hacia ella y vuelve a buscar.

Después, dirija el dispositivo a esa dirección. Conéctese por SSH al dispositivo desde la LAN remota. Un dispositivo con los valores de fábrica acepta el nombre de usuario ubnt y la contraseña ubnt:

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

El firmware más reciente del dispositivo abre un menú en lugar de un shell. Ejecute lo mismo como un único comando:

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

El dispositivo aparece ahora en el controlador listo para adoptarlo. Haga clic en Adopt y el estado cambia a Adopting. Esta es la parte que sorprende a todo el mundo: normalmente debe ejecutar set-inform una segunda vez. El dispositivo se reinicia para iniciar el aprovisionamiento y vuelve a la URL de inform guardada en su propia configuración, que el controlador todavía no ha terminado de reemplazar. Ejecutar el comando de nuevo mientras el estado muestra Adopting completa la transferencia. Escriba info en el dispositivo para ver la URL de inform y el estado que tiene actualmente.

Si el dispositivo ya fue adoptado por otro controlador, set-inform por sí solo no terminará el proceso, porque todavía conserva las credenciales de ese controlador. Restablézcalo primero a los valores de fábrica, mediante el botón de reset o con set-default por SSH usando las credenciales anteriores.

Para más de unos pocos dispositivos, use DHCP. La opción 43 de DHCP (protocolo de configuración dinámica de host) transporta un valor específico del fabricante, y los dispositivos UniFi leen la URL de inform desde la subopción 2. Construya la cadena hexadecimal en cualquier equipo 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"

Para http://192.168.3.10:8080/inform, una cadena de 31 bytes, el comando imprime 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Pegue el resultado en el campo de la opción 43 de DHCP de su router como valor hexadecimal. Todos los dispositivos que arranquen en esa red aprenderán la dirección del controlador a partir de su concesión, sin usar SSH. Las guías antiguas muestran la subopción 1 en su lugar, 0104 seguida de los cuatro bytes de una dirección IPv4 en hexadecimal, y los dispositivos todavía aceptan ese formato.

Existe una tercera opción si ejecuta DNS en el sitio. Un dispositivo UniFi intenta resolver el nombre de host unifi durante el arranque, por lo que un registro A para unifi que apunte a la dirección de su VPS adopta los dispositivos sin trabajo individual. Sólo sirve si controla el resolvedor que usan realmente los dispositivos.

Qué puertos de UniFi abrir y cuáles mantener privados

Dos puertos deben ser accesibles desde un sitio remoto para la adopción y la administración diaria.

• TCP 8080 es el canal inform. Todos los dispositivos adoptados se conectan a él. La carga útil se cifra con AES mediante una clave que el controlador entrega al dispositivo durante la adopción. Por eso, HTTP sin cifrar es la configuración normal en este caso.
• UDP 3478 es STUN (session traversal utilities for NAT). Los dispositivos lo usan para mantener una ruta de vuelta al controlador.

Algunas funciones necesitan puertos adicionales. La referencia de puertos de Ubiquiti añade TCP 5671 para los registros de Traffic Flow de gateways UXG adoptados en redes L2 o L3. Si un sitio tiene un UXG que envía informes a este controlador y necesita esos registros, abra también 5671 hacia ese sitio.

En una VPS, el resto debe permanecer cerrado.

• TCP 8443 es la interfaz de administración. Nunca debe ser público. Contiene la configuración de todos los sitios que administra el controlador y está protegida por una sola contraseña.
• UDP 10001 y UDP 1900 se usan para la detección mediante difusión. Las difusiones no atraviesan Internet, por lo que abrirlos no sirve de nada.
• TCP 8880 y TCP 8843 se usan para las redirecciones del portal de invitados. Ábralos sólo si ejecuta un portal de invitados.
• TCP 6789 es la prueba de velocidad de la aplicación móvil y UDP 5514 es el syslog remoto. Añádalos cuando los utilice.
• TCP 27117 es MongoDB. En el archivo compose anterior, la base de datos no publica ningún puerto, por lo que sólo existe en la red interna de Docker. Mantenga esa configuración.

Si sus sitios tienen direcciones públicas estáticas, permita únicamente esas direcciones:

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

los conceptos básicos de ufw para el firewall de una VPS explica la configuración de denegación predeterminada que asumen esas reglas.

Aquí hay una trampa que suele causar problemas. Los puertos publicados por Docker evitan ufw. Publicar un puerto escribe directamente reglas de NAT y reenvío en iptables. Ese tráfico se filtra en la propia cadena de Docker, no en la cadena INPUT que administra ufw. Por eso, ufw deny 8443 parece correcto en ufw status, aunque el puerto siga abierto a todo el mundo. Pruébelo desde otra máquina, nunca desde la propia VPS:

nc -vz vps.example.com 8443

Lo que se busca es un rechazo o un tiempo de espera. Si la conexión se establece, el puerto es público, independientemente de lo que indique ufw. La solución fiable es la que ya aparece en el archivo compose: publique el puerto en 127.0.0.1 o en una dirección del túnel para que Docker nunca lo asocie a la interfaz pública. También funciona una regla en la cadena DOCKER-USER, pero asociar el puerto a una interfaz es más sencillo y un error en el orden de las reglas no puede anularlo.

¿Qué ocurre con los instaladores propios de Ubiquiti?

Ubiquiti publica un paquete Debian para Network Application y, desde octubre de 2026, su centro de ayuda califica esa opción como heredada y presenta UniFi OS Server como el nuevo estándar para el alojamiento propio. El paquete funciona, pero en las versiones actuales de Ubuntu plantea una cuestión sobre MongoDB que la distribución ya no resuelve: Ubuntu 22.04 y 24.04 no incluyen ningún paquete de servidor MongoDB, por lo que debe añadir el repositorio propio de MongoDB y hacer coincidir las versiones manualmente. El contenedor anterior resuelve esa correspondencia en una única etiqueta fijada. Por eso se utiliza esa opción aquí.

El producto más reciente de Ubiquiti para el alojamiento propio es UniFi OS Server. Ejecuta las aplicaciones UniFi en contenedores Podman y proporciona el mismo UniFi OS que sus consolas de hardware. Desde octubre de 2026, Ubiquiti indica como requisitos una CPU x86-64, Ubuntu 24.04 o posterior o Debian 13 o posterior, Podman 4.9.3 o posterior con slirp4netns 1.2 o posterior, al menos 2 GB de RAM y 10 GB de almacenamiento libre. El enlace del instalador en la página Releases o Download de Ubiquiti depende de la versión: haga clic con el botón derecho en la descarga, copie la dirección del enlace y descárguela con curl -O o wget. Cada versión tiene su propia URL. Por tanto, una guía puede fijar una versión, pero no puede proporcionar un enlace que apunte siempre a la última versión. El instalador configura un servicio systemd llamado uosserver, que puede detener e iniciar con systemctl. Elija esta opción si quiere utilizar el empaquetado propio del proveedor. Elija la pila de contenedores si quiere fijar las versiones por su cuenta y mantener el servidor disponible para otras tareas.

Dónde se guardan las copias de seguridad de UniFi y cómo sacarlas del equipo

El controlador escribe sus propias copias de seguridad según el calendario que configure en Settings, en la sección de copias de seguridad, junto con el número de copias que debe conservar. Los archivos se guardan en /config/data/backup/autobackup dentro del contenedor, que corresponde a ~/unifi/config/data/backup/autobackup en el host, con nombres como autobackup_10.5.67_20260813_1200_1755086400004.unf.

Compruebe que realmente aparezcan:

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

Un directorio vacío un día después de configurar un calendario es un fallo conocido en instalaciones nuevas del contenedor. La aplicación espera que exista el directorio autobackup y no lo crea, por lo que la tarea programada no escribe nada y no muestra ningún error. Créelo manualmente con el mismo usuario con el que se ejecuta el contenedor y espere a la siguiente ejecución:

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

Un archivo .unf contiene la configuración del sitio y las cuentas de administrador, por lo que debe tratarlo como una clave criptográfica. Descargue copias a una máquina bajo su control y manténgalas privadas:

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

La restauración requiere un solo paso. La primera página del asistente de configuración de una instalación nueva permite restaurar desde un archivo de copia de seguridad. Un controlador en ejecución también permite restaurarla desde la misma página de configuración. Restaure en la misma versión o en una versión posterior. Se rechaza una copia de seguridad escrita por una aplicación más reciente que la instalación donde intenta restaurarla. Por eso debe registrar el número de versión junto con el archivo.

Qué puede romper una actualización del controlador

Haga una copia de seguridad manual y descárguela antes de cada actualización. Después:

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

La base de datos es lo primero que suele fallar. Cambiar la etiqueta mongo a una versión principal nueva en la misma edición que la aplicación es la forma más rápida de dejar un controlador que no arranca, porque MongoDB no abre archivos de datos de otra versión principal sin una actualización escalonada. Actualice la aplicación por separado. Actualice MongoDB por separado, una versión principal cada vez, con una copia de seguridad reciente disponible.

La memoria es el siguiente problema. Una versión más grande necesita un heap mayor. Si la aplicación arranca, funciona durante unos minutos y termina, aumente MEM_LIMIT y MEM_STARTUP a 1536 o 2048 y reinicie. dmesg -T | grep -i 'killed process' en el host confirma si el kernel es el que la termina.

El firmware de los dispositivos es el riesgo que suele olvidarse. Después de actualizarse, el controlador ofrece actualizaciones de firmware para los dispositivos adoptados. No las acepte en la misma sesión. Si coinciden una actualización del dispositivo y una actualización del controlador y se pierde el enlace entre ambos, el dispositivo puede quedar aprovisionado a medias, y tendrá que volver a usar set-inform por SSH en hardware ubicado en otro edificio.

La ventana de actualización es menos problemática de lo que parece. Los dispositivos siguen reenviando tráfico mientras se reinicia el controlador, por lo que los usuarios no notan nada. Lo que sí se detiene es el portal de invitados y RADIUS si el controlador los proporciona. Elija un horario en el que no se utilice ninguno de los dos. Conviene saber si un controlador deja de responder en silencio a las 3 a.m., así que apunte un monitor de estado de Uptime Kuma al puerto 8080 y deje que se lo indique.

La alternativa honesta: la consola alojada de Ubiquiti

Ubiquiti ofrece el mismo servicio como una solución alojada. En octubre de 2026, la tienda estadounidense de Ubiquiti lo vende como Official UniFi Hosting, desde $29 al mes, con capacidad para gestionar hasta 1,000 dispositivos UniFi Network en un servidor administrado por Ubiquiti. La aplicación autohospedada que acaba de instalar es gratuita y no requiere suscripción.

Elija la consola alojada si administra un solo sitio y prefiere pagar en lugar de aplicar parches. Elija un VPS si administra varios sitios, si quiere que el controlador esté dentro de una red que controle o si desea compartir el servidor con los demás servicios que ejecuta. La diferencia de coste a pequeña escala es real, pero no es el único factor que debe valorar: la disponibilidad de una consola alojada depende de otra persona, mientras que el VPS es responsabilidad suya, incluida la noche en que se llene el disco. Si el servidor va a justificar su coste de cualquier forma, qué más puede ejecutar en un VPS es la siguiente lista que debe consultar.

FAQ

¿Por qué mi dispositivo UniFi no se adopta en un controlador alojado en una VPS?

Los dispositivos detectan los controladores mediante difusión en el puerto UDP 10001. La difusión nunca sale de la red local, por lo que un dispositivo ubicado en un sitio remoto no puede encontrar un controlador en Internet pública. Configure la sustitución del host inform en los ajustes del sistema del controlador con el nombre de host de la VPS. Después, indique ese destino al dispositivo con ssh ubnt@<device-ip> seguido de set-inform http://vps.example.com:8080/inform. Si el dispositivo permanece en el estado Adopting, ejecute set-inform de nuevo mientras se encuentre en ese estado. Si otro controlador lo adoptó anteriormente, restablézcalo primero a los valores de fábrica, porque todavía conserva las credenciales del controlador anterior.

¿Cuánta RAM necesita un controlador UniFi autohospedado?

2 GB es el mínimo operativo y 4 GB ofrecen un margen cómodo. La aplicación consta de Java y MongoDB, y ambos dimensionan su memoria por separado: la imagen del contenedor limita de forma predeterminada el heap de Java a 1024 MB, mientras que la caché WiredTiger de MongoDB utiliza la mitad de la RAM que supera 1 GB. En x86_64, confirme también que la CPU expone AVX con grep -m1 -o avx /proc/cpuinfo, porque MongoDB 5.0 y versiones posteriores no se iniciarán sin esa extensión y el contenedor de la base de datos se reiniciará en bucle.

¿Debo exponer el puerto 8443 a Internet?

No. El puerto 8443 es la interfaz de administración y contiene la configuración de todos los sitios que gestiona el controlador. Publíquelo en 127.0.0.1 con Docker Engine 28.0.0 o una versión posterior y acceda mediante ssh -L 8443:127.0.0.1:8443 you@vps.example.com, o vincúlelo a una dirección de WireGuard o Tailscale. Para la adopción y la administración, sus sitios deben poder acceder a TCP 8080 y UDP 3478, además de TCP 5671 si una puerta de enlace UXG envía registros de Traffic Flow al controlador. Puede restringir esos puertos a las direcciones públicas de los sitios cuando sean estáticas. Recuerde que ufw no filtra un puerto publicado por Docker. Por tanto, pruebe desde una máquina externa en lugar de confiar en ufw status.

¿Deja de funcionar mi red si el controlador de la VPS se detiene?

No. Los puntos de acceso y switches adoptados siguen reenviando el tráfico con la configuración que el controlador ya les envió. Por tanto, los clientes permanecen conectados y la red Wi-Fi sigue funcionando. Lo que se detiene es la administración. Se pierde el panel y la recopilación de estadísticas, además de cualquier función en tiempo real que proporcione el controlador, como la autenticación del portal de invitados o RADIUS cuando el controlador actúa como servidor RADIUS.

¿Dónde almacena el controlador UniFi sus copias de seguridad automáticas?

En la imagen del contenedor utilizada aquí, se guardan en /config/data/backup/autobackup. Esta ruta corresponde a la ruta de datos del host más data/backup/autobackup, como archivos .unf cuyos nombres incluyen la versión y una marca de tiempo. En algunas instalaciones nuevas no existe el directorio autobackup. En ese caso, la copia de seguridad programada no escribe nada y tampoco informa de ningún error. Por tanto, enumere el contenido de ese directorio un día después de configurar una programación y créelo manualmente si está vacío. Copie los archivos fuera de la VPS, porque un .unf contiene la configuración de los sitios y las cuentas de administrador.