Como hospedar o Beszel por conta própria em 2026: agentes, rede privada e backups

A demonstração mais simples do Beszel prova que um processo está escutando na porta 8090. Em produção, é preciso ter evidências mais sólidas. O sistema deve passar por este cenário mesmo depois que o container for substituído: cadastrar um agent, observar os gráficos de CPU, memória e disco, disparar um alerta de limite e reconectar o agent após uma reinicialização do hub.

O Beszel é implantado com um objetivo claro: monitorar servidores leves em um container pequeno. A armadilha mais comum em sua implantação é o hub não conseguir acessar a porta 45876 de um agent ou a chave SSH ter sido alterada. Por isso, o tratamento da URL pública e do estado persistente deve receber a mesma atenção que a inicialização da imagem.

Delimite o ambiente de execução do Beszel

A saúde do processo e a saúde do produto são coisas diferentes no Beszel. A porta 8090 pode responder enquanto a transação voltada ao usuário ainda falha. O contrato de rede do Beszel exige um agent do Beszel em cada máquina monitorada. Mantenha os endpoints privados no DNS interno, permita apenas as chamadas de saída necessárias e forneça ao Beszel uma credencial de serviço com escopo limitado.

Use este exercício de readiness após mudanças relevantes de configuração: cadastre um agent, observe os gráficos de CPU, memória e disco, dispare um alerta de limite e reconecte o agent após uma reinicialização do hub. Não inclua verificações externas dispendiosas nos liveness probes, para que uma indisponibilidade de um provedor não provoque um loop de reinicialização. O trabalho de capacity planning deve acompanhar a quantidade de agents, a retenção de métricas, o armazenamento do hub e a conectividade de rede com cada agent em sua porta dedicada — fatores mais próximos da pressão real sobre o Beszel do que as solicitações de página.

Torne a origem pública inequívoca

O navegador, o cliente da API e o Beszel devem concordar com uma única origem. Para garantir isso, encaminhe o hub por HTTPS e mantenha as portas dos agents privadas. Preserve o host e o protocolo originais, mantendo a porta 8090 indisponível como um endereço público alternativo.

O guia de troubleshooting de site indisponível ajuda a diferenciar uma rota inacessível de uma aplicação que está respondendo. Essa distinção é importante aqui: o hub não consegue acessar a porta 45876 de um agent ou a chave SSH foi alterada. Apenas o primeiro caso é corrigido com mudanças no ingress; o segundo exige a inspeção dos logs, do estado ou da workload do Beszel.

Execute a primeira instância com características de produção

O primeiro container deve ser fácil de excluir e recriar. Mantenha os dados fora da camada gravável, faça o bind da porta 8090 apenas onde o proxy possa alcançá-la e passe a configuração em runtime.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

Fixe a versão da imagem após o teste inicial. Leia o primeiro erro de inicialização, em vez da mensagem final de reinicialização; verifique cada mount com docker inspect e acompanhe os logs enquanto cadastra um agent, observa os gráficos de CPU, memória e disco, dispara um alerta de limite e reconecta o agent após uma reinicialização do hub. Essa sequência diferencia um comando incorreto da imagem de um problema de dependência ou permissão.

Logs que respondem à próxima pergunta

Um container verde é necessário, mas não suficiente. O indicador de serviço é a conclusão bem-sucedida de “cadastrar um agent, observar os gráficos de CPU, memória e disco, disparar um alerta de limite e reconectar o agent após uma reinicialização do hub”. Já os sinais prováveis de pressão são a quantidade de agents, a retenção de métricas, o armazenamento do hub e a conectividade de rede com cada agent em sua porta dedicada.

O change control é importante porque as versões do hub e do agent devem ser testadas em conjunto: mudanças de protocolo podem se manifestar como lacunas silenciosas no monitoramento. Preserve a imagem antiga, teste as migrações em uma cópia do estado e documente se o rollback é compatível depois da alteração do schema. Se o hub não consegue acessar a porta 45876 de um agent ou a chave SSH foi alterada, diagnostique o primeiro limite que diverge do ambiente funcional.

Um processo de aceitação do Beszel em produção

Antes da chegada dos usuários reais, prepare uma release worksheet para o Beszel. Ela deve identificar a imagem fixada, a porta 8090, a origem canônica, os caminhos persistentes e o responsável por um agent do Beszel em cada máquina monitorada. Anexe o resultado esperado desta transação: cadastrar um agent, observar os gráficos de CPU, memória e disco, disparar um alerta de limite e reconectar o agent após uma reinicialização do hub.

