Como rodar um controlador UniFi em uma VPS

O que um controlador UniFi numa VPS faz efetivamente

Um controlador UniFi numa VPS é um único servidor de gestão que continua acessível quando os sites que gere ficam indisponíveis. O software é a UniFi Network Application da Ubiquiti: um programa Java com uma base de dados MongoDB. Configura os seus pontos de acesso e switches, armazena as respetivas estatísticas e disponibiliza a interface de administração. Não transporta tráfego de clientes.

Este último ponto determina onde deve ficar. Se colocar o controlador numa máquina dentro do escritório que gere, perde a rede e a ferramenta de análise da rede no mesmo momento. Se o colocar numa VPS com um endereço público estável, ele continua a funcionar, continua a recolher dados e pode adotar dispositivos de vários sites a partir de um único local. Precisa de disponibilidade, não de capacidade de processamento.

Quando o controlador está offline, os pontos de acesso e switches adotados continuam a encaminhar tráfego com a configuração que já receberam. Perde o painel e as estatísticas, além de qualquer funcionalidade que exija o controlador ativo: o início de sessão num portal de convidados ou o RADIUS (remote authentication dial-in user service), se o controlador for o seu servidor RADIUS. Os clientes continuam ligados.

Quanta RAM um controlador UniFi precisa?

2 GB é o mínimo e 4 GB é o valor recomendado. Existem dois consumidores de memória no mesmo servidor: Java e MongoDB. Cada um dimensiona o seu consumo de forma independente.

O heap do Java é limitado por MEM_LIMIT, que a imagem do contentor define como 1024 MB por predefinição. O MongoDB é a outra parte. O seu motor de armazenamento WiredTiger dimensiona a cache para metade da RAM acima de 1 GB, ou 256 MB, consoante o valor que for maior. Numa VPS com 2 GB, isso corresponde aproximadamente a 512 MB de cache, 1 GB de heap, a memória não heap da JVM e o sistema operativo. Funciona até surgir um dia com carga elevada. Nesse momento, o kernel termina um dos dois processos através do OOM killer. Depois de qualquer reinício inexplicado, execute dmesg -T | grep -i 'killed process' para confirmar se foi isso que aconteceu. Adicione um ficheiro de swap se tiver apenas 2 GB.

O CPU e o disco não exigem muito. Um ou dois vCPU são suficientes para algumas dezenas de dispositivos. Comece com 20 GB de disco e monitorize o consumo, porque a base de dados cresce conforme o número de clientes e o tempo durante o qual mantém as estatísticas. Um controlador isolado deixa a maior parte de um servidor com 4 GB livre. Se planear alojar outro serviço no mesmo servidor, dimensione primeiro para esse serviço, porque PhotoPrism e Immich têm requisitos mínimos de RAM muito diferentes e qualquer um deles precisa de mais memória do que o controlador.

Uma funcionalidade do CPU é importante e pode passar despercebida num plano barato:

grep -m1 -o avx /proc/cpuinfo

O MongoDB 5.0 e versões posteriores precisam de AVX (advanced vector extensions) em hardware x86_64. Se esse comando não produzir qualquer saída, o mongod termina durante o arranque e o contentor reinicia continuamente, porque o binário executa uma instrução que o CPU não suporta. Hosts com Intel Celeron e Pentium antigos são a causa habitual. Os hipervisores que ocultam os flags do CPU do sistema convidado também podem causar o problema. O MongoDB 4.4 é a versão mais recente que funciona sem AVX. A imagem também aceita versões anteriores até à 3.6, mas a versão 4.4 chegou ao fim de vida em fevereiro de 2024. A MongoDB publicou builds da versão 4.4 para a correção de dezembro de 2025 da CVE-2025-14847, mas não há garantia de que faça o mesmo para a próxima vulnerabilidade. As versões mais antigas estão ainda mais desatualizadas. Migrar para um host com um CPU mais recente é a melhor solução. Numa VPS ARM, esta questão não se coloca, porque AVX é um conjunto de instruções x86 e ambas as imagens disponibilizam builds arm64. Se estiver a escolher entre as duas opções, as diferenças entre planos de VPS ARM e x86 são mais importantes do que o preço.

