Caddy: o servidor web que simplifica hospedagem, HTTPS e proxy reverso

Autor: Pablo Murad
Ano: 2026

Introdução

Caddy é um servidor web moderno, escrito em Go, que pode servir sites estáticos, atuar como proxy reverso, gerenciar certificados HTTPS automaticamente e organizar vários domínios ou subdomínios em um único servidor. Em termos práticos, ele ocupa um espaço parecido com Nginx e Apache, mas com uma filosofia diferente: reduzir a quantidade de configuração necessária para colocar um site no ar com segurança.

A grande promessa do Caddy é simples: você aponta um domínio para o servidor, escreve uma configuração curta, e ele tenta cuidar automaticamente do HTTPS. Isso não significa que ele resolva todos os problemas de infraestrutura, nem que substitua Nginx em qualquer cenário, mas para muitos projetos pequenos e médios ele reduz drasticamente a fricção.

A documentação oficial do Caddy apresenta o uso como proxy reverso como um dos caminhos principais para colocar aplicações em produção, inclusive com HTTPS automático quando o domínio está configurado corretamente. O projeto também mantém releases ativos no GitHub; em junho de 2026, a série estável mais recente era a 2.11.x, com a versão 2.11.4 publicada recentemente.

Referências principais:

• Documentação oficial: https://caddyserver.com/docs/
• Guia de proxy reverso: https://caddyserver.com/docs/quick-starts/reverse-proxy
• HTTPS automático: https://caddyserver.com/docs/automatic-https
• Repositório no GitHub: https://github.com/caddyserver/caddy

O que é o Caddy?

Caddy é um servidor HTTP que pode cumprir várias funções:

1. servir arquivos estáticos;
2. hospedar sites simples;
3. atuar como proxy reverso para aplicações;
4. gerenciar HTTPS automaticamente;
5. redirecionar domínios;
6. balancear requisições entre backends;
7. aplicar autenticação básica;
8. trabalhar em ambientes com Docker;
9. expor APIs, painéis e serviços internos de forma organizada.

A configuração mais comum do Caddy é feita pelo arquivo chamado Caddyfile. Ele é propositalmente mais legível e direto do que muitas configurações equivalentes em Nginx.

Um exemplo mínimo:

meusite.com {
    root * /var/www/meusite
    file_server
}

Essa configuração diz: para o domínio meusite.com, sirva os arquivos da pasta /var/www/meusite.

Se o domínio apontar corretamente para o servidor e as portas necessárias estiverem acessíveis, o Caddy pode obter e renovar certificados HTTPS automaticamente.

A principal vantagem: HTTPS automático

O HTTPS é uma das partes mais chatas da hospedagem tradicional. Em muitos setups com Nginx ou Apache, você precisa configurar certificados, instalar Certbot, criar redirecionamentos HTTP para HTTPS, renovar certificados e garantir que nada quebre no caminho.

O Caddy tenta automatizar esse processo.

Um proxy reverso para uma aplicação local pode ser tão simples quanto:

app.exemplo.com {
    reverse_proxy localhost:3000
}

Nesse exemplo, o Caddy recebe as conexões externas em app.exemplo.com e encaminha as requisições para uma aplicação rodando localmente na porta 3000.

Na prática, isso é excelente para aplicações Node.js, Python, Go, PHP, painéis administrativos, APIs, bots, dashboards e sistemas internos.

Servindo um site estático

Para um site estático, a configuração é curta:

site.exemplo.com {
    root * /var/www/site
    file_server
}

A pasta /var/www/site pode conter arquivos como:

index.html
style.css
script.js
imagens/

Esse tipo de uso é perfeito para:

• páginas pessoais;
• documentação;
• landing pages;
• blogs estáticos;
• arquivos HTML simples;
• páginas geradas por Hugo, Jekyll, Astro, Eleventy ou Vite.

Também dá para criar respostas extremamente simples sem nem criar um arquivo HTML:

texto.exemplo.com {
    respond "Olá, mundo!"
}

Isso é útil para testes, páginas mínimas, endpoints simples e experimentos.

Caddy como proxy reverso

O uso mais poderoso do Caddy é como proxy reverso.

Imagine que você tem três serviços rodando no mesmo servidor:

• aplicação principal na porta 3000;
• API na porta 8000;
• painel administrativo na porta 8080.

O Caddyfile poderia ficar assim:

site.exemplo.com {
    reverse_proxy localhost:3000
}

api.exemplo.com {
    reverse_proxy localhost:8000
}

admin.exemplo.com {
    reverse_proxy localhost:8080
}

