Cloudflare Tunnel: exponha seu homelab com segurança

Cloudflare Tunnel é a forma mais simples que eu conheço de acessar um serviço do seu homelab de fora de casa sem abrir uma única porta no roteador. Um programa pequeno, o cloudflared, roda na sua máquina e abre uma conexão de saída até a rede da Cloudflare, e é por esse caminho que o tráfego chega ao painel, ao n8n ou ao dashboard que você quer usar na rua. Neste guia tem o que é, quanto custa, o arquivo de configuração explicado linha a linha, os erros que aparecem e o ponto em que ele deixa de bastar.

Se você já tentou expor um painel que sobe num container e travou na parte de port forwarding, IP dinâmico e certificado, esse é o tipo de problema que ele resolve. Eu uso isso no meu setup há um tempo. Tenho um Raspberry Pi e dois containers rodando em casa, e até pouco tempo atrás eu fazia a gangorra de sempre: abrir porta, configurar DDNS, rezar para o provedor não trocar meu IP. Funcionava, só que estava longe do ideal, e o caminho que ficou mais limpo é o que está aqui.

Todo número de versão, limite e preço deste texto foi conferido na documentação oficial da Cloudflare em 15/09/2026, com o endereço nas tabelas. Isso importa mais do que parece, porque a Cloudflare reorganizou a documentação do Tunnel e várias páginas que os tutoriais antigos linkam hoje respondem 404. O comando que você copia de um vídeo de 2022 ainda funciona, mas o painel mudou de lugar e o jeito recomendado de rodar o túnel também.

O que é a Cloudflare e o que é o Cloudflare Tunnel?

A Cloudflare é uma empresa americana que opera uma rede de servidores espalhada pelo mundo e vende serviços em cima dela. DNS, CDN, certificado HTTPS, proteção contra ataque e, no plano gratuito, tudo isso para um site pessoal sem pagar nada. Quando você coloca um domínio na Cloudflare, quem acessa o seu site bate primeiro num servidor deles, que filtra, guarda cópia do que dá para guardar e só então fala com a sua máquina. É por isso que muita gente conhece a Cloudflare só como a tela laranja do DNS.

O Cloudflare Tunnel é um dos produtos dessa rede, e é o que interessa aqui. Ele resolve um problema específico: como fazer a Cloudflare chegar na sua máquina quando ela está atrás de um roteador doméstico, sem IP público e sem porta aberta. A resposta é inverter o sentido da conexão. Em vez de a Cloudflare bater na sua porta, a sua máquina liga para a Cloudflare e fica esperando o tráfego chegar por ali. É o mesmo jeito que o seu navegador abre conexão de saída sem que ninguém precise liberar nada no firewall.

Para quem chega pela busca "cloudflare o que é" e só quer a resposta curta, fica assim. A Cloudflare é a rede, o Tunnel é o cabo que liga o seu homelab a essa rede, e o cloudflared é o programa que segura esse cabo do seu lado. O produto está disponível em todos os planos, inclusive no gratuito, e o cloudflared é código aberto, com o repositório no GitHub e versão nova várias vezes por mês. O resto deste guia é sobre como usar esse cabo sem se enforcar nele.

Como o túnel funciona por dentro?

Quando você roda o cloudflared, ele abre quatro conexões de saída, criptografadas, para dois data centers diferentes da Cloudflare, e mantém essas conexões vivas o tempo inteiro. Se um data center cair, as outras conexões seguram o tráfego. Do lado de fora, o seu subdomínio vira um registro CNAME apontando para um endereço do tipo UUID.cfargotunnel.com, e é a Cloudflare que sabe qual túnel responde por ele. Quem acessa recebe HTTPS válido sem você instalar certificado nenhum na sua máquina.

O tráfego que chega no subdomínio passa pelas proteções da Cloudflare, cai numa dessas conexões e o cloudflared entrega para o serviço local que você configurou, como http://localhost:5678. Esse mapeamento de hostname para serviço se chama regra de ingress, e um túnel pode ter várias: n8n.seudominio.com.br vai para uma porta, grafana.seudominio.com.br vai para outra. A última regra é sempre um pega-tudo que responde 404 para o que não casou com nada, e sem ela o cloudflared nem sobe.