Instale a aplicação UniFi Network com Docker Compose

O Docker é o caminho com menos surpresas, porque permite fixar o MongoDB numa versão compatível com a aplicação, em vez de aceitar a versão disponibilizada pela distribuição. Se o Docker ainda não estiver instalado no servidor, instale o Docker numa VPS primeiro.

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

O MongoDB precisa de um utilizador antes de a aplicação poder iniciar sessão. A imagem oficial do MongoDB executa qualquer script que encontre em /docker-entrypoint-initdb.d no primeiro arranque. Guarde este conteúdo 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

Esse script é executado apenas quando o diretório da base de dados está vazio. Se iniciar a stack uma vez com a palavra-passe errada, o utilizador será criado com essa palavra-passe. Alterar o ficheiro Compose depois disso não terá efeito, porque o script não volta a ser executado. O sintoma é o contentor da aplicação registar falhas de autenticação no MongoDB, enquanto a interface web nunca fica disponível. Numa instalação nova, a correção consiste em parar a stack, eliminar ~/unifi/db e iniciá-la novamente.

Depois, escreva ~/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

As duas tags de imagem estão fixadas de propósito. 10.5.67-ls141 era a versão atual da aplicação em agosto de 2026, por isso consulte a lista de versões da imagem e fixe a versão que estiver atual quando fizer a instalação. A tag da base de dados é mais importante. O MongoDB não atualiza automaticamente os ficheiros de dados entre versões principais. Por isso, mongo:latest acabará por obter uma nova versão principal, recusará abrir os ficheiros existentes e reiniciará continuamente. Fixe a versão principal e altere-a de forma deliberada. O UniFi Network 8.1 e versões posteriores suportam MongoDB 3.6 a 7.0, e a versão 9.0 acrescentou suporte para MongoDB 8.0.

PUID e PGID têm de corresponder a um utilizador real no host. Caso contrário, os ficheiros em ./config ficarão pertencentes a uma identidade que não pode escrevê-los. Execute id para obter os seus valores. como funcionam PUID e PGID em imagens de contentores explica como se manifesta uma incompatibilidade.

Inicie a stack e monitorize os logs:

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

docker compose ps deve mostrar os dois contentores com o estado running. Um unifi-db bloqueado em restarting indica um problema de AVX ou de permissões em ./db. Quando os logs estabilizarem, verifique os dois 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

Qualquer código de estado HTTP significa que o listener está associado à porta e a responder. Connection refused significa que a aplicação ainda está a iniciar. Na primeira execução, esse processo demora um ou dois minutos numa VPS pequena. Também pode significar que a aplicação nunca arrancou.

Aceder à interface de administração sem a expor

A porta 8443 é publicada em 127.0.0.1 no ficheiro acima. Por isso, no Docker Engine 28.0.0 ou posterior, nada fora do VPS consegue aceder à interface de administração. Nas versões mais antigas, outros hosts no mesmo segmento L2, como máquinas ligadas ao mesmo switch de rede, conseguem aceder às portas publicadas em localhost. Execute docker version e atualize primeiro se o servidor indicar uma versão mais antiga. Encaminhe a porta através de SSH para executar o assistente de configuração:

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

Mantenha essa sessão aberta e aceda a https://127.0.0.1:8443 no navegador. O certificado é autoassinado, por isso o navegador apresenta um aviso uma vez. Crie a conta de administrador, atribua um nome ao site e ignore a adoção de dispositivos por enquanto.

Um túnel SSH é suficiente para um administrador. Para uma equipa, atribua um endereço privado ao VPS e faça a interface escutar nesse endereço. Uma VPN WireGuard no seu próprio VPS e um router de sub-rede Tailscale fornecem um endereço ao qual apenas as pessoas da sua equipa conseguem encaminhar tráfego. Altere a porta publicada para 10.8.0.1:8443:8443 no caso do WireGuard, ou para o endereço atribuído pelo Tailscale. Existe uma limitação: o Docker não pode publicar numa interface que ainda não exista. Por isso, a interface do túnel tem de estar ativa antes de o contentor arrancar. Caso contrário, o contentor falha com um erro de bind.

