Migrar do nginx, Apache ou Traefik para o Caddy

Receita de um clique que traduz sua configuração atual de proxy reverso para um Caddyfile, ensaia em portas alternativas enquanto o mecanismo antigo continua servindo o tráfego real e depois faz a troca de forma atômica. O rollback automático entra em ação se qualquer verificação falhar. Depois da migração, todos os fluxos do Server Manager (deploy, conectar domínio, instalar WordPress, …) funcionam diretamente, sem passar pelo fallback do chat.

Última atualização 26 de mai. de 2026

O Server Manager tem uma preferência clara por — todas as receitas e assistentes escrevem blocos de , não blocos server { } do nginx, <VirtualHost> do Apache nem labels Docker do Traefik. Se o seu servidor estiver rodando um desses hoje, as receitas que precisam mexer na configuração do proxy usam o caminho 💬 pelo chat — elas ainda funcionam, mas você precisa dar uma aprovação extra por ação. A receita Migrar para o Caddy leva você desse estado para um servidor Caddy totalmente gerenciado em ~10 minutos, com uma etapa de ensaio que permite ao Faro verificar se todos os sites foram traduzidos corretamente antes de qualquer troca real.

A receita aceita três mecanismos de origem: nginx, Apache (tanto apache2 no Debian/Ubuntu quanto httpd no RHEL/Fedora) e Traefik (provedor por labels Docker). O formato da migração é o mesmo para os três — só mudam os detalhes do lado da origem.

1. Abra Informações do servidor → Servidor web

Na barra superior, clique no nome do seu servidor para abrir o e depois clique na aba ****.

Painel Informações do servidor com a aba Servidor web aberta, mostrando nginx como mecanismo atual e um botão Migrar para o Caddy

A aba mostra:

Mecanismo — o que está rodando nas portas 80 / 443 agora (nginx / Apache / Traefik / Caddy / nenhum).
Vhosts detectados — quantos sites o mecanismo está servindo (no Traefik, aparecem "routers" no lugar).
Certificados TLS — quem gerencia seus certificados HTTPS (normalmente certbot para nginx/Apache, ACME integrado do Traefik para Traefik).
Gerenciabilidade — uma verificação de traduzibilidade: um ✓ verde significa que todos os sites usam diretivas que a receita sabe converter; um ✗ vermelho mostra qual diretiva está no caminho (mod_lua, proxy_cache_path, cadeias complexas de RewriteRule, middlewares do Traefik etc.). Se aparecer um ✗ vermelho, a receita se recusa a rodar até você remover a diretiva incompatível — isso é intencional: a receita nunca perde comportamento silenciosamente.

2. Clique em Migrar para o Caddy

Clique no botão Migrar este servidor para o Caddy →. O Server Manager abre o painel de chat, e o Faro assume a partir daí.

Close da aba Servidor web: o botão Migrar este servidor para o Caddy é o CTA marcado como destrutivo abaixo da verificação de gerenciabilidade

A receita roda em 5 fases. A Fase 0 é somente leitura (apenas uma rodada de verificação). As Fases 1–4 pausam para sua aprovação antes de executar qualquer comando destrutivo. Você pode cancelar a qualquer momento — até a troca atômica da Fase 4, o mecanismo atual continua dono das portas públicas e seus sites seguem servindo tráfego sem mudanças.

3. Aprove cada fase

O Faro explica o que vai acontecer antes de cada aprovação. Os pacotes são curtos e focados.

Fase 0 — Pré-verificação. Somente leitura: enumera seus vhosts atuais, verifica diretivas incompatíveis e encontra o e-mail de administrador do Let's Encrypt. Termina com um plano em linguagem simples + um botão Reply: go. Clique nele (ou digite go) para começar.
Fase 1 — Instalar o Caddy. Adiciona o repositório oficial do Caddy, instala o pacote e interrompe o serviço imediatamente. O mecanismo atual continua dono das portas.
Fase 2 — Traduzir. Escreve um Caddyfile candidato em /tmp e o valida. Nada em produção muda ainda.
Fase 3 — Ensaiar. Inicia o Caddy em portas alternativas :8080 / :8443 para que ele possa ser testado sem tocar no tráfego real. Em seguida, o próprio Faro roda testes curl em loopback (HTTPS, redirecionamento HTTP→HTTPS, rota de desafio ACME) e mostra as evidências de resposta por domínio. O mecanismo atual ainda serve as portas reais :80 / :443.