Use a worksheet após uma substituição normal e depois de uma restauração limpa. A recuperação só será aceita se os sistemas, o histórico e os alertas retornarem e cada agent restaurado voltar a enviar métricas atuais. Colete também um breve resource trace que cubra a quantidade de agents, a retenção de métricas, o armazenamento do hub e a conectividade de rede com cada agent em sua porta dedicada; mantenha esse registro junto da release para que futuras mudanças de capacidade sejam comparadas com a mesma workload.

Inclua uma falha controlada: negue temporariamente à identidade de teste o acesso a um agent do Beszel em cada máquina monitorada. Confirme que o Beszel informa o problema no limite correto, restaure a condição válida e execute novamente a transação. Isso verifica a visibilidade dos erros, não apenas o sucesso, e impede que uma interface aparentemente saudável esconda um worker, callback ou conexão com o banco de dados com problemas.

Planeje a restauração do Beszel antes do lançamento

Faça um inventário de todos os artefatos persistentes: dados do hub, usuários, sistemas e configuração de alertas. Monte /beszel_data antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para provar que esse caminho é realmente persistente. Inclua também as configurações que alteram a interpretação dos dados armazenados, e não apenas o diretório maior.

Defina a retenção, copie os backups para fora do host e execute uma restauração em ambiente limpo. O exercício do Beszel estará concluído quando os sistemas, o histórico e os alertas retornarem e cada agent restaurado voltar a enviar métricas atuais. Se snapshots fizerem parte do plano, use as orientações sobre PITR e snapshots para documentar o que cada mecanismo consegue recuperar.

Encerre o acesso temporário de configuração

Faça o threat modeling da ação executada pelo Beszel, não apenas do formulário de login. Aqui, o erro de maior risco é publicar listeners dos agents na internet sem controles de rede. Implemente este limite: mantenha os listeners dos agents em redes privadas e proteja a conta do hub e as chaves de cadastro.

O Beszel não exige um segredo de bootstrap neste baseline; proteja a conta de administrador real ou a autenticação upstream. Não resolva um erro de permissão executando o container como root ou montando o host de forma ampla. Os limites de recursos também fazem parte do design de segurança quando usuários podem provocar aumentos na quantidade de agents, na retenção de métricas, no armazenamento do hub e na conectividade de rede com cada agent em sua porta dedicada.

Mova o trabalho repetível de infraestrutura para o Dockup

Para o Beszel, o Dockup é mais útil no limite entre uma imagem e um serviço durável. Ele mantém a rota para a porta 8090, o TLS, os valores de secrets e o armazenamento associados entre substituições de containers, independentemente de a computação pertencer ao Dockup ou ao seu servidor conectado.

Finalize com o conhecimento da aplicação: encaminhe o hub por HTTPS e mantenha as portas dos agents privadas; conecte e teste um agent do Beszel em cada máquina monitorada; e execute esta verificação: cadastre um agent, observe os gráficos de CPU, memória e disco, dispare um alerta de limite e reconecte o agent após uma reinicialização do hub. Mantenha o resultado como uma verificação de deployment, para que a próxima atualização da imagem seja avaliada pelo comportamento, e não pelo status do container.

Perguntas frequentes

O que o Beszel precisa para uma implantação em produção?

Encaminhe o container do Beszel na porta 8090 por meio de uma única origem HTTPS. O requisito de rede correspondente é um agent do Beszel em cada máquina monitorada. Não considere o Beszel pronto até conseguir cadastrar um agent, observar os gráficos de CPU, memória e disco, disparar um alerta de limite e reconectar o agent após uma reinicialização do hub.

Quais dados do Beszel devem fazer parte de um backup?

Persista /beszel_data e inclua os dados do hub, usuários, sistemas e configuração de alertas no mesmo manifesto de recuperação. Uma restauração limpa do Beszel só será bem-sucedida quando os sistemas, o histórico e os alertas retornarem e cada agent restaurado voltar a enviar métricas atuais.

O Beszel exige HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do Beszel e mantenha a porta 8090 na rota interna. Aplique corretamente a configuração do Beszel: encaminhe o hub por HTTPS e mantenha as portas dos agents privadas. No Beszel, o HTTPS protege credenciais ou conteúdo de usuários durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.

Como testar uma atualização do Beszel?

Restaure o estado atual do Beszel em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Preste atenção especial ao fato de que as versões do hub e do agent devem ser testadas em conjunto, pois mudanças de protocolo podem se manifestar como lacunas silenciosas no monitoramento. Mantenha a imagem anterior do Beszel até compreender os limites da migração de dados e do rollback.