O detalhe que muda a segurança é que não existe nada escutando na sua rede para o mundo. Um scanner que varre o seu IP não encontra porta aberta porque não tem porta aberta, e o firewall do roteador pode ficar fechado para tudo que entra. A documentação da Cloudflare chega a recomendar exatamente isso: bloquear todo tráfego de entrada e liberar só a saída na porta 7844. É a porta que o cloudflared usa para falar com a rede deles, em TCP e UDP.

Quando vale usar e quando é exagero?

Cloudflare Tunnel faz sentido quando você tem um serviço que precisa ser acessado de fora, mas não quer ou não pode abrir portas. Painel de automação, um Grafana, um WebUI de IA, aquele dashboard interno que você quer abrir no celular na rua. Os sinais de que é a hora são bem claros, e quase todo mundo que tem homelab reconhece pelo menos um deles na própria rotina.

• O seu IP é dinâmico e o DDNS vive te traindo, com o acesso caindo justamente no dia em que você precisa dele.
• O roteador é do provedor, e mexer em NAT ali é uma novela que às vezes nem tem final feliz.
• Você quer autenticação na frente do serviço sem implementar login do zero em cada aplicação.
• Está atrás de CGNAT, e simplesmente não existe porta para abrir porque o IP público é compartilhado com outros clientes.

Agora, onde é exagero. Se o serviço só roda na sua rede local e você nunca acessa de fora, não precisa de túnel nenhum, e cada coisa exposta é uma coisa a mais para manter. Se você já tem uma VPN bem montada e acessa tudo por ela, o túnel vira redundância para o acesso pessoal. Ele só volta a fazer sentido quando alguém que não tem a VPN precisa entrar, como um cliente ou um webhook. Na minha visão, a regra é uma só: exponha pela internet só o que você realmente vai usar de fora.

Tem um caso que eu vejo confundir bastante: usar o túnel para servir arquivo pesado ou vídeo. Nos planos Free, Pro e Business, os termos da Cloudflare exigem produto pago específico para vídeo e para volume grande de arquivo passando pela rede deles. A documentação do Tunnel avisa que hostname público está sujeito a essa regra. Um Jellyfin exposto por túnel pode funcionar por um tempo e depois receber aviso, então para mídia o caminho é VPN ou rota privada, não hostname público.

O que precisa ter antes de instalar?

A lista é curta: uma conta na Cloudflare, um domínio com o DNS gerenciado por ela e uma máquina com acesso à internet para rodar o cloudflared. O domínio é o único item que custa dinheiro, e pode ser qualquer um, inclusive um .com.br registrado em outro lugar, desde que os nameservers apontem para a Cloudflare. A máquina pode ser um Raspberry Pi, um mini PC com Proxmox ou um container no mesmo Docker onde os serviços já rodam. Os números que costumam travar estão na tabela.

Dois avisos que a tabela não mostra. No Windows o cloudflared não se atualiza sozinho, você precisa baixar a versão nova de tempos em tempos. E a Cloudflare só dá suporte a versões com até um ano de idade. Na prática, um túnel esquecido num Pi por dois anos pode parar de conectar depois de uma mudança do lado deles. Coloque a atualização na rotina, tem uma seção sobre isso mais abaixo, junto com o cuidado com o token.

Como criar o túnel pelo painel em cinco minutos?

Hoje o caminho recomendado pela própria Cloudflare é criar o túnel no painel e rodar o cloudflared com um token, sem arquivo de configuração na máquina. A vantagem é que a regra de qual subdomínio vai para qual porta fica salva na conta, e você edita pelo navegador sem reiniciar nada. O fluxo tem quatro passos e leva menos tempo do que ler esta seção, o que costuma travar vem depois dele.

1. No painel, entre em Networking, depois Tunnels, e clique em Create Tunnel. Dê um nome, como meu-homelab.
2. Escolha o sistema da máquina em Setup Environment e copie o comando de instalação que aparece, ele já traz o token do túnel.
3. Rode o comando na máquina. No Linux ele instala o cloudflared como serviço do systemd, que sobe junto com o sistema.
4. Em Routes, clique em Add route, escolha Published application, digite o subdomínio e o endereço local do serviço, tipo http://localhost:5678.