Evidências da Fase 3: resumo em linguagem simples do Faro por domínio com os resultados do curl em loopback, terminando com "ensaio aprovado — pronto para a troca da Fase 4"

Fase 4 — Troca atômica. Faz backup da configuração atual (/etc/nginx.helm-backup.<timestamp>/ ou /etc/apache2.helm-backup.<timestamp>/ ou /tmp/traefik.helm-backup.compose.*.yml), para o mecanismo antigo, inicia o Caddy nas portas reais :80 / :443, verifica todos os domínios com mais uma rodada de curl e depois muda o certbot.timer atual do modo de renovação por plugin do mecanismo (certbot --nginx, certbot --apache) para o modo webroot que o Caddy consegue servir. O certbot.timer continua responsável pela renovação; um deploy-hook recarrega o Caddy a cada renovação, então você não precisa mexer em nada.

Se a verificação falhar em qualquer ponto da Fase 4, a receita faz rollback automático: para o Caddy, reinicia o mecanismo antigo e deixa sua configuração atual intacta. Você volta ao estado anterior à migração em <10 segundos.

4. Confirme + transferência

Depois que a Fase 4 for concluída com sucesso, o Faro pede que você abra Informações do servidor → Servidor web mais uma vez para confirmar.

Aba Servidor web após a migração: mecanismo mostra Caddy (serviço no host), TLS mostra "certbot (Let's Encrypt, renovado pelo certbot.timer; servido pelo Caddy via recarregamento por deploy-hook)", Status mostra o ✓ verde de ponta a ponta

A aba se atualiza sozinha ao abrir (não é preciso desconectar/reconectar). Você deve ver:

Mecanismo: Caddy (serviço no host)
Certificados TLS — para migrações de nginx/Apache: certbot (Let's Encrypt, renewed by certbot.timer; served by Caddy via deploy-hook reload). Para migrações de Traefik: Caddy ACME (automatic Let's Encrypt) — os certificados antigos do Traefik em acme.json não são reutilizados; o Caddy obtém novos durante a troca.
Status: ✓ O Server Manager gerencia este servidor de ponta a ponta. Todas as receitas e assistentes funcionam diretamente; nada é encaminhado para o fallback exclusivo do chat.

O pacote do mecanismo antigo permanece instalado (mas desativado) por ~30 dias como opção de rollback manual. O backup da configuração também fica no disco. Quando você estiver confiante de que a migração está estável (~1 semana), pode usar apt remove nginx / apt remove apache2 para liberar alguns MB ou parar o contêiner antigo do Traefik com docker rm traefik.

Observações por mecanismo

O modelo ensaiar-e-depois-trocar é o mesmo em todos os mecanismos. As diferenças são mecânicas:

nginx. Sondagem do mecanismo de origem via sudo nginx -T. Backup em /etc/nginx.helm-backup.<ts>/. Transferência da renovação: authenticator = nginx → authenticator = webroot em /etc/letsencrypt/renewal/<domain>.conf. O plugin certbot --nginx deixa de ser usado; o certbot.timer continua rodando.

Apache. Mesmo formato, com caminhos trocados para apache2 (Debian) ou httpd (RHEL). Enumeração de vhosts via apache2ctl -S + leitura de sites-enabled/ (ou conf.d/ no RHEL). Backup em /etc/apache2.helm-backup.<ts>/. Transferência da renovação: authenticator = apache → webroot. Configurações com mod_php são marcadas como não gerenciáveis até você removê-las — o Caddy não roda PHP dentro do próprio processo como o Apache + mod_php faz.