Com isso, cada subdomínio aponta para um serviço diferente. O usuário acessa tudo pelo navegador, com domínio bonito e HTTPS, enquanto as aplicações ficam isoladas em portas internas.

Esse modelo é especialmente útil em servidores com Docker, porque você pode expor apenas o Caddy nas portas 80 e 443, deixando os demais containers acessíveis somente dentro da rede interna do Docker.

Usando Caddy com Docker

Um exemplo básico de docker-compose.yml para Caddy:

services:
  caddy:
    image: caddy:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

O volume caddy_data é importante porque guarda dados persistentes, incluindo certificados. Apagar esse volume sem necessidade pode forçar o Caddy a emitir certificados novamente, o que pode esbarrar em limites de autoridade certificadora.

Com Docker, uma configuração típica poderia ser:

app.exemplo.com {
    reverse_proxy app:3000
}

Aqui, app seria o nome de outro serviço no mesmo docker-compose.yml.

Caddy em servidor local com CGNAT

Caddy pode rodar perfeitamente em um servidor local, mesmo atrás de CGNAT. O problema é outro: CGNAT normalmente impede que conexões externas cheguem diretamente à sua máquina.

Ou seja: o Caddy funciona, mas a internet não consegue entrar até ele sozinha.

Para hospedar publicamente atrás de CGNAT, você precisa de uma camada intermediária, como:

• Cloudflare Tunnel;
• Tailscale Funnel;
• ngrok;
• uma VPS pública como ponte;
• IPv6 público;
• IP público fixo contratado com a operadora.

Uma arquitetura comum seria:

Internet
   ↓
Cloudflare Tunnel / VPS / Tailscale / ngrok
   ↓
Servidor local atrás de CGNAT
   ↓
Caddy
   ↓
Site ou aplicação

Nesse cenário, Caddy continua sendo útil para organizar os serviços locais, mas ele não é o responsável por furar o CGNAT.

Prós do Caddy

1. Configuração muito simples

O Caddyfile é direto. Em muitos casos, poucas linhas resolvem o que em Nginx exigiria blocos maiores de configuração.

Exemplo:

meusite.com {
    reverse_proxy localhost:3000
}

Isso é difícil de bater em simplicidade.

2. HTTPS automático

Este é o grande diferencial. O Caddy tenta emitir e renovar certificados automaticamente. Para servidores pequenos e médios, isso reduz erro humano e economiza tempo.

3. Excelente para projetos pessoais e pequenos serviços

Caddy é ótimo para VPS pessoal, homelab, dashboards, APIs, bots, landing pages e ferramentas internas.

4. Boa integração com Docker

Ele funciona muito bem como ponto de entrada para múltiplos containers.

5. Configuração legível

Um Caddyfile bem escrito é fácil de entender meses depois. Isso parece detalhe, mas não é. Configuração ilegível vira dívida técnica.

6. Menos necessidade de Certbot

Em muitos cenários, você não precisa instalar e manter Certbot separadamente.

7. Bom para múltiplos subdomínios

Você pode organizar vários serviços assim:

app.exemplo.com {
    reverse_proxy localhost:3000
}

api.exemplo.com {
    reverse_proxy localhost:8000
}

docs.exemplo.com {
    root * /var/www/docs
    file_server
}

Simples, limpo e fácil de versionar.

Contras do Caddy

1. Menor ecossistema que Nginx e Apache

Nginx e Apache existem há muito tempo e têm uma base gigantesca de tutoriais, módulos, exemplos, painéis e casos de uso documentados. Caddy é maduro, mas o ecossistema ao redor ainda é menor.

2. Algumas customizações exigem plugins

Caddy é extensível, mas alguns recursos dependem de plugins. Isso pode complicar instalação, empacotamento e atualização, especialmente em produção.

Um exemplo comum é usar DNS challenge para emitir certificados em cenários onde as portas 80 e 443 não estão acessíveis. Dependendo do provedor DNS, pode ser necessário usar uma build customizada com plugin.

3. Menos comum em ambientes corporativos tradicionais

Muitas empresas ainda padronizam Nginx, Apache, HAProxy ou balanceadores gerenciados em cloud. Isso não torna o Caddy ruim, mas pode dificultar adoção em equipe.

4. Menos material para tuning extremo

Para tráfego muito alto, caching agressivo, mirrors públicos, CDNs próprias ou regras finas de performance, Nginx ainda costuma ser a opção mais conhecida e documentada.

5. Automação demais pode esconder detalhes

O HTTPS automático é ótimo, mas também pode criar uma falsa sensação de que tudo é mágico. Em produção, você ainda precisa entender DNS, portas, firewall, certificados, logs, proxy headers e comportamento de cache.