Quando o túnel conecta, o status na lista muda para Healthy e o registro DNS do subdomínio é criado sozinho, apontando para o túnel. O que costuma travar é o endereço do serviço: ele é visto a partir da máquina onde o cloudflared roda, não a partir do seu notebook. Se o serviço está noutra máquina da rede, o endereço é o IP interno dela, como http://192.168.1.50:5678. Se o serviço é um container no mesmo Compose, é o nome do container, como explico na seção seguinte.

Para testar sem conta nenhuma, existe o quick tunnel: cloudflared tunnel --url http://localhost:8080 gera um endereço aleatório em trycloudflare.com que morre quando você fecha o terminal. Serve para mostrar algo para alguém por dez minutos ou para receber um webhook em desenvolvimento, e para nada além disso. Tem limite de 200 requisições simultâneas, não suporta Server-Sent Events e o endereço muda a cada execução.

Como fica o compose com o cloudflared como mais um container?

Se os seus serviços vivem em containers, o jeito mais limpo é subir o cloudflared como mais um serviço do mesmo compose.yaml, na mesma rede dos outros. Isso mantém o homelab organizado, o túnel reinicia junto com o resto e o token fica no .env em vez de solto num comando. O exemplo abaixo expõe um n8n, que é o serviço que mais gente quer acessar de fora, e eu rodei ele com docker compose config para garantir que o arquivo é válido antes de colar aqui.

services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment: {N8N_HOST: n8n.exemplo.com.br, WEBHOOK_URL: "https://n8n.exemplo.com.br/", GENERIC_TIMEZONE: America/Sao_Paulo}
    volumes: ["n8n_data:/home/node/.n8n"]

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment: {TUNNEL_TOKEN: "${TUNNEL_TOKEN}"}
    depends_on: [n8n]

volumes:
  n8n_data: {}

Linha a linha, começando pelo n8n. A imagem é a oficial e restart unless-stopped faz o container voltar depois de um reboot. As variáveis dizem ao n8n qual é o endereço público dele, porque é com esse endereço que ele monta as URLs de webhook. Sem N8N_HOST e WEBHOOK_URL, o n8n gera webhook apontando para localhost, e o serviço externo que tenta chamar nunca chega. O volume guarda o banco interno e as credenciais, então ele não pode faltar.

Repare que o n8n não tem a chave ports. Ele não precisa: quem fala com ele é o cloudflared, que está na mesma rede interna do Compose e enxerga o container pelo nome. Essa é a parte que mais engana quem vem de tutorial com localhost. No painel da Cloudflare o endereço do serviço tem que ser http://n8n:5678, o nome do serviço e a porta que ele escuta dentro do container. Não pode ser http://localhost:5678, porque dentro do container do cloudflared não tem ninguém escutando nessa porta.

No cloudflared, o comando tunnel --no-autoupdate run sobe o túnel e desliga a atualização automática, que dentro de container não faz sentido porque a versão vem da imagem. O token entra pela variável TUNNEL_TOKEN, que é o nome que o próprio cloudflared reconhece e que o guia oficial de Kubernetes usa, então não precisa passar --token na linha de comando. O depends_on só ordena a subida, não espera o n8n ficar pronto, e aqui não faz diferença, porque o cloudflared tenta de novo sozinho quando a origem não responde.

O token vem do arquivo .env, ao lado do compose.yaml, com uma linha só: TUNNEL_TOKEN=cole-aqui-o-token-do-painel. Esse arquivo não vai para o repositório, e a razão está na documentação, sem meias palavras: quem tem o token roda o túnel. Se você já usa Compose no dia a dia mas nunca parou para entender ordem de subida, rede e volume, vale ler o guia de Docker Compose do zero. Ele cobre isso do requisito da máquina até o momento em que o Compose deixa de bastar.

Como fica o config.yml de um túnel gerenciado na máquina?

