Nginx Proxy Manager, Traefik ou Cloudflare Tunnel: qual caminho usar para publicar apps na VPS?

Publicar um app Docker na VPS parece simples até chegar o segundo domínio, o certificado vencer ou um container responder onde não devia. Nginx Proxy Manager, Traefik e Cloudflare Tunnel resolvem partes desse cenário. A escolha certa depende de onde você quer administrar rotas, TLS e exposição do servidor.

Resposta curta: escolha pela fronteira de operação

A melhor opção não é universal. Para poucos apps em uma VPS e alguém que prefere uma interface, Nginx Proxy Manager costuma reduzir o atrito. Para vários serviços no Docker Compose, Traefik transforma rotas em configuração e labels versionáveis. Para manter o origin sem portas inbound abertas, Cloudflare Tunnel cria conexões de saída até a rede Cloudflare. Essa é a sua Fronteira de Operação: o ponto onde a responsabilidade fica no painel, no Compose ou na borda de rede.

Nenhuma dessas ferramentas elimina autenticação do aplicativo, atualização, backup ou monitoramento. Elas mudam quem recebe a conexão e como você recupera a operação quando algo falha. Se você vai colocar n8n, Dify, Chatwoot, Portainer ou um app próprio em produção, essa decisão vem antes de abrir uma porta no firewall.

Proxy reverso e Tunnel não resolvem exatamente o mesmo problema

Um proxy reverso recebe a requisição pública e encaminha para o serviço interno correto. Em uma VPS, ele permite concentrar os acessos HTTP e HTTPS nas portas 80 e 443, enquanto n8n, Dify ou outro app ficam acessíveis pela rede Docker. Nginx Proxy Manager e Traefik atuam nesse papel, cada um com um modelo de administração diferente.

Cloudflare Tunnel é outro desenho. O daemon cloudflared mantém uma conexão criptografada de saída com a rede Cloudflare. Segundo a documentação do Cloudflare Tunnel, esse modelo não exige IP público nem portas inbound abertas no origin. Em vez de o usuário chegar diretamente ao IP da VPS, ele chega à borda Cloudflare, que encaminha o tráfego pelo Tunnel até o serviço definido.

Isso não torna Tunnel um substituto automático de proxy local. Ele pode apontar para um serviço interno, para localhost ou para uma aplicação atrás de NPM ou Traefik. Essa combinação faz sentido quando você quer uma camada local para organizar hosts e uma borda externa para evitar inbound no origin. Ela não é uma redundância obrigatória para toda VPS pequena.

Onde entram TLS, inbound e egress

Com NPM ou Traefik em modo tradicional, o tráfego público costuma chegar à VPS pelas portas 80 e 443. Em desafios ACME do Traefik, o entrypoint usado no HTTP-01 precisa estar acessível na porta 80. No TLS-ALPN-01, a exigência é acessibilidade na 443, como detalham os requisitos dos desafios ACME.

Já o Tunnel desloca a entrada pública para a Cloudflare, mas a VPS precisa sair para a rede dela. A configuração oficial pede egress na porta 7844 e recomenda bloquear todo ingress para um modelo de exposição positiva: só os serviços declarados entram nas regras do Tunnel. O termo inbound significa conexão que entra no seu servidor. Egress é a conexão que sai dele.

Nginx Proxy Manager para poucos apps e operação visual

Nginx Proxy Manager é uma imagem Docker baseada em Nginx com interface para criar Proxy Hosts, configurar SSL e usar certificados Let’s Encrypt ou certificados próprios. O projeto também documenta listas de acesso, HTTP Basic Auth, permissões de usuário e audit log. Esses controles ajudam na camada do proxy, mas não substituem a autenticação do n8n, do painel administrativo ou do app publicado.

No setup oficial do Nginx Proxy Manager, o Compose expõe 80, 443 e 81. As duas primeiras atendem HTTP e HTTPS. A porta 81 serve ao painel administrativo. Ela não deve ficar aberta indiscriminadamente na internet. Restrinja o acesso por firewall, VPN ou rede de administração, com credenciais fortes.

A vantagem do NPM para um solo builder é a velocidade de operação. Você cria um hostname, aponta para o serviço e cuida do certificado pela interface. Para quem tem dois ou três apps estáveis, esse fluxo pode ser mais fácil de revisar do que várias labels distribuídas em arquivos Compose.

A contrapartida é disciplina. Uma alteração feita só pelo painel pode não estar no seu repositório nem no backup que você lembra de restaurar. O próprio modelo visual não é um erro. O erro é tratá-lo como se configuração de proxy não precisasse de histórico, exportação e procedimento de rollback.

Rede Docker e portas internas

NPM pode encaminhar para outro container usando o nome do serviço em uma rede Docker externa, conforme a configuração avançada do Nginx Proxy Manager. Na prática, isso permite que o proxy fale com n8n, chatwoot ou outro serviço sem publicar a porta desse app no host.