Por que um dispositivo UniFi remoto não é adotado

Por padrão, um dispositivo UniFi encontra o seu controlador através de uma transmissão na rede local, na porta UDP 10001. Uma transmissão não sai da LAN, portanto um dispositivo num escritório noutra cidade nunca descobrirá um controlador num VPS. Isto é a adoção de Layer 3 e é onde a maioria das pessoas fica bloqueada. O dispositivo está funcional e o controlador também. Ninguém informou o dispositivo sobre onde procurar.

Primeiro, informe ao controlador qual endereço deve fornecer. Nas Settings do controlador, na secção System, existe uma definição de inform host com uma opção de override. Defina-a para o hostname público ou o IP do seu VPS. Sem essa definição, o controlador anuncia o endereço que vê na sua própria interface, que dentro de uma rede bridge do Docker é um endereço privado como 172.18.0.3. O dispositivo recebe esse endereço, não consegue encaminhar tráfego para ele e volta a procurar.

Depois, indique esse endereço ao dispositivo. Ligue-se por SSH ao dispositivo na LAN remota. Um dispositivo com as predefinições de fábrica aceita o nome de utilizador ubnt e a palavra-passe ubnt:

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

O firmware mais recente do dispositivo apresenta um menu em vez de uma shell. Execute o mesmo procedimento como um único comando:

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

O dispositivo aparece agora no controlador como pronto para adoção. Clique em Adopt e o estado muda para Adopting. Esta é a parte que surpreende toda a gente: normalmente é necessário executar set-inform uma segunda vez. O dispositivo reinicia para o aprovisionamento e recorre ao URL de inform guardado na sua própria configuração, que o controlador ainda não terminou de substituir. Executar o comando novamente enquanto o estado apresenta Adopting conclui a transferência. Introduza info no dispositivo para ver o URL de inform e o estado atualmente guardados.

Se o dispositivo tiver sido adotado anteriormente por outro controlador, set-inform não será suficiente, porque o dispositivo ainda mantém as credenciais desse controlador. Reponha primeiro as predefinições de fábrica, utilizando o botão de reset ou set-default por SSH com as credenciais antigas.

Para mais do que alguns dispositivos, utilize DHCP. A opção 43 do DHCP (dynamic host configuration protocol) transporta um valor específico do fabricante, e os dispositivos UniFi leem o URL de inform a partir da subopção 2. Crie a cadeia hexadecimal em qualquer máquina 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, uma cadeia de 31 bytes, o comando apresenta 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Cole o resultado no campo da opção 43 do DHCP do seu router como valor hexadecimal. Todos os dispositivos que arrancarem nessa rede aprendem então o endereço do controlador a partir do respetivo lease, sem qualquer ligação SSH. Os guias mais antigos mostram a subopção 1 em vez disso, 0104 seguida dos quatro bytes de um endereço IPv4 em hexadecimal, e os dispositivos continuam a aceitar esse formato.

Existe uma terceira opção se executar DNS no local. Um dispositivo UniFi tenta resolver o hostname unifi durante o arranque, portanto um registo A para unifi apontado para o endereço do seu VPS adota os dispositivos sem intervenção individual. Esta opção só funciona quando controla o resolver que os dispositivos utilizam efetivamente.

Quais portas do UniFi abrir e quais manter privadas

Duas portas precisam de ser acessíveis a partir de um site remoto para a adoção e a gestão diária.

• TCP 8080 é o canal inform, ao qual todos os dispositivos adotados se ligam. O conteúdo é encriptado com AES usando uma chave que o controlador fornece ao dispositivo durante a adoção. Por isso, HTTP simples é a configuração normal neste caso.
• UDP 3478 é STUN (session traversal utilities for NAT). Os dispositivos usam-no para manter um caminho de volta para o controlador.