6. Não resolve problemas de rede

Caddy não fura CGNAT, não substitui uma VPS pública, não conserta DNS errado e não transforma internet residencial em infraestrutura de alta disponibilidade.

Caddy vs Nginx

A comparação honesta é esta:

Caddy não é simplesmente “melhor que Nginx”. Ele é melhor quando a prioridade é simplicidade, velocidade de configuração e HTTPS automático. Nginx continua fortíssimo quando a prioridade é controle fino, tradição operacional e ambientes de alto tráfego já consolidados.

Quando usar Caddy

Use Caddy quando você quer:

• subir um site rapidamente;
• hospedar uma aplicação pessoal;
• criar um proxy reverso simples;
• expor serviços em subdomínios;
• evitar dor de cabeça com HTTPS;
• organizar aplicações Docker;
• hospedar páginas estáticas;
• criar protótipos públicos;
• manter uma VPS com vários serviços pequenos.

Exemplo de caso ideal:

Uma VPS pequena rodando:
- app Node.js;
- API Python;
- documentação estática;
- painel administrativo;
- blog pessoal.

Caddy encaixa muito bem aí.

Quando não usar Caddy

Evite ou avalie com cuidado quando você tem:

• infraestrutura Nginx já madura e estável;
• tráfego altíssimo;
• mirror público de arquivos pesados;
• regras complexas de cache;
• equipe acostumada com outro stack;
• dependência de módulos específicos do Nginx ou Apache;
• necessidade de suporte empresarial padronizado;
• ambiente onde qualquer comportamento automático é indesejado.

Para um mirror público grande, por exemplo, Caddy pode até funcionar, mas eu não trocaria um Nginx bem configurado apenas por curiosidade. Mirror de distribuição Linux precisa de previsibilidade, bom suporte a arquivos grandes, ranges, logs claros, estabilidade e comportamento sob carga. Nesse caso, conservadorismo técnico é virtude, não atraso.

Exemplo completo de Caddyfile

# Site estático
site.exemplo.com {
    root * /var/www/site
    file_server
}

# Aplicação Node.js
app.exemplo.com {
    reverse_proxy localhost:3000
}

# API Python
api.exemplo.com {
    reverse_proxy localhost:8000
}

# Painel administrativo com autenticação básica
admin.exemplo.com {
    basicauth {
        usuario $2a$14$HASH_DA_SENHA_AQUI
    }

    reverse_proxy localhost:8080
}

# Redirecionamento de www para domínio sem www
www.exemplo.com {
    redir https://exemplo.com{uri} permanent
}

Esse exemplo mostra bem a proposta do Caddy: uma configuração legível que cobre vários cenários comuns.

Segurança: o que ainda depende de você

Caddy ajuda, mas não faz milagre. Você ainda precisa cuidar de:

• firewall;
• atualizações do sistema;
• permissões dos arquivos;
• backups;
• logs;
• senhas fortes;
• isolamento de containers;
• proteção de painéis administrativos;
• variáveis de ambiente;
• headers de segurança quando necessário;
• rate limiting, se o cenário exigir;
• exposição indevida de portas internas.

Um erro comum é achar que HTTPS automático significa “servidor seguro”. Não significa. HTTPS protege o transporte. Ele não corrige aplicação vulnerável, senha fraca, painel exposto ou container mal configurado.

Conclusão

Caddy é uma excelente ferramenta para quem quer hospedar sites e aplicações com menos burocracia. Ele brilha quando usado como servidor web simples, proxy reverso e gerenciador automático de HTTPS. Para projetos pessoais, pequenas empresas, homelabs, VPS com múltiplos subdomínios e aplicações Docker, ele pode economizar muito tempo.

Mas ele não deve ser tratado como solução universal. Para ambientes extremamente otimizados, infraestruturas legadas, mirrors públicos pesados ou operações com regras muito específicas, Nginx, Apache ou HAProxy ainda podem ser escolhas mais conservadoras e apropriadas.

A melhor leitura é esta: Caddy não substitui conhecimento de infraestrutura. Ele remove uma parte grande da burocracia. Quem entende isso usa bem. Quem acha que ele é mágica só troca um problema por outro.

Para começar, a experiência mínima é simples:

meusite.com {
    root * /var/www/meusite
    file_server
}

Ou, para uma aplicação local:

app.meusite.com {
    reverse_proxy localhost:3000
}

Poucas ferramentas entregam tanto com tão pouca configuração. Esse é o verdadeiro mérito do Caddy.