Esse é um padrão preferível para aplicações HTTP. Publique o proxy e mantenha as portas internas dos apps fora do host quando elas não precisam ser acessadas diretamente. Também vale observar que os serviços Nginx do container rodam como root por padrão. A documentação oferece PUID e PGID para alterar usuário e grupo, mas isso não resolve todos os riscos do container.

Escolha NPM quando a sua prioridade é administrar poucos hosts com clareza visual. Evite escolhê-lo apenas porque parece simples se ninguém vai guardar backup do banco, dos volumes e da configuração. A interface reduz cliques. Ela não reduz a necessidade de operação.

Traefik para Compose como fonte de verdade

Traefik é mais natural quando os serviços nascem e morrem por Docker Compose. O provider Docker lê a API Docker e pode descobrir containers. As labels passam a declarar regras como hostname, entrypoint e porta interna perto do serviço que será publicado. Para uma stack com muitos projetos, isso torna a rota parte do deploy.

Essa automação exige um default defensivo. A documentação do provider Docker informa que exposedByDefault é true. Ao definir exposedByDefault=false, somente containers com traefik.enable=true entram no roteamento. Em uma VPS com vários serviços, deixe a exposição como opt-in explícito.

O ganho é rastreabilidade. Um pull request ou um commit pode mostrar que determinado serviço passou a responder em um domínio. O custo é que cada pessoa que opera a stack precisa entender labels, redes, certificados e o impacto de mexer no Docker provider. Traefik não é “mais profissional” por si só. Ele é melhor quando essa disciplina cabe na sua rotina.

Dashboard, API e acesso privilegiado ao Docker

O dashboard e a API do Traefik merecem o mesmo cuidado do painel NPM. A documentação diferencia api.insecure de uma exposição customizada. Não trate o modo inseguro como dashboard público seguro. Proteja o acesso com firewall, VPN ou autenticação adequada e evite expor uma tela que revela rotas e serviços da sua infraestrutura.

Há outra fronteira importante: o Docker socket ou a API Docker. Dar acesso a esse recurso permite ao Traefik descobrir containers, o que é útil. Mas essa integração deve ser tratada como superfície privilegiada. Não copie uma configuração de internet sem entender quais permissões o container está recebendo.

Traefik é a escolha mais coerente quando Compose é sua fonte de verdade. Ele encaixa bem em stacks com vários serviços, ambientes repetíveis e deploy frequente. Se o seu fluxo real é abrir uma interface, criar um host e seguir para o próximo cliente, NPM pode manter a operação mais compreensível.

Cloudflare Tunnel para origem sem inbound

Cloudflare Tunnel atende um caso que proxy local tradicional não resolve sozinho: publicar um serviço quando a origem não deve receber conexões inbound. O cloudflared conecta a VPS à Cloudflare por saída. O hostname público fica na borda, e a regra de ingress define o serviço interno para onde o tráfego seguirá.

Essa arquitetura é interessante para VPS atrás de uma rede restritiva, IP que você não quer expor diretamente ou ambientes em que abrir 80 e 443 não é aceitável. Ela também reduz a quantidade de portas abertas no origin. Mas a decisão cria dependência operacional da conta Cloudflare, do DNS, da conectividade do conector e da própria borda externa.

Para serviços não HTTP, há uma diferença prática. A documentação de setup informa que SSH, TCP e RDP exigem cloudflared também do lado cliente. Não prometa acesso remoto genérico como se o navegador bastasse para qualquer protocolo.

Replicas não são alta disponibilidade completa

Um Tunnel mantém quatro conexões long-lived com dois data centers Cloudflare. Você pode usar réplicas que apontam para o mesmo Tunnel. Ainda assim, a Cloudflare recomenda Load Balancing quando a necessidade inclui traffic steering, lógica de failover ou alertas de health. Réplicas ajudam a manter conexões, mas não viram alta disponibilidade completa por definição.

Também existe uma rotina de atualização. O repositório oficial do cloudflared informa suporte por até um ano após o release mais recente; versões mais antigas podem receber breaking changes sem relação com recursos. Inclua o conector no seu processo de atualização, em vez de tratá-lo como um binário que pode ficar esquecido.

Cloudflare Tunnel é uma boa escolha quando “origin sem inbound” é um requisito. Não o venda como segurança absoluta. O edge não substitui patch de sistema, autenticação da aplicação, gestão de segredos nem backup restaurável. Porta fechada reduz uma superfície. A responsabilidade pela operação continua aberta.

Qual caminho encaixa no seu caso?

A tabela não mede performance, RAM ou latência. A pesquisa não encontrou benchmark oficial controlado entre as três opções. Não use números fixos de consumo para decidir. O custo real inclui VPS, domínio, DNS, backup de volumes e configuração, horas de manutenção, monitoramento e suporte. Software open source e certificado Let’s Encrypt não tornam a operação gratuita.