Traefik. O mecanismo de origem é um contêiner Docker, parado com docker stop traefik (não systemctl stop). Os vhosts vêm de labels traefik.http.routers.* em contêineres em execução, não de arquivos de configuração. A reutilização de certificados é pulada — o Caddy obtém novos certificados Let's Encrypt via auto-HTTPS durante a troca, consumindo uma nova emissão por domínio (janela de certificado de ~30–60 segundos). Routers com middlewares personalizados ou matchers que não sejam Host() são marcados como não gerenciáveis. Os backends precisam ter portas publicadas no host (por exemplo, 127.0.0.1:8080:80 no arquivo compose) — o Caddy como serviço no host não consegue acessar contêineres disponíveis apenas na rede do Docker.

E se a receita se recusar?

Se a verificação de gerenciabilidade mostrar um ✗ vermelho, o Faro informa a diretiva e o vhost exatos. Correções comuns:

**nginx proxy_cache_path / fastcgi_cache** — isso não tem tradução 1:1 para o Caddy. Remova a zona de cache (ou mova o cache para uma CDN como Cloudflare) e tente novamente. A maioria dos usuários que não usam Caddy em servidores pequenos não precisa de cache local no servidor.
**Apache RewriteRule ... [L,R=301]** — pacotes de flags indicam cadeias de várias etapas que o tradutor não consegue modelar. Converta para um Redirect permanent mais simples ou achate a cadeia antes.
Middlewares do Traefik — middlewares exigem tradução para Caddy por tipo, e a receita não faz isso automaticamente na v1. Remova as labels de middleware e aplique o equivalente no Caddy depois da migração (autenticação básica, limite de taxa, headers — tudo suportado, apenas não traduzido automaticamente).
**Regra HostRegexp do Traefik** — matchers com regex não têm tradução 1:1. Troque por uma ou mais regras Host() com nomes de host explícitos.

Se você não conseguir simplificar sua configuração e não quiser migrar, o caminho pelo chat continua funcionando para tudo que o Server Manager normalmente faria por receitas — fazer deploy de um site, instalar WordPress, conectar um domínio, configurar um banco de dados, criar um backup, restaurar a partir de um backup etc. O Faro lê o mecanismo atual e propõe os comandos nativos corretos (/etc/nginx/sites-available/ + certbot --nginx para nginx, o equivalente no Apache, labels Docker para Traefik). Exemplos concretos de pedidos que funcionam hoje em um servidor que não usa Caddy:

"Adicione um novo site WordPress em blog.mysite.com neste servidor nginx" — o Faro propõe o vhost do nginx + o docker compose do WordPress + certbot. Você aprova cada pacote.
"Meu certificado TLS de api.mysite.com está prestes a expirar — verifique e renove se necessário" — o Faro roda a inspeção + a renovação + o reload, tudo pelo chat.
"Faça um backup da carga de trabalho api.mysite.com" — o Faro descobre o que precisa ser exportado + como empacotar + oferece o link de download.

Você não perde recursos ao continuar no mecanismo atual. Você troca conveniências de UI com um clique por equivalentes mediados pelo chat.

Referência

Arquivos escritos no seu servidor durante a migração:

/etc/caddy/Caddyfile — configuração de sites do Caddy (nova neste servidor)
/var/www/certbot/.well-known/acme-challenge/ — webroot para renovações ACME (nginx + Apache; não usado em migrações de Traefik)
/etc/letsencrypt/renewal-hooks/deploy/reload-caddy.sh — recarrega o Caddy a cada renovação do certbot (somente nginx + Apache)
/etc/letsencrypt/renewal/<domain>.conf — editado de forma cirúrgica para trocar authenticator = nginx / authenticator = apache → authenticator = webroot (somente nginx + Apache)

Arquivos / estado preservados para rollback:

nginx: /etc/nginx.helm-backup.<timestamp>/ (cópia completa da configuração)
Apache: /etc/apache2.helm-backup.<timestamp>/ (Debian) ou /etc/httpd.helm-backup.<timestamp>/ (RHEL)
Traefik: /tmp/traefik.helm-backup.compose.<timestamp>.yml (o arquivo docker-compose), mais o próprio contêiner Traefik parado
O pacote do mecanismo antigo permanece instalado, mas desativado (systemctl disable apache2 / nginx; docker update --restart=no traefik)

Portões de aprovação: normalmente 4 cliques para nginx e Apache, 5 para Traefik (o clique extra acontece quando o Faro precisa escolher uma porta de ensaio fora do padrão se o seu backend já usa :8080).