Caddy: ideias legais e práticas para usar em servidores, homelab e projetos web

Autor/compilação: Pablo Murad — 2026
Tema: Caddy, servidor web moderno, proxy reverso e automação de HTTPS

1. O que é o Caddy, em linguagem direta

Caddy é um servidor web moderno escrito em Go. Ele pode servir sites estáticos, funcionar como proxy reverso para aplicações, emitir certificados HTTPS automaticamente, redirecionar domínios, proteger áreas com autenticação básica, servir aplicações PHP via FastCGI, comprimir respostas, gerar logs e organizar vários serviços no mesmo servidor.

A diferença mais chamativa em relação a Nginx e Apache é a simplicidade operacional. Em muitos casos, um site que exigiria vários blocos de configuração e certificados configurados manualmente no Nginx pode virar poucas linhas no Caddy.

Exemplo básico:

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

Se o DNS estiver apontando para o servidor e as portas certas estiverem acessíveis, o Caddy tenta cuidar do HTTPS automaticamente. Isso é o principal charme dele: menos cerimônia para colocar algo no ar.

Fontes úteis:

Documentação oficial do Caddy: https://caddyserver.com/docs/
HTTPS automático: https://caddyserver.com/docs/automatic-https
Caddyfile: https://caddyserver.com/docs/caddyfile

2. Hospedar sites estáticos simples

Um dos usos mais diretos do Caddy é hospedar sites HTML, CSS, JavaScript, imagens, PDFs e arquivos estáticos.

Exemplo:

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

Você coloca um index.html dentro de /var/www/site e pronto. É ótimo para:

páginas pessoais;
zines digitais;
documentação;
landing pages;
páginas de projeto;
arquivos públicos;
pequenos sites institucionais;
páginas feitas em HTML puro.

O Caddy também pode listar diretórios, se você quiser transformar uma pasta em um índice navegável:

arquivos.exemplo.com {
    root * /srv/arquivos
    file_server browse
}

Isso pode ser útil para compartilhar arquivos em rede local, publicar documentos, organizar builds, servir pacotes internos ou manter uma pequena biblioteca digital.

Cuidado: se usar browse, você está expondo a estrutura dos arquivos. Não coloque nada sensível nessa pasta.

3. Servir uma página única sem nem criar arquivo HTML

Caddy também consegue responder diretamente com texto.

status.exemplo.com {
    respond "Servidor online. Nada pegando fogo por enquanto."
}

Isso parece bobo, mas é útil para:

endpoint de status;
página temporária de manutenção;
resposta simples para monitoramento;
aviso rápido;
página mínima de contato;
placeholder de domínio.

Exemplo mais elaborado:

manutencao.exemplo.com {
    respond <<HTML
    <!doctype html>
    <html lang="pt-BR">
    <meta charset="utf-8">
    <title>Manutenção</title>
    <h1>Voltamos em breve</h1>
    <p>O serviço está em manutenção programada.</p>
    </html>
    HTML 200
}

Para algo permanente, é melhor usar arquivos reais. Mas para uma página temporária, esse recurso é elegante.

4. Usar como proxy reverso para aplicações

Este talvez seja o uso mais poderoso do Caddy.

Você roda sua aplicação localmente em uma porta, por exemplo:

Node.js em localhost:3000;
Python/FastAPI em localhost:8000;
Flask em localhost:5000;
painel em localhost:8080;
serviço Docker em app:3000.

Depois usa o Caddy para expor essa aplicação com domínio e HTTPS:

app.exemplo.com {
    reverse_proxy localhost:3000
}

Ou:

api.exemplo.com {
    reverse_proxy localhost:8000
}

Isso é excelente para organizar vários serviços:

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

app.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 por HTTPS, mas internamente os serviços podem continuar rodando em portas locais.

Fontes úteis:

Quick-start de proxy reverso: https://caddyserver.com/docs/quick-starts/reverse-proxy
Diretiva reverse_proxy: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy

5. Rodar vários projetos no mesmo servidor

Caddy é muito bom para VPS ou homelab com vários projetos pequenos.

Exemplo:

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

wiki.exemplo.com {
    reverse_proxy localhost:8081
}

notas.exemplo.com {
    reverse_proxy localhost:8082
}

painel.exemplo.com {
    reverse_proxy localhost:9000
}