O outro jeito de rodar é o túnel gerenciado localmente, com um arquivo config.yml que fica na máquina e diz quais subdomínios vão para quais serviços. É o modelo que os tutoriais mais antigos ensinam e o que quem prefere versionar a configuração ainda escolhe. O fluxo pela linha de comando tem três comandos. O cloudflared tunnel login abre o navegador e grava um certificado da conta. O cloudflared tunnel create meu-homelab cria o túnel e o arquivo de credenciais. E o cloudflared tunnel route dns meu-homelab n8n.exemplo.com.br cria o CNAME no DNS.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /home/pi/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
ingress: [
  {hostname: n8n.exemplo.com.br, service: "http://localhost:5678"},
  {hostname: grafana.exemplo.com.br, service: "http://localhost:3000"},
  {hostname: ssh.exemplo.com.br, service: "ssh://localhost:22"},
  {service: "http_status:404"}
]

A primeira linha é o UUID do túnel, que o comando create imprime, e a segunda é o caminho do arquivo JSON de credenciais que ele gerou. Repare no /home/pi. Quando o serviço é instalado com sudo, o HOME vira /root e o cloudflared procura o config no lugar errado, um erro tão comum que a documentação tem um parágrafo só para ele. O jeito de evitar é instalar apontando o caminho: sudo cloudflared --config /home/pi/.cloudflared/config.yml service install.

O bloco ingress é lido de cima para baixo, e a primeira regra que casa com o hostname ganha. As três primeiras mapeiam subdomínio para serviço local, e a última, sem hostname, é o pega-tudo obrigatório. Antes de rodar, dois comandos economizam bastante tempo. O cloudflared tunnel ingress validate confere a sintaxe do arquivo. E o cloudflared tunnel ingress rule https://n8n.exemplo.com.br mostra qual regra vai atender aquela URL, o que resolve na hora a dúvida de por que a requisição está caindo no 404.

A regra de SSH merece um comentário, porque ela não funciona como as de HTTP. Quem for conectar precisa ter o cloudflared instalado na própria máquina e usar um ProxyCommand no SSH, já que o navegador não fala SSH e o tráfego passa por WebSocket. Para uso pessoal é ótimo, você acessa o Pi de qualquer lugar sem porta 22 aberta, só que não espere que um script antigo de deploy que usa ssh direto para o IP funcione sem ajuste.

Como colocar login na frente do serviço com o Cloudflare Access?

Subdomínio público sem login é a mesma coisa que porta aberta com nome bonito. Muita gente expõe um painel por túnel, se sente segura porque não abriu porta no roteador, e esquece que a tela de login do n8n agora está na internet para qualquer um tentar. O Cloudflare Access resolve isso na borda. Ele fica na frente do hostname, pede identidade antes de deixar a requisição chegar no cloudflared, e nega tudo por padrão até existir uma política de permissão.

A configuração fica em Zero Trust, Access controls, Applications. Você cria uma aplicação do tipo Self-hosted, adiciona o hostname público e uma política dizendo quem entra, que pode ser só o seu e-mail. Para o método de login, o mais simples é o PIN de uso único por e-mail. Ele precisa ser adicionado como provedor de identidade, porque em organização nova o padrão passou a ser o provedor da própria Cloudflare. Também dá para ligar Google ou GitHub como provedor, sem custo.

O plano gratuito do Zero Trust cobre até 50 usuários, o que para homelab é infinito. O limite que importa é outro. O Access pede login no navegador, então a tela do n8n e do Grafana ficam protegidas. Um webhook que um serviço externo precisa chamar, por outro lado, não pode ficar atrás de PIN, porque o serviço não vai preencher formulário. A saída é um caminho separado para o webhook, com service token do Access ou com a própria aplicação validando a assinatura da chamada.

Cloudflare Tunnel, abrir porta, WireGuard ou Tailscale: qual escolher?

Aqui é onde a escolha fica clara, e a resposta depende de uma pergunta só: quem vai acessar precisa instalar algo? Abrir porta no roteador é o método clássico, funciona, é gratuito e não depende de terceiros. Só que porta aberta é porta escaneável, IP dinâmico quebra o acesso quando você menos espera, e atrás de CGNAT simplesmente não tem porta para abrir. VPN, seja WireGuard na mão ou Tailscale, entrega a rede inteira, só que exige cliente instalado em cada dispositivo que entra.