Algumas funcionalidades precisam de mais portas. A referência de portas da Ubiquiti acrescenta TCP 5671 para o registo Traffic Flow de gateways UXG adotados em redes L2 ou L3. Se um site tiver um UXG a enviar dados para este controlador e quiser esses logs, abra também 5671 para esse site.

Num VPS, todas as outras portas devem permanecer fechadas.

• TCP 8443 é a interface de administração. Esta porta nunca deve ser pública. Contém a configuração de todos os sites geridos pelo controlador, protegida por uma única palavra-passe.
• UDP 10001 e UDP 1900 são usados pela descoberta por broadcast. Os broadcasts não atravessam a Internet, por isso abri-los não produz qualquer efeito.
• TCP 8880 e TCP 8843 são usados pelos redirecionamentos do portal de convidados. Abra-os apenas se utilizar um portal de convidados.
• TCP 6789 é usado pelo teste de velocidade da aplicação móvel e UDP 5514 pelo syslog remoto. Adicione-os quando os utilizar.
• TCP 27117 é o MongoDB. No ficheiro compose acima, a base de dados não publica nenhuma porta. Existe apenas na rede Docker interna. Mantenha essa configuração.

Se os seus sites tiverem endereços públicos estáticos, permita apenas esses endereços:

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

os fundamentos do ufw para um firewall de VPS explica a configuração de negação predefinida assumida por essas regras.

Há uma armadilha que apanha utilizadores repetidamente. As portas publicadas pelo Docker contornam o ufw. Publicar uma porta escreve regras de NAT e encaminhamento diretamente no iptables. Esse tráfego é filtrado na própria cadeia do Docker, não na cadeia INPUT gerida pelo ufw. Assim, ufw deny 8443 parece correto em ufw status, enquanto a porta continua aberta para toda a Internet. Teste a partir de outra máquina, nunca a partir do próprio VPS:

nc -vz vps.example.com 8443

Uma recusa ou um timeout é o resultado pretendido. Se a ligação for estabelecida, a porta está pública, independentemente do que o ufw indicar. A correção fiável é a que já está no ficheiro compose: publique a porta em 127.0.0.1 ou num endereço de túnel, para que o Docker nunca a associe à interface pública. Também pode usar uma regra na cadeia DOCKER-USER, mas associar a porta ao endereço correto é mais simples, e um erro na ordem das regras não consegue desfazer essa proteção.

E os instaladores da própria Ubiquiti?

A Ubiquiti publica um pacote Debian para a Network Application e, em outubro de 2026, o seu centro de ajuda classifica essa opção como legada e apresenta o UniFi OS Server como o novo padrão para alojamento próprio. O pacote funciona, mas no Ubuntu atual surge uma questão relacionada com o MongoDB que a distribuição já não resolve: o Ubuntu 22.04 e 24.04 não incluem um pacote de servidor MongoDB. Por isso, é necessário adicionar o repositório do próprio MongoDB e compatibilizar manualmente as versões. O contentor acima faz essa compatibilização numa única tag fixa. É por isso que essa é a opção usada aqui.

O produto mais recente da Ubiquiti para alojamento próprio é o UniFi OS Server. Ele executa as aplicações UniFi em contentores Podman e fornece o mesmo UniFi OS presente nas consolas de hardware da empresa. Em outubro de 2026, a Ubiquiti indica como requisitos uma CPU x86-64, Ubuntu 24.04 ou posterior ou Debian 13 ou posterior, Podman 4.9.3 ou posterior com slirp4netns 1.2 ou posterior, pelo menos 2 GB de RAM e 10 GB de armazenamento livre. A ligação do instalador na página Releases ou Download da Ubiquiti é específica da versão: clique com o botão direito no download, copie o endereço da ligação e faça o download com curl -O ou wget. Cada release tem o seu próprio URL. Por isso, um guia pode fixar uma versão, mas não pode fornecer uma ligação que aponte sempre para a versão mais recente. O instalador configura um serviço systemd chamado uosserver. Pode pará-lo e iniciá-lo com systemctl. Escolha esta opção se quiser usar o empacotamento da própria fabricante. Escolha a stack de contentores se quiser fixar as versões por conta própria e manter o servidor disponível para outras tarefas.