Isso permite transformar um único servidor em uma pequena central de serviços.

Ideias práticas:

um subdomínio para cada projeto;
um subdomínio para cada bot;
um subdomínio para cada dashboard;
um subdomínio para documentação;
um subdomínio para homologação;
um subdomínio para ambiente de testes.

Exemplo:

bot.exemplo.com {
    reverse_proxy localhost:5000
}

dev.exemplo.com {
    reverse_proxy localhost:5173
}

staging.exemplo.com {
    reverse_proxy localhost:3001
}

6. HTTPS automático sem sofrer com Certbot

O Caddy tenta obter e renovar certificados TLS automaticamente quando você usa nomes de domínio públicos e o servidor está acessível da forma esperada. Ele usa ACME, normalmente com autoridades como Let's Encrypt ou ZeroSSL, dependendo da configuração.

Exemplo simples:

meusite.com {
    reverse_proxy localhost:3000
}

Se meusite.com aponta para o servidor e as portas 80/443 estão corretas, o Caddy tenta resolver a parte de HTTPS.

Isso reduz bastante a dor de cabeça com:

emitir certificado;
renovar certificado;
configurar redirect HTTP para HTTPS;
manter arquivo de certificado;
reiniciar serviço depois da renovação.

Mas não é magia. Para o HTTPS automático funcionar no fluxo normal, o domínio precisa resolver para o servidor e o Caddy precisa conseguir completar os desafios ACME. A documentação oficial informa que o desafio TLS-ALPN exige acesso externo à porta 443, e o DNS challenge é uma alternativa quando o servidor não pode receber conexão externa.

Fonte:

HTTPS automático do Caddy: https://caddyserver.com/docs/automatic-https

7. Usar Caddy em servidor local com CGNAT

Aqui entra uma distinção importante.

Você consegue rodar Caddy em servidor local atrás de CGNAT. O problema é que o mundo externo normalmente não consegue entrar direto na sua rede.

Então, para site público em CGNAT, você precisa de alguma ponte:

Cloudflare Tunnel;
ngrok;
Tailscale Funnel;
VPS intermediária;
WireGuard/Tailscale entre VPS e servidor local;
IPv6 público, se sua operadora fornecer.

Arquitetura típica:

Internet
   ↓
Cloudflare Tunnel / ngrok / VPS
   ↓
Servidor local
   ↓
Caddy
   ↓
Aplicação ou site

Exemplo local:

:8080 {
    root * /var/www/site
    file_server
}

Depois você aponta um túnel para http://localhost:8080.

Opinião direta: Caddy é ótimo dentro desse arranjo, mas ele não fura CGNAT sozinho. Quem fura é o túnel ou a VPS.

8. Usar Caddy com Docker Compose

Caddy combina muito bem com Docker Compose.

Exemplo básico:

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 detalhe importante é o volume /data. A imagem oficial do Caddy informa que o diretório de dados precisa ser persistido, porque ali ficam informações importantes como certificados e estado operacional. Não trate isso como cache descartável.

Fonte:

Imagem oficial do Caddy no Docker Hub: https://hub.docker.com/_/caddy/

Exemplo com aplicação:

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

  app:
    image: node:22
    working_dir: /app
    volumes:
      - ./app:/app
    command: sh -c "npm install && npm run start"
    expose:
      - "3000"

volumes:
  caddy_data:
  caddy_config:

Caddyfile:

app.exemplo.com {
    reverse_proxy app:3000
}

9. Proteger painéis com senha

Caddy pode proteger rotas ou sites com autenticação básica.

Exemplo:

admin.exemplo.com {
    basic_auth {
        pablo $2a$14$HASH_DA_SENHA_AQUI
    }

    reverse_proxy localhost:8080
}

Para gerar hash de senha:

caddy hash-password

Isso é útil para:

painel admin;
Grafana privado;
dashboard de bot;
ambiente de teste;
área de homologação;
pasta de arquivos internos.

Cuidado brutalmente honesto: autenticação básica não é sistema de segurança completo. Use com HTTPS, senha forte e, se o serviço for realmente sensível, prefira VPN, autenticação mais robusta ou restrição por IP. A própria documentação alerta que basic auth não é seguro sobre HTTP puro.

Fonte:

Diretiva basic_auth: https://caddyserver.com/docs/caddyfile/directives/basic_auth

10. Criar rotas diferentes no mesmo domínio

Você pode usar o mesmo domínio e mandar caminhos diferentes para serviços diferentes.

Exemplo:

exemplo.com {
    handle_path /api/* {
        reverse_proxy localhost:8000
    }

    handle_path /admin/* {
        reverse_proxy localhost:8080
    }

    handle {
        root * /var/www/site
        file_server
    }
}

Isso permite:

/api para backend;
/admin para painel;
/docs para documentação;
/ para frontend estático.

Exemplo para app SPA + API:

app.exemplo.com {
    handle_path /api/* {
        reverse_proxy localhost:8000
    }

    handle {
        root * /var/www/app
        try_files {path} /index.html
        file_server
    }
}

Esse padrão é bem útil para React, Vue, Svelte, Angular e outros frontends de página única.

Fonte:

Padrões comuns de Caddyfile: https://caddyserver.com/docs/caddyfile/patterns
Diretivas do Caddyfile: https://caddyserver.com/docs/caddyfile/directives

11. Servir aplicações SPA, como React/Vite/Vue/Svelte

Aplicações SPA geralmente precisam que qualquer rota desconhecida caia em index.html, porque o roteamento é feito pelo navegador.

Exemplo:

app.exemplo.com {
    root * /var/www/app
    try_files {path} /index.html
    file_server
}

Com isso:

/ serve index.html;
/assets/app.js serve o arquivo real;
/dashboard cai em index.html e o frontend decide o que renderizar;
/perfil/123 também cai em index.html.

Sem esse ajuste, ao atualizar a página em /dashboard, o servidor poderia responder 404.

12. Redirecionar domínios e URLs

Caddy é ótimo para redirects simples.

Redirecionar www para domínio sem www:

www.exemplo.com {
    redir https://exemplo.com{uri} permanent
}

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

Redirecionar domínio antigo para novo:

antigo.com {
    redir https://novo.com{uri} permanent
}

Redirecionar página específica:

exemplo.com {
    redir /blog-antigo /blog/novo-artigo permanent
    root * /var/www/site
    file_server
}

Usos:

migração de domínio;
corrigir URLs antigas;
forçar domínio canônico;
criar atalhos;
aposentar projetos antigos sem quebrar links.

13. Comprimir respostas automaticamente

Caddy pode comprimir respostas com a diretiva encode.

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

Isso ajuda a reduzir tamanho de HTML, CSS, JS e JSON transferidos.

É útil para:

sites estáticos;
APIs;
documentação;
apps frontend.

Não espere milagre se seus arquivos já são imagens, vídeos, ZIPs ou PDFs comprimidos. Compressão ajuda mais em texto.

Fonte:

Lista de diretivas do Caddyfile: https://caddyserver.com/docs/caddyfile/directives

14. Adicionar headers de segurança

Você pode adicionar headers HTTP com Caddy.

Exemplo:

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

    header {
        X-Content-Type-Options nosniff
        X-Frame-Options DENY
        Referrer-Policy no-referrer-when-downgrade
    }
}

Também pode configurar cache:

static.exemplo.com {
    root * /var/www/static
    file_server

    header /assets/* Cache-Control "public, max-age=31536000, immutable"
}

Isso é útil para melhorar:

segurança básica;
cache de assets;
comportamento do navegador;
política de iframe;
entrega de arquivos estáticos.

Cuidado: headers como CSP podem quebrar site se você copiar configuração sem entender. Segurança de verdade exige testar.

15. Criar logs por site

Caddy permite configurar logs de acesso.

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

    log {
        output file /var/log/caddy/site-access.log
        format json
    }
}

Isso ajuda em:

diagnóstico;
monitoramento;
auditoria;
análise de tráfego;
descobrir 404;
saber quais endpoints estão sendo usados.

Logs em JSON são bons para integração com ferramentas como Loki, Elasticsearch, jq, scripts e pipelines de observabilidade.

16. Balancear carga entre múltiplas instâncias

Caddy consegue encaminhar tráfego para múltiplos backends.

app.exemplo.com {
    reverse_proxy localhost:3001 localhost:3002 localhost:3003
}

Isso pode ser usado para:

distribuir carga;
rodar múltiplas instâncias da mesma aplicação;
fazer deploy com menor indisponibilidade;
criar ambiente mais resiliente.

Também existem opções de health check e comportamento de falha dentro da diretiva reverse_proxy.

Exemplo conceitual:

app.exemplo.com {
    reverse_proxy localhost:3001 localhost:3002 {
        health_uri /health
        health_interval 10s
        health_timeout 2s
    }
}

Cuidado: isso não transforma automaticamente uma aplicação ruim em arquitetura robusta. Banco de dados, sessão, cache, fila e estado da aplicação precisam estar preparados.

Fonte:

Diretiva reverse_proxy: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy

17. Servir PHP com php_fastcgi

Caddy também pode servir aplicações PHP via PHP-FPM.

Exemplo:

php.exemplo.com {
    root * /var/www/phpapp/public
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

Ou usando TCP:

php.exemplo.com {
    root * /var/www/phpapp/public
    php_fastcgi localhost:9000
    file_server
}

Isso serve para:

pequenos sistemas em PHP;
Laravel;
WordPress, com cuidado;
painéis legados;
apps internos.

Opinião direta: Caddy serve PHP bem, mas se você já tem um WordPress pesado afinado em Nginx, não troque por moda. Para projeto novo ou pequeno, faz sentido testar.

Fonte:

Diretiva php_fastcgi: https://caddyserver.com/docs/caddyfile/directives/php_fastcgi

18. Criar ambiente de desenvolvimento local com HTTPS

Caddy também é útil localmente.

Exemplo:

localhost {
    reverse_proxy localhost:3000
}

Segundo a documentação do proxy reverso, se você usa localhost ou domínio terminado em .localhost, o Caddy pode usar certificado local auto-renovável e autoassinado.

Isso é útil para testar:

cookies Secure;
APIs que exigem HTTPS;
OAuth callbacks;
webhooks locais;
service workers;
PWAs;
comportamento de produção.

Fonte:

Quick-start de reverse proxy: https://caddyserver.com/docs/quick-starts/reverse-proxy

19. Criar uma página de status simples

Você pode usar Caddy para criar páginas de status manuais.

status.exemplo.com {
    respond <<HTML
    <!doctype html>
    <html lang="pt-BR">
    <meta charset="utf-8">
    <title>Status</title>
    <h1>Status dos serviços</h1>
    <ul>
      <li>Site: online</li>
      <li>API: online</li>
      <li>Bot: manutenção</li>
    </ul>
    </html>
    HTML 200
}

Isso não substitui ferramenta de monitoramento real, mas é uma forma rápida de publicar aviso.

Para algo mais profissional, use Uptime Kuma, Better Stack, Grafana ou outro serviço, e coloque o Caddy na frente.

20. Colocar Caddy na frente de ferramentas internas

Caddy é muito bom como “porteiro” para ferramentas internas:

Uptime Kuma;
Grafana;
Prometheus;
Portainer;
Adminer;
pgAdmin;
n8n;
Metabase;
Gitea;
Wiki.js;
HedgeDoc;
serviços próprios.

Exemplo:

monitor.exemplo.com {
    basic_auth {
        pablo $2a$14$HASH
    }

    reverse_proxy localhost:3001
}

Regra honesta: se o painel dá acesso administrativo de verdade, senha básica não é o bastante. Melhor restringir por VPN, IP, autenticação forte ou não expor publicamente.

21. Fazer staging e homologação sem bagunçar produção

Você pode organizar ambientes diferentes:

app.exemplo.com {
    reverse_proxy localhost:3000
}

staging.app.exemplo.com {
    basic_auth {
        pablo $2a$14$HASH
    }

    reverse_proxy localhost:3001
}

Isso permite:

testar versão nova;
mostrar para cliente;
validar integração;
manter staging com senha;
separar produção de desenvolvimento.

22. Usar DNS challenge para certificados em cenários difíceis

Quando o servidor não pode receber conexões externas nas portas 80/443, o DNS challenge pode ser útil. Ele valida o domínio criando registros TXT no DNS.

Isso serve para:

servidores atrás de CGNAT;
certificados wildcard;
ambientes internos;
servidores que não podem expor porta 80;
casos onde HTTP/TLS challenge falha.

Exemplo conceitual com Cloudflare, dependendo do plugin instalado:

*.exemplo.com {
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
    }

    reverse_proxy localhost:3000
}

Cuidado: o Caddy padrão pode não vir com todos os plugins DNS. Muitas vezes você precisa compilar uma versão customizada com xcaddy ou usar uma imagem Docker customizada.

Fonte:

HTTPS automático e DNS challenge: https://caddyserver.com/docs/automatic-https
Módulos DNS: https://caddyserver.com/docs/modules/dns

23. Criar certificados wildcard

Com DNS challenge, você pode emitir certificado wildcard:

*.exemplo.com

Isso permite cobrir:

app.exemplo.com;
api.exemplo.com;
admin.exemplo.com;
docs.exemplo.com;
qualquercoisa.exemplo.com.

Útil para homelab, multi-serviços e ambientes dinâmicos.

Mas não confunda certificado wildcard com roteamento automático. Você ainda precisa dizer ao Caddy o que fazer com cada host ou criar regras para capturar subdomínios.

24. Fazer reverse proxy para serviços HTTPS internos

Você também pode colocar o Caddy na frente de um backend HTTPS.

Exemplo:

externo.exemplo.com {
    reverse_proxy https://servico-interno.exemplo.local
}

Dependendo do backend, talvez você precise ajustar transporte, validação TLS ou cabeçalhos. A documentação recente do reverse_proxy observa mudanças e detalhes sobre upstreams HTTPS e cabeçalho Host.

Fonte:

reverse_proxy: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy

25. Criar uma mini-CDN pessoal de arquivos estáticos

Você pode usar Caddy para servir assets em um subdomínio separado:

cdn.exemplo.com {
    root * /srv/cdn
    encode zstd gzip
    file_server

    header /assets/* Cache-Control "public, max-age=31536000, immutable"
}

Usos:

imagens de site;
CSS/JS versionado;
arquivos públicos;
downloads;
documentação;
pacotes internos.

Cuidado: isso não é uma CDN global como Cloudflare, Fastly ou BunnyCDN. É apenas um servidor de arquivos bem organizado. Chamar de CDN pessoal é útil como metáfora, não como equivalência técnica.

26. Publicar documentação técnica

Caddy é ótimo para servir documentação gerada por:

MkDocs;
Docusaurus;
Hugo;
Astro;
VitePress;
mdBook;
Zola;
arquivos HTML simples.

Exemplo:

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

Fluxo:

mkdocs build
rsync -av site/ /var/www/docs/
systemctl reload caddy

Ou com deploy automatizado via Git.

27. Hospedar sites gerados por Hugo, Astro ou Eleventy

Geradores estáticos combinam muito bem com Caddy.

Exemplo com Hugo:

hugo --minify
rsync -av public/ /var/www/blog/

Caddyfile:

blog.exemplo.com {
    root * /var/www/blog
    encode zstd gzip
    file_server
}

Isso é simples, rápido e robusto. Para blog, zine, arquivo pessoal e documentação, é uma solução excelente.

28. Servir uma biblioteca digital ou arquivo pessoal

Caddy pode servir uma biblioteca de PDFs, EPUBs, imagens ou textos.

biblioteca.exemplo.com {
    root * /srv/biblioteca
    file_server browse
}

Você pode proteger com senha:

biblioteca.exemplo.com {
    basic_auth {
        pablo $2a$14$HASH
    }

    root * /srv/biblioteca
    file_server browse
}

Para acervo privado, o ideal é não expor publicamente. Use VPN ou rede local.

29. Criar endpoints úteis para automação

Você pode criar respostas simples para scripts.

hooks.exemplo.com {
    respond /ping "pong" 200
    respond /version "1.0.0" 200
}

Também pode encaminhar webhooks:

hooks.exemplo.com {
    reverse_proxy localhost:9001
}

Usos:

webhooks do GitHub;
notificações;
bots;
automações com n8n;
endpoints de status;
callbacks de OAuth.

30. Fazer blue-green deployment simples

Você pode alternar entre duas versões da aplicação mudando o backend.

app.exemplo.com {
    reverse_proxy localhost:3001
}

Versão nova em 3002:

app.exemplo.com {
    reverse_proxy localhost:3002
}

Depois:

caddy reload --config /etc/caddy/Caddyfile

Isso é simples, mas manual. Para deploy sério, use estratégia mais controlada com health checks, filas, rollback e observabilidade.

31. Servir APIs com headers e limites básicos

Exemplo:

api.exemplo.com {
    reverse_proxy localhost:8000

    header {
        X-Content-Type-Options nosniff
        Referrer-Policy no-referrer
    }
}

O Caddy pode ficar na frente de APIs e centralizar:

HTTPS;
logs;
headers;
compressão;
roteamento;
proxy para múltiplos serviços.

Limitação: Caddy puro não é um API gateway completo como Kong, Traefik Enterprise, NGINX Plus ou Envoy com configuração avançada. Ele resolve muito, mas não tudo.

32. Usar como servidor web minimalista para projetos pessoais

Caddy é excelente para publicar pequenos projetos sem transformar cada deploy em uma novela.

Exemplo:

projeto1.exemplo.com {
    reverse_proxy localhost:4001
}

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

projeto3.exemplo.com {
    reverse_proxy localhost:4003
}

Esse é o tipo de setup onde Caddy brilha: muitos projetos pequenos, pouca paciência para configuração repetitiva.

33. Usar Caddy como frontend de uma VPS

Uma arquitetura comum:

Internet
   ↓
Caddy na VPS
   ↓
apps locais / containers / serviços internos

Caddy recebe tudo em 80/443 e distribui para os serviços.

Exemplo:

app.exemplo.com {
    reverse_proxy 127.0.0.1:3000
}

api.exemplo.com {
    reverse_proxy 127.0.0.1:8000
}

Isso é provavelmente o uso mais comum e mais seguro para produção pequena/média.

34. Usar VPS + túnel para servidor local

Se você quer hospedar coisas de casa, mas está em CGNAT, uma arquitetura mais séria é:

Internet
   ↓
VPS pública com Caddy
   ↓
WireGuard ou Tailscale
   ↓
Servidor local

Caddy na VPS:

homeapp.exemplo.com {
    reverse_proxy 100.64.0.10:3000
}

Aqui 100.64.0.10 seria o IP interno da VPN/Tailscale/WireGuard.

Isso é mais robusto do que depender de portas abertas no roteador. Mas exige mais disciplina de rede e segurança.

35. Criar um portal de homelab

Você pode ter:

home.exemplo.com {
    root * /srv/homepage
    file_server
}

uptime.exemplo.com {
    reverse_proxy localhost:3001
}

files.exemplo.com {
    root * /srv/files
    file_server browse
}

notes.exemplo.com {
    reverse_proxy localhost:8082
}

Com isso, seu homelab fica organizado por subdomínios.

Recomendação séria: para serviços pessoais, prefira acesso via VPN. Expor painel de homelab diretamente na internet é uma forma eficiente de arrumar dor de cabeça.

36. Criar páginas temporárias para projetos

Caddy permite colocar placeholder rapidamente:

novo-projeto.exemplo.com {
    respond "Projeto em construção. Volte depois."
}

Ou redirecionar enquanto o projeto não está pronto:

novo-projeto.exemplo.com {
    redir https://exemplo.com
}

Bom para reservar domínio/subdomínio antes de publicar app real.

37. Usar templates do Caddy

Caddy tem suporte a templates, permitindo renderizar alguns conteúdos dinamicamente.

Exemplo conceitual:

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

Isso não substitui um framework web, mas pode ser útil para sites simples com includes, variáveis e páginas geradas de forma leve.

38. Usar Caddy com JSON config e API administrativa

O Caddyfile é a forma mais amigável para humanos, mas o Caddy internamente usa JSON. A documentação explica que o Caddyfile é um adaptador de configuração, mais simples para escrita manual, enquanto o JSON nativo é mais expressivo e programável.

Isso abre portas para:

automação;
geração dinâmica de configuração;
integração com painel próprio;
deploy programático;
controle via API administrativa.

Opinião direta: para uso comum, fique no Caddyfile. Use JSON/API só se você realmente precisa automatizar configuração em escala. Caso contrário, é complexidade gratuita.

Fonte:

Caddyfile: https://caddyserver.com/docs/caddyfile

39. Criar uma camada simples de organização para microserviços

Caddy pode organizar microserviços pequenos:

api.exemplo.com {
    handle_path /users/* {
        reverse_proxy users:8000
    }

    handle_path /orders/* {
        reverse_proxy orders:8000
    }

    handle_path /billing/* {
        reverse_proxy billing:8000
    }
}

Isso pode servir em ambiente pequeno. Em escala grande, talvez você queira algo mais especializado como API gateway, service mesh ou ingress controller.

40. Usar em conjunto com Cloudflare

Você pode usar Cloudflare na frente e Caddy atrás.

Arquitetura:

Usuário
   ↓
Cloudflare
   ↓
Caddy na VPS
   ↓
Aplicação

Vantagens:

DNS fácil;
cache/CDN opcional;
proteção básica;
túnel, se usar Cloudflare Tunnel;
Caddy continua cuidando do roteamento interno.

Cuidado: não misture camadas sem entender. Se Cloudflare termina TLS e Caddy também serve HTTPS, saiba exatamente onde cada certificado e cada redirect está acontecendo. Configuração confusa gera loop de redirect e erros difíceis de diagnosticar.

41. Usar Caddy como alternativa mais simples ao Nginx

Caddy pode substituir Nginx em muitos cenários:

sites estáticos;
reverse proxy;
HTTPS automático;
apps pequenos e médios;
homelab;
VPS com vários serviços;
documentação;
painéis internos.

Mas não é sempre superior.

Nginx ainda pode ser melhor quando você precisa de:

tunagem fina de performance;
ecossistema já maduro na empresa;
configurações legadas;
módulos específicos;
comportamento altamente previsível em alto tráfego;
mirrors públicos pesados;
cache avançado muito customizado.

Resumo brutal:

Para projetos novos e pequenos/médios: Caddy é excelente.
Para infraestrutura enorme já afinada: não troque só porque é bonito.
Para mirror público ou tráfego massivo: teste com cuidado antes de mexer.

42. Exemplos de Caddyfile úteis

Site estático

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

Site estático com compressão

exemplo.com {
    root * /var/www/exemplo
    encode zstd gzip
    file_server
}

Proxy reverso para app Node

app.exemplo.com {
    reverse_proxy localhost:3000
}

API Python

api.exemplo.com {
    reverse_proxy localhost:8000
}

SPA

spa.exemplo.com {
    root * /var/www/spa
    try_files {path} /index.html
    file_server
}

Painel protegido

admin.exemplo.com {
    basic_auth {
        pablo $2a$14$HASH
    }

    reverse_proxy localhost:8080
}

Redirecionar domínio

antigo.com {
    redir https://novo.com{uri} permanent
}

Arquivos com listagem

files.exemplo.com {
    root * /srv/files
    file_server browse
}

PHP-FPM

php.exemplo.com {
    root * /var/www/php/public
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

43. Coisas legais para fazer com Caddy: lista rápida

Publicar um site estático em minutos.
Criar uma landing page sem framework.
Servir uma pasta de arquivos com file_server browse.
Colocar HTTPS automático em apps locais na VPS.
Usar subdomínios para organizar projetos.
Criar proxy reverso para Node, Python, Go, Rust ou PHP.
Proteger dashboards com senha.
Criar ambiente de staging com autenticação.
Servir documentação técnica.
Publicar blog estático com Hugo/Astro/Eleventy.
Criar mini biblioteca digital privada.
Expor Uptime Kuma, Grafana ou Portainer com cuidado.
Fazer redirects permanentes.
Criar endpoints simples com respond.
Centralizar logs de acesso.
Comprimir respostas com gzip/zstd.
Adicionar headers de segurança.
Rodar em Docker Compose.
Criar frontend para microserviços pequenos.
Balancear carga entre instâncias.
Usar DNS challenge para certificados wildcard.
Rodar localmente com HTTPS para desenvolvimento.
Colocar Caddy atrás da Cloudflare.
Colocar Caddy na frente de serviços de homelab.
Usar VPS como ponte para servidor local em CGNAT.

44. Pontos fortes do Caddy

Simplicidade

A configuração é limpa. O Caddyfile é fácil de ler e escrever.

HTTPS automático

Esse é o grande diferencial. Menos Certbot, menos script, menos renovação manual.

Ótimo para proxy reverso

Você consegue expor vários apps com poucos blocos.

Bom para Docker

A imagem oficial é simples de usar e encaixa bem em Compose.

Excelente para homelab e VPS pessoal

Para quem mantém muitos serviços pequenos, Caddy reduz atrito.

Configuração declarativa

Você descreve o que quer: domínio, pasta ou backend. O Caddy cuida de bastante coisa.

45. Pontos fracos e riscos

Menos onipresente que Nginx

Nginx ainda é mais comum em ambientes corporativos e materiais legados.

Menos exemplos para casos muito específicos

Para algo muito fora do padrão, você pode achar mais material de Nginx.

Plugins podem exigir build customizado

DNS challenge com provider específico pode exigir Caddy customizado.

Abstração pode esconder detalhes

HTTPS automático é ótimo, mas quando quebra você precisa entender ACME, DNS, portas e certificados.

Não fura CGNAT sozinho

Caddy não resolve conectividade pública sem túnel, VPS, IPv6 ou IP público.

Não substitui segurança séria

Basic auth não é controle de acesso completo. Expor painel administrativo na internet continua sendo arriscado.

Não é sempre a melhor escolha para tráfego pesado

Para mirrors, cache avançado ou infraestrutura muito tunada, Nginx/Apache/HAProxy podem continuar fazendo mais sentido.

46. Quando eu usaria Caddy

Eu usaria Caddy para:

VPS pessoal;
projetos pequenos e médios;
APIs próprias;
sites estáticos;
dashboards internos;
documentação;
homelab;
testes rápidos;
staging;
apps Docker;
ambientes com muitos subdomínios.

47. Quando eu não usaria Caddy como primeira escolha

Eu pensaria duas vezes em usar Caddy para:

mirror público de alto tráfego;
infraestrutura já muito afinada em Nginx;
cenário que exige módulo específico de Nginx;
cache reverso altamente customizado;
ambiente corporativo onde a equipe só domina Nginx/Apache;
sistemas críticos sem tempo para validar comportamento em carga.

Não porque Caddy seja ruim, mas porque trocar peça de infraestrutura por gosto pessoal é burrice operacional. Ferramenta boa é ferramenta adequada ao cenário.

48. Caminho recomendado para aprender

Um caminho prático:

Instale Caddy em uma VPS ou máquina local.
Crie um site estático simples.
Coloque um domínio apontando para ele.
Teste HTTPS automático.
Faça proxy reverso para uma aplicação local.
Adicione compressão com encode.
Adicione logs.
Proteja um painel com basic_auth.
Teste Docker Compose.
Só depois mexa com DNS challenge, wildcard e automações avançadas.

Não comece pelo caso mais complicado. Isso é pedir para se frustrar.

49. Conclusão

Caddy é uma ferramenta excelente para quem quer hospedar sites e aplicações com menos burocracia. Ele brilha em três coisas: HTTPS automático, proxy reverso simples e configuração legível.

O grande valor do Caddy não é fazer algo impossível. Nginx e Apache também fazem muita coisa. O valor é fazer o comum ficar menos chato.

Para um servidor pessoal, VPS com vários projetos, homelab, documentação, apps em Docker e sites estáticos, Caddy é uma escolha muito forte.

Mas ele não é uma varinha mágica. Não resolve CGNAT sozinho, não substitui uma arquitetura de segurança decente, não transforma painel exposto em algo seguro e não é automaticamente melhor que Nginx em todos os cenários.

A conclusão honesta é:

Use Caddy onde ele reduz complexidade real. Não use só porque parece moderno.

Para a maioria dos projetos pequenos e médios, essa redução de complexidade é enorme.

50. Referências

Caddy Documentation: https://caddyserver.com/docs/
Caddyfile: https://caddyserver.com/docs/caddyfile
Caddyfile Directives: https://caddyserver.com/docs/caddyfile/directives
Common Caddyfile Patterns: https://caddyserver.com/docs/caddyfile/patterns
Automatic HTTPS: https://caddyserver.com/docs/automatic-https
Reverse Proxy Quick-start: https://caddyserver.com/docs/quick-starts/reverse-proxy
reverse_proxy: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy
basic_auth: https://caddyserver.com/docs/caddyfile/directives/basic_auth
php_fastcgi: https://caddyserver.com/docs/caddyfile/directives/php_fastcgi
DNS modules: https://caddyserver.com/docs/modules/dns
Caddy Docker image: https://hub.docker.com/_/caddy/

Related documents