Por que o Server Manager usa Caddy?

O Server Manager tem uma escolha bem definida: toda receita e todo assistente escreve blocos de Caddyfile, não server { } do nginx, <VirtualHost> do Apache nem labels Docker do Traefik. Isso não quer dizer que os outros mecanismos sejam ruins — o nginx, em especial, é um excelente software. É porque o Caddy elimina a parte mais dolorosa de manter um site no ar (HTTPS) sem exigir configuração, e os outros não. Se você já usa nginx, Apache ou Traefik, o Server Manager detecta sua configuração e você escolhe: continuar com ela (com uma pequena desvantagem na experiência) ou executar a receita Migrar para Caddy com um clique.

O que um proxy reverso faz mesmo?

O proxy reverso é o servidor voltado ao público nas portas 80 (HTTP) e 443 (HTTPS). Os navegadores chegam nele; ele encaminha cada requisição para o app interno correto por trás — seu WordPress, seu app web, sua API. Seus apps escutam em portas internas como 3000 ou 127.0.0.1:8080; o proxy reverso é a porta de entrada que decide o que vai para onde.

Você precisa de um proxy reverso para:

• Servir HTTPS (o ícone de cadeado). Hoje em dia, navegadores se recusam a enviar cookies / senhas / pagamentos por HTTP puro.
• Rodar vários sites em um único servidor com domínios diferentes.
• Esconder portas internas — visitantes acessam https://mysite.com, não https://mysite.com:3000.

As quatro opções mais comuns

A mesma ideia em uma linha para cada um:

• Caddy — "Quero que o HTTPS simplesmente funcione."
• nginx — "Preciso do máximo de vazão e tenho tempo para configurar tudo com cuidado."
• Apache — "Rodo apps PHP corporativos com .htaccess."
• Traefik — "Tudo está no Docker, é só colocar labels."

Por que o Server Manager escolheu Caddy

Três motivos, em ordem de prioridade:

1. HTTPS automático é o recurso mais importante para usuários não técnicos. A maior fonte de atrito ao publicar um site pequeno é lidar com certificados TLS. O Caddy elimina completamente esse atrito. O assistente pede que você digite um domínio; 30 segundos depois, o site está no ar com HTTPS e um certificado válido da Let's Encrypt. Sem instalar certbot, sem escolher plugin, sem cron de renovação, sem editar configuração. Essa é a vitória indiscutível, e não queremos abrir mão dela.
2. Boas configurações padrão reduzem bugs de site quebrado. O Caddy já vem com compressão gzip, HTTP/2, cifras TLS modernas e timeouts sensatos, tudo ativado por padrão. nginx e Apache deixam a maior parte disso desativada — o que significa que uma parcela real de cada implantação com nginx acaba com uma configuração sutilmente abaixo do ideal, sem que a pessoa saiba que precisa corrigir. O Caddy torna o caminho certo o padrão.
3. A sintaxe do Caddyfile é acessível. Faro consegue escrever blocos de Caddyfile com confiabilidade; você consegue lê-los. O equivalente no nginx exige blocos server { listen 80; listen 443 ssl; ssl_certificate /etc/letsencrypt/live/...; ... } com várias linhas, mais difíceis de examinar e mais difíceis para uma LLM gerar com precisão. Sintaxe com menos atrito = menos erros do agente + revisões de aprovação mais limpas.

Do que você abre mão ao escolher Caddy

Tentamos ser honestos sobre os trade-offs. O Caddy não é estritamente melhor em tudo.

• Desempenho máximo com milhões de requisições. O nginx ainda tem vantagem em vazão. Para a maioria dos sites, isso não importa — o gargalo é o seu backend, não o proxy — mas, se você serve centenas de milhões de requisições por dia, o nginx vai usar um pouco menos de CPU.
• Módulos específicos do nginx. mod_lua / OpenResty, proxy_cache_path, limit_req_zone, geoip — esses são recursos reais que o Caddy faz de outro jeito ou não oferece. Se você depende deles, a migração não é algo de um clique.
• **Legado Apache + mod_php.** Alguns apps PHP antigos pressupõem Apache com mod_php (o PHP roda dentro do processo do Apache). O Caddy usa PHP-FPM (processo separado); o resultado funcional é o mesmo, mas, se você tem anos de configuração específica do Apache (.htaccess personalizado, cadeias de mod_rewrite), portar isso dá trabalho.
• Familiaridade da equipe atual. Se sua equipe já conhece nginx a fundo, existe um custo de aprendizado ao trocar. Vale a pena pelo HTTPS automático, mas não é de graça.

Para o público-alvo do Server Manager (equipes pequenas, projetos pessoais, implantações em um único servidor), isso raramente vira problema. A vantagem do HTTPS automático é o que importa no dia a dia.

E se eu mantiver meu mecanismo atual?

Você pode. O Server Manager detecta nginx, Apache e Traefik e oferece dois caminhos com suporte:

• Continuar no seu mecanismo atual. Faro configura tudo nativamente no chat: /etc/nginx/sites-available/ + certbot --nginx para nginx, o equivalente do Apache para Apache, labels Docker para Traefik. O resultado final é o mesmo para cada domínio; a paleta de receitas marca fluxos exclusivos para Caddy com um selo 💬 via chat — eles ainda funcionam, só exigem um clique extra de aprovação em comparação com o caminho ideal do Caddy.
• **Migrar para Caddy** com a receita integrada. Converte sua configuração existente para um Caddyfile, testa em portas alternativas enquanto seu mecanismo atual continua servindo tráfego ao vivo, troca tudo de forma atômica quando dá certo e faz rollback automático em caso de falha. ~10 minutos; compatível com nginx, Apache e Traefik.

Seja qual for sua escolha, seus sites existentes continuam servindo tráfego. A migração é opcional.

Quando NÃO migrar

Não migre para Caddy se qualquer uma destas situações se aplicar:

• Você usa OpenResty / nginx-lua ou outros recursos do nginx que dependem muito de módulos personalizados.
• Você tem regras **Apache .htaccess complexas** com cadeias empilhadas de RewriteRule [L,PT,NE].
• Você roda Traefik com middlewares personalizados (basic auth, rate limit, cadeias de reescrita de headers) — em teoria dá para traduzir, mas a receita v1 não faz isso automaticamente.
• Você é uma hospedagem compartilhada com usuários em quem não confia — talvez você dependa dos modelos de isolamento por usuário do mod_php do Apache, que o Caddy não replica.

A verificação de gerenciabilidade da receita de migração se recusa a rodar quando detecta essas situações. Mas isso vale apenas para a receita de migração automática — todas as outras ações do Server Manager (implantar, instalar WordPress, conectar um domínio, gerenciar backups, depurar um site lento, reiniciar um serviço) continuam funcionando pelo caminho do chat no seu mecanismo existente. Faro se adapta ao proxy que estiver no servidor. Experimente; se um botão da interface estiver bloqueado, Faro vai oferecer fazer o mesmo trabalho por comandos de shell.

Em resumo

O Caddy não é superior em todos os aspectos. Ele é superior na dimensão mais importante para o tipo de servidor que a maioria dos usuários do Server Manager administra: HTTPS automático e confiável, sem configuração. Todo o resto (boas configurações padrão, binário único, sintaxe concisa, recarga em tempo real) reforça essa vitória principal.

Se você já roda nginx / Apache / Traefik e sua configuração atual está saudável, o caminho pelo chat tem suporte completo. Se você quiser a experiência completa do Server Manager com um clique, a receita Migrar para Caddy está a um botão de distância na aba Servidor web de Informações do servidor.