Onde ficam os backups do UniFi e como removê-los do servidor

O controlador grava os próprios backups de acordo com a agenda definida em Settings, na secção de backups, juntamente com o número de backups a manter. Os ficheiros ficam em /config/data/backup/autobackup dentro do contentor, que corresponde a ~/unifi/config/data/backup/autobackup no host, com nomes no formato autobackup_10.5.67_20260813_1200_1755086400004.unf.

Confirme se os ficheiros são realmente criados:

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

Um diretório vazio um dia depois de definir uma agenda é uma falha conhecida em instalações novas do contentor. A aplicação espera que o diretório autobackup exista e não o cria, pelo que a tarefa agendada não grava nada. Crie-o manualmente com o mesmo utilizador com que o contentor é executado e aguarde pela próxima execução:

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

Um ficheiro .unf contém a configuração do site e as contas de administrador, pelo que deve ser tratado como uma chave criptográfica. Transfira cópias para uma máquina sob o seu controlo e mantenha-as privadas:

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

A restauração é simples. A primeira página do assistente de configuração de uma instalação nova permite restaurar a partir de um ficheiro de backup, e um controlador em execução permite iniciar a restauração na mesma página de definições. Restaure para a mesma versão ou para uma versão mais recente. Um backup criado por uma aplicação mais recente do que a aplicação para a qual está a restaurar é rejeitado. Por isso, registe o número da versão juntamente com o ficheiro.

O que uma atualização do controlador pode interromper

Faça um backup manual e transfira-o antes de cada atualização. Depois:

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

A base de dados é o primeiro componente a falhar. Alterar a tag mongo para uma nova versão principal na mesma edição em que atualiza a aplicação é a forma mais rápida de ficar com um controlador que não inicia, porque o MongoDB não abre ficheiros de dados de outra versão principal sem uma atualização faseada. Atualize apenas a aplicação. Atualize o MongoDB separadamente, uma versão principal de cada vez, mantendo um backup recente disponível.

A memória é o problema seguinte. Uma versão maior precisa de mais heap. Se a aplicação iniciar, funcionar durante alguns minutos e terminar, aumente MEM_LIMIT e MEM_STARTUP para 1536 ou 2048 e reinicie. dmesg -T | grep -i 'killed process' no host confirma se foi o kernel que terminou o processo.

O firmware dos dispositivos é o risco que muitas pessoas esquecem. Depois de o controlador se atualizar, ele disponibiliza atualizações de firmware para os dispositivos adotados. Não as aceite na mesma sessão. Se uma atualização de dispositivo coincidir com uma atualização do controlador e a ligação entre ambos cair, o dispositivo pode ficar parcialmente provisionado, e terá novamente de usar set-inform por SSH num equipamento situado noutro edifício.

A própria janela de atualização é menos problemática do que parece. Os dispositivos continuam a encaminhar tráfego enquanto o controlador reinicia, por isso os utilizadores não notam nada. O portal de convidados e o RADIUS deixam de funcionar se forem fornecidos pelo controlador. Escolha um horário em que nenhum dos dois esteja a ser utilizado. É importante saber se um controlador termina silenciosamente às 3 a.m., por isso aponte um monitor de estado do Uptime Kuma para a porta 8080 e deixe-o avisá-lo.

A alternativa honesta: a console alojada da Ubiquiti

A Ubiquiti disponibiliza a mesma função como serviço. Em outubro de 2026, a loja da Ubiquiti nos EUA vende-a como Official UniFi Hosting, a partir de $29 por mês, gerindo até 1,000 dispositivos UniFi Network num servidor operado pela Ubiquiti. A aplicação autoalojada que acabou de instalar é gratuita e não tem subscrição.