Se suporte em português, cobrança local e uma operação de VPS mais assistida pesam na sua escolha, compare a oferta de VPS Servla para n8n. Se o projeto é WordPress, não uma stack Docker, a necessidade muda: veja a oferta Turbo Cloud para WordPress.

Checklist antes de publicar n8n, Dify ou Portainer

Antes de transformar um container em serviço público, passe por esta lista:

1. Publique somente 80 e 443 quando usar proxy local. Não publique a porta HTTP de cada app sem necessidade.
2. Restrinja NPM:81 e dashboard/API do Traefik por firewall, VPN ou autenticação forte.
3. No Traefik, use exposedByDefault=false e habilite rotas conscientemente com traefik.enable=true.
4. No Tunnel, libere apenas o egress exigido, mantenha token ou credencial fora do repositório e monitore cloudflared.
5. Faça backup restaurável do Compose, das configurações, dos volumes de aplicação e banco. Teste a restauração.
6. Atualize imagens e conector de forma deliberada. Acompanhe releases e changelogs.
7. Documente o rollback: imagem anterior, backup de configuração e rota ou DNS que precisam voltar.
8. Monitore resposta HTTP externa, certificado, disco, CPU, RAM e reinício de containers. Processo ativo não prova que o app responde.

Esse checklist é mais importante do que a marca escolhida. Uma VPS pode ter um proxy bem configurado e ainda falhar porque o banco não tem backup, o disco encheu ou ninguém sabe restaurar a configuração depois de uma atualização.

Quando parar de operar isso sozinho

Autohospedagem vale a pena quando você consegue explicar como o tráfego chega ao app, onde ficam os segredos, como o certificado é renovado e como ocorre a restauração. Ela deixa de valer quando cada mudança exige tentativa e erro em produção ou quando downtime tem custo que você não consegue absorver.

Considere um serviço gerenciado quando ninguém na equipe consegue executar o checklist, quando o aplicativo precisa de alta disponibilidade com health checks e direcionamento de tráfego, ou quando suporte operacional importa mais do que controle total. Para um app novo ou um projeto de vibe coding, reduzir camadas pode ser a decisão mais segura do que montar infraestrutura complexa cedo demais.

Também vale comparar uma plataforma gerenciada se a prioridade é colocar um app no ar, não administrar VPS. Veja o comparativo Vercel, Railway ou Render para entender onde esse modelo se encaixa.

FAQ

Cloudflare Tunnel substitui um proxy reverso?

Nem sempre. Tunnel cria um caminho outbound entre o origin e a borda Cloudflare. NPM e Traefik organizam roteamento local de forma diferente. Para um único serviço, Tunnel pode apontar diretamente para ele. Para vários serviços, ele pode coexistir com um proxy local quando esse desenho simplifica a operação.

Preciso abrir as portas 80 e 443 com Cloudflare Tunnel?

Para HTTP publicado via Tunnel, a documentação Cloudflare informa que não são necessárias portas inbound abertas no origin. A VPS ainda precisa de conectividade de saída para a Cloudflare, incluindo a porta 7844 conforme a configuração oficial. Confirme as regras de firewall antes de bloquear entradas e saídas.

Traefik é melhor que Nginx Proxy Manager para Docker?

Traefik é mais adequado quando a equipe quer que Compose e labels sejam a fonte de verdade das rotas. NPM é mais adequado quando poucos apps precisam de administração visual. “Melhor” depende da rotina de deploy, do número de serviços e da capacidade de manter configuração e backup.

Onde ficam os certificados SSL em cada modelo?

NPM pode emitir certificados Let’s Encrypt ou usar certificados próprios. Traefik usa resolvers ACME e exige que o desafio escolhido seja alcançável quando você usa HTTP-01 ou TLS-ALPN-01. No Tunnel, a TLS pública fica no edge Cloudflare, enquanto a regra pode encaminhar ao origin por HTTP ou HTTPS conforme sua configuração.

Posso usar Cloudflare Tunnel na frente de NPM ou Traefik?

Sim. Tunnel pode encaminhar para um proxy local ou diretamente para um serviço interno. Essa composição deve existir por uma razão operacional clara, como manter o origin sem inbound e ainda centralizar rotas locais. Não adicione as três ferramentas só porque cada uma parece oferecer mais segurança.

Conclusão: escolha a responsabilidade que você consegue sustentar

Nginx Proxy Manager é um bom ponto de partida para poucos apps e operação visual. Traefik ganha sentido quando seu Compose precisa declarar rotas de forma reproduzível. Cloudflare Tunnel é a escolha para origin sem inbound, desde que você aceite operar cloudflared, DNS e a dependência da borda Cloudflare.

A escolha não é de interface. É de Fronteira de Operação. Escolha a camada que você consegue atualizar, auditar e restaurar sem improvisar. Se a VPS é o próximo passo do seu projeto, comece pela oferta de VPS Hostinger para n8n e planeje a operação antes do primeiro deploy público.