Na prática, se é homelab pessoal e o que você quer é abrir um painel no celular, o túnel ganha. Ele não pede nada instalado do outro lado e ainda dá HTTPS e login de graça. Se você quer acessar a rede inteira, inclusive o compartilhamento de arquivo e o Proxmox, a VPN é o caminho, e o Tailscale tira o trabalho de configurar chave e porta. Os dois convivem bem: o túnel para o que outras pessoas ou outros sistemas precisam alcançar, a VPN para você. Com IP fixo e controle total do roteador, abrir porta ainda é defensável.

Por que o túnel não substitui o reverse proxy?

Esse é um ponto que confunde bastante gente. O túnel leva o tráfego de fora até a sua máquina e escolhe o serviço pelo hostname, e para dois ou três serviços isso basta. Ele não organiza o que acontece dentro da sua rede. Não faz rota por caminho com reescrita de URL, não gera certificado para acesso interno, não junta vários containers num ponto único de entrada com regra por label. Para várias aplicações atrás de um mesmo ponto de entrada, você ainda quer um reverse proxy fazendo o roteamento interno.

O arranjo que funciona melhor é o túnel entregando tudo para o proxy, com uma regra só, e o proxy decidindo o resto. Se esse é o seu caso, o Traefik com Docker Compose como reverse proxy encaixa bem na frente dos containers, com o túnel só cuidando da entrada externa. A mesma configuração do proxy vale para o acesso pela rede local e pela VPN, que não passam pela Cloudflare. Um detalhe da documentação ajuda aqui: o cloudflared não reescreve o caminho da requisição, então prefixo de URL é trabalho do proxy, não do túnel.

E não esquece do básico de segurança da aplicação em si. Túnel protege a borda, não protege código mal feito. Se a aplicação exposta tem brecha, dá uma revisada nos erros mais comuns do OWASP Top 10 antes de colocar qualquer coisa de fora. A Cloudflare filtra ataque genérico na borda, só que uma injeção de SQL num formulário seu passa pelo túnel do mesmo jeito que passa por porta aberta.

Como cuidar de token, atualização e do que fica exposto?

O token do túnel é o segredo mais importante desse setup, e a documentação é direta: qualquer pessoa com o token roda o túnel. Ou seja, consegue apontar o seu subdomínio para uma máquina dela. Ele fica no .env, fora do repositório, e se vazar o caminho é rotacionar no painel, o que invalida o antigo para conexões novas, e reinstalar o serviço com o token novo. O mesmo vale para o arquivo JSON de credenciais e o cert.pem do modelo local, que vivem na pasta .cloudflared e não devem sair dela.

A segunda rotina é atualizar o cloudflared. No Linux com pacote, um apt-get install --only-upgrade cloudflared seguido de systemctl restart cloudflared resolve. A atualização derruba as conexões por alguns segundos, então faça fora do horário em que alguém depende do serviço. Em container, atualizar é puxar a imagem nova e subir de novo. A Cloudflare mantém compatibilidade com versões de até um ano. É comum um erro esquisito de conexão sumir só de atualizar, tanto que a página de troubleshooting pede isso antes de qualquer outra investigação.

A terceira é a mais simples e a mais ignorada: revisar o que está exposto. Cada hostname público é uma superfície, mesmo atrás de Access, e o painel mostra a lista inteira em Routes. Vale abrir essa lista de tempos em tempos e tirar o que não usa mais, porque o serviço exposto para um teste em março continua no ar em setembro se ninguém apagar. A mesma disciplina que vale para segredo de aplicação vale aqui, e o guia de gestão de segredos em produção mostra onde token e credencial devem morar.

Quais são os erros mais comuns e como corrigir cada um?

Já apanhei o suficiente para te poupar de alguns, e a página de troubleshooting da Cloudflare cobre o resto. A tabela junta os erros que aparecem com mais frequência em homelab, com o sintoma que você vê, a causa que a documentação aponta e a correção. O primeiro passo em quase todos é o mesmo: olhar o log do cloudflared, que no serviço do systemd aparece com journalctl -u cloudflared e em container com docker compose logs cloudflared.

Fora da tabela, o erro que mais vejo em homelab é o túnel Healthy e a página fora do ar. O motivo está na própria documentação: o status do túnel mede só a conexão entre o cloudflared e a Cloudflare, e não diz nada sobre o serviço atrás dele. Healthy com 502 significa que o problema é local, entre o cloudflared e o container, e é ali que se procura. Se você sobe o túnel na mão e fecha o terminal, ele cai junto. Em produção doméstica ele roda como serviço ou como container com restart, nunca solto num terminal.