Escolha a console alojada se gere um único site e prefere pagar em vez de aplicar patches. Escolha um VPS se gere vários sites, ou se quiser o controlador dentro de uma rede que controla e partilhar o servidor com os outros serviços que executa. A diferença de custo em pequena escala é real, mas não é o único fator a considerar: a disponibilidade de uma console alojada depende de terceiros, enquanto o VPS é seu, incluindo a noite em que o disco fica cheio. Se o servidor vai justificar o custo de qualquer forma, o que mais pode executar num VPS é a lista que deve consultar a seguir.

FAQ

Porque é que o meu dispositivo UniFi não é adotado por um controller numa VPS?

Os dispositivos descobrem os controllers através de broadcast na porta UDP 10001. Um broadcast nunca sai da rede local. Por isso, um dispositivo num site remoto não consegue encontrar um controller na Internet pública. Defina o override do inform host nas definições de sistema do controller para o hostname da sua VPS. Depois, aponte o dispositivo para esse hostname com ssh ubnt@<device-ip> seguido de set-inform http://vps.example.com:8080/inform. Se o dispositivo ficar no estado Adopting, execute set-inform novamente enquanto estiver nesse estado. Se outro controller o tiver adotado anteriormente, reponha primeiro as predefinições de fábrica. O dispositivo ainda mantém as credenciais do controller antigo.

De quanta RAM precisa um controller UniFi alojado pelo próprio utilizador?

2 GB é o mínimo funcional e 4 GB oferece uma margem confortável. A aplicação usa Java e MongoDB. Cada um dimensiona a sua memória separadamente: a imagem do container limita o heap Java a 1024 MB por predefinição, enquanto a cache WiredTiger do MongoDB usa metade da RAM acima de 1 GB. Em x86_64, confirme também que a CPU disponibiliza AVX com grep -m1 -o avx /proc/cpuinfo. O MongoDB 5.0 e versões posteriores não inicia sem essa extensão, e o container da base de dados entra num ciclo de reinícios.

Devo expor a porta 8443 à Internet?

Não. A porta 8443 é a interface de administração. Contém a configuração de todos os sites geridos pelo controller. Publique-a em 127.0.0.1 com o Docker Engine 28.0.0 ou posterior e aceda-lhe com ssh -L 8443:127.0.0.1:8443 you@vps.example.com. Em alternativa, associe-a a um endereço WireGuard ou Tailscale. Para adoção e gestão, os seus sites precisam de alcançar a porta TCP 8080 e a porta UDP 3478. Também precisam da porta TCP 5671 se um gateway UXG enviar logs de Traffic Flow para o controller. Quando os endereços públicos dos sites são estáticos, pode restringir o acesso a esses endereços. Lembre-se de que uma porta publicada pelo Docker não é filtrada pelo ufw. Por isso, teste a partir de uma máquina externa em vez de confiar em ufw status.

A minha rede deixa de funcionar se o controller UniFi na VPS ficar indisponível?

Não. Os access points e switches adotados continuam a encaminhar tráfego com a configuração que o controller já lhes enviou. Os clientes permanecem ligados e o Wi-Fi continua a funcionar. O que deixa de funcionar é a gestão. Perde o dashboard e a recolha de estatísticas, além de qualquer funcionalidade em tempo real disponibilizada pelo controller, como a autenticação do guest portal ou o RADIUS quando o controller é o servidor RADIUS.

Onde guarda o controller UniFi as cópias de segurança automáticas?

Na imagem do container usada neste tutorial, são guardadas em /config/data/backup/autobackup. Esse caminho corresponde ao seu caminho de dados mais data/backup/autobackup no host, como ficheiros .unf com o nome baseado na versão e num timestamp. Em algumas instalações novas, o diretório autobackup não existe. Nesse caso, a cópia de segurança agendada não grava nada nem comunica um erro. Liste esse diretório um dia depois de configurar um agendamento. Se estiver vazio, crie o diretório manualmente. Copie os ficheiros para fora da VPS, porque um .unf contém a configuração dos sites e as contas dos administradores.