Quanto custa usar Cloudflare Tunnel?

O Tunnel em si não custa nada e o cloudflared é código aberto. O que você paga é o domínio, e a conta de plano só aparece se quiser recurso que o Free não tem, tipo upload maior que 100 MB, log de acesso guardado por mais de um dia ou regra de WAF avançada. A tabela mostra os planos como estão na página de preços da Cloudflare hoje, em dólar, e os limites que costumam importar para quem expõe serviço de casa.

Para homelab a conta fecha em zero, mais o domínio. O que faz alguém sair do Free costuma ser o limite de upload, que trava quem quer expor um Nextcloud ou um Immich e mandar foto e vídeo pela rede da Cloudflare. Nesse ponto o problema não é preço, é o termo de serviço sobre mídia. O caminho certo para isso é VPN, não plano pago. Se o que está no homelab virou negócio, a conta que importa passa a ser outra, e o texto sobre quanto custa manter um sistema no ar detalha o que entra nela.

Quando o túnel deixa de bastar e o que vem depois?

O túnel resolve o acesso, e resolve bem, só que tem três situações em que ele deixa de ser a resposta. A primeira é volume de arquivo: mídia, backup remoto, sincronização de foto. Aí a regra da Cloudflare sobre vídeo e arquivo grande pesa, e o caminho vira VPN ou rota privada. A segunda é latência: todo pacote vai até o data center da Cloudflare e volta, e para uma tela de painel isso é invisível, para um jogo ou uma sessão de desktop remoto pesada começa a incomodar.

A terceira é quando o serviço deixa de ser seu para ser de um cliente. Um sistema que atende gente pagando não pode depender de um Raspberry Pi atrás da fibra de casa, com um ponto único de falha na energia, na internet e no disco. Nesse momento o serviço muda para uma VPS ou para um servidor com contrato. O túnel pode até continuar como forma de esconder o IP, porque a mesma lógica de infra sem porta pública vale para o servidor de produção, com réplicas do cloudflared para não ter parada em atualização.

Se o homelab em si cresceu, com mais de uma máquina virtual e serviços que precisam de isolamento, o que vem depois é organizar a base. O guia de homelab com Proxmox do zero mostra como montar isso com máquina virtual e container LXC, backup que restaura e rede com IP fixo. O túnel entra ali como a porta de saída de um dos containers, exatamente como neste texto. Para a hospedagem em si, o VPS na prática ajuda a dimensionar a máquina.

Como eu uso o túnel no meu homelab?

O meu caso é pequeno e é justamente por isso que serve de exemplo. São um Raspberry Pi e dois containers em casa, e antes do túnel a rotina era abrir porta, configurar DDNS e torcer para o provedor não trocar o IP no meio da semana. O que mudou é o que este guia descreve: o cloudflared entrou no setup, cada serviço ganhou o próprio subdomínio e a porta do roteador fechou. Para um Pi com dois containers isso basta, e é a mesma base que eu usaria numa operação maior, só com réplica e monitoramento em cima.

O que eu ganhei não foi só comodidade. A superfície de ataque caiu, porque não tem porta para alguém escanear e o tráfego passa pela borda da Cloudflare antes de chegar em mim. E o dia a dia ficou mais simples: reiniciar o roteador ou receber um IP novo do provedor não quebra nada, porque nada depende do meu IP. A parte que ainda exige disciplina é a mesma de qualquer serviço exposto, manter a aplicação atualizada e não deixar painel sem login, e isso nenhum túnel faz por você.

Quando o serviço atrás do túnel deixa de ser um painel pessoal e vira a operação de uma empresa, a lógica de infra sem porta pública continua a mesma. O que muda de peso é o que roda em cima: agente de IA atendendo cliente pelo WhatsApp, fila processando pedido, banco com dado real. É esse tipo de projeto que a SyntaxLab constrói em agentes de IA e automação, com fila persistente, log estruturado e banco na infra do cliente, sem nada aberto para a internet. Para sistema sob medida, o caminho é a página de software sob medida.

Quais são as dúvidas mais comuns sobre Cloudflare Tunnel?

Cloudflare Tunnel é gratuito?

Sim. O plano Free da Cloudflare inclui o Tunnel, com o limite de 1.000 túneis por conta, e o Access, que coloca login na frente, é gratuito para até 50 usuários. O único custo obrigatório é o domínio, que você registra onde quiser e aponta para o DNS da Cloudflare. Para homelab não esbarra em limite; o que pode esbarrar é o termo de serviço sobre vídeo e arquivo grande, que vale para hostname público nos planos Free, Pro e Business.

Preciso de IP fixo para usar?

Não, e esse é justamente um dos motivos de usar. Como a conexão sai da sua máquina para a Cloudflare, o seu IP pode mudar à vontade que o acesso continua funcionando, porque o subdomínio aponta para o túnel, não para o IP. Resolve CGNAT também, que é o cenário em que não existe porta para abrir. A única exigência de rede é conseguir sair na porta 7844, que quase todo roteador doméstico libera por padrão.

Cloudflare Tunnel funciona com qualquer serviço?

Funciona com qualquer coisa que responda em HTTP ou HTTPS na sua rede, direto no navegador, e também com SSH, RDP, SMB e TCP genérico. Para esses protocolos tem uma diferença: quem conecta precisa do cloudflared instalado na própria máquina, porque o tráfego viaja por WebSocket. Para painéis, dashboards, APIs internas e webhooks é direto. O que fica fora é serviço que não é HTTP nem TCP, tipo jogo em UDP, e mídia pesada por hostname público, pelos termos de uso.

É seguro expor um serviço assim?

Mais seguro do que abrir porta, porque não há porta exposta para escaneamento e o tráfego passa pelo filtro da Cloudflare antes de chegar na sua máquina. Ainda assim, ative o Access na frente de tudo que tem tela, mantenha a aplicação e o cloudflared atualizados e guarde o token fora do repositório. Borda segura não conserta aplicação vulnerável: uma falha no código do serviço passa pelo túnel do mesmo jeito que passaria por porta aberta.

Dá para usar um domínio .com.br registrado no Registro.br?

Dá. Você mantém o registro onde está e só troca os nameservers do domínio para os dois que a Cloudflare mostra quando você adiciona o site. A partir daí o DNS é gerenciado por ela, o túnel consegue criar os registros CNAME sozinho e o HTTPS vem junto. No modelo parcial, em que outra empresa continua gerenciando a zona, também funciona, só que o CNAME precisa ser criado na mão lá, e a documentação do Access descreve esse passo extra.

O que acontece se a Cloudflare sair do ar?

O acesso de fora para. Essa é a contrapartida de depender de um intermediário, e vale dizer sem rodeio. O túnel mantém quatro conexões com dois data centers diferentes, então a queda de um deles não derruba nada. Uma falha na rede inteira, por outro lado, deixa o seu subdomínio inacessível até voltar. Os serviços continuam rodando em casa, na rede local, e é por isso que faz sentido manter um caminho alternativo para você mesmo, como uma VPN, para o dia em que a borda não responde.

Por onde começar hoje?

Cloudflare Tunnel é a opção que eu recomendo hoje para quem quer acessar o homelab de fora sem a dor de cabeça de port forwarding, IP dinâmico e certificado. Não é bala de prata, mas para o caso de uso de servidor doméstico resolve com folga e ainda reduz a superfície de ataque. Se você tem um serviço rodando em casa que precisa alcançar de fora, vale testar antes de mexer no roteador, e a ordem que funciona é esta.

• Comece agora: crie o túnel no painel e exponha um serviço de teste seguindo o guia de início oficial do Cloudflare Tunnel, que leva cinco minutos.
• Coloque login: antes de expor qualquer painel de verdade, crie a aplicação no Access com o seu e-mail como única regra de permissão.
• Organize a stack: coloque um reverse proxy na frente dos containers para não depender só do túnel, e mantenha o token no .env.
• Acompanhe a operação: monte um painel básico com o Prometheus e Grafana via Docker Compose, aproveitando que o cloudflared expõe métricas Prometheus em 127.0.0.1:20241. Ligue também o alerta de saúde do túnel no painel da Cloudflare.