🔒 Domínio, HTTPS, reverse proxy

HTTPS começa no DNS. Sem o domínio resolvendo para o IP da VPS, o Caddy não consegue completar o desafio ACME HTTP-01 do Let's Encrypt e o cadeado nunca aparece. O registro essencial é o A record (IPv4); se a VPS tem IPv6, adicione também um AAAA.

O TTL (time-to-live) controla quanto tempo resolvers fazem cache da resposta. Em mudança de IP, baixe para 300 antes; em produção estável, 3600 ou mais. A propagação global leva de minutos a algumas horas — depende do provider e do TTL anterior.

# Registros no painel do provider (Cloudflare, Registro.br, etc.)
# Tipo  Nome              Valor              TTL
# A     postiz.exemplo    203.0.113.42       300
# AAAA  postiz.exemplo    2001:db8::1        300
# A     api.postiz.exemplo 203.0.113.42       300
# A     app.postiz.exemplo 203.0.113.42       300

# Confirmar resolução (IPv4)
dig +short postiz.exemplo.com A
# 203.0.113.42

# IPv6
dig +short postiz.exemplo.com AAAA
# 2001:db8::1

# Resolver específico para ver propagação em outro DNS
dig @1.1.1.1 postiz.exemplo.com +short
dig @8.8.8.8 postiz.exemplo.com +short

Conceitos-chave

Três caminhos para o mesmo objetivo: terminar TLS na borda e fazer reverse proxy para os containers. A escolha depende de quanto automatismo você quer e quão familiar é com cada ecossistema.

Para o Postiz em uma VPS, Caddy é a escolha óbvia: emite e renova certificado sozinho, suporta HTTP/2 e HTTP/3 sem flags, e o arquivo de config cabe em 10 linhas.

# Comparativo rápido (linhas de config para o caso "1 domínio → 1 backend")
# Caddy        ~3 linhas
# Traefik      ~25 linhas (labels) + traefik.yml estático
# nginx-proxy  ~20 linhas + Dockerfile de acme-companion

# Footprint de memória (idle, médio)
# Caddy        ~30 MB
# Traefik      ~50 MB
# nginx        ~10 MB (sem acme-companion)

Conceitos-chave

O Caddy adiciona à stack como mais um serviço no docker-compose.yml. Ele assume as portas 80 e 443 do host, e fala com o Postiz pela network interna — sem expor 5000 publicamente.

# ~/postiz/Caddyfile
postiz.exemplo.com {
    reverse_proxy postiz:5000
    encode gzip zstd
}

Três linhas. O Caddy faz o resto: ACME challenge, certificado, redirect 80→443, HTTP/2, HTTP/3. Adicione o serviço ao compose e remova o ports: ["5000:5000"] do Postiz — ele não precisa mais ser acessível direto.

# ~/postiz/docker-compose.yml (recorte do serviço caddy)
  caddy:
    image: caddy:2-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"   # HTTP/3 (QUIC)
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data         # certificados (NÃO PERDER!)
      - caddy-config:/config
    networks: [postiz-net]
    depends_on:
      - postiz

volumes:
  caddy-data:
  caddy-config:

Conceitos-chave

Frontend e backend em subdomínios separados dá clareza operacional: app.exemplo.com serve a UI, api.exemplo.com a API. Cada subdomínio é um bloco no Caddyfile com seu próprio certificado.

# ~/postiz/Caddyfile com subdomínios
app.exemplo.com {
    reverse_proxy postiz:5000
    encode gzip zstd
}

api.exemplo.com {
    reverse_proxy postiz:3000
    encode gzip zstd

    # CORS para o frontend
    header {
        Access-Control-Allow-Origin "https://app.exemplo.com"
        Access-Control-Allow-Credentials "true"
    }
}

# Redirect raiz → app
exemplo.com {
    redir https://app.exemplo.com{uri} permanent
}

Ajuste as variáveis do Postiz para refletir os subdomínios — FRONTEND_URL=https://app.exemplo.com, NEXT_PUBLIC_BACKEND_URL=https://api.exemplo.com. Sem isso o frontend tenta chamar localhost e quebra no browser do usuário.

Conceitos-chave

Certificado é só metade do trabalho. Sem headers de segurança, o browser ainda permite ataques que TLS sozinho não cobre: downgrade para HTTP, clickjacking, sniffing de MIME, XSS via scripts injetados.

# ~/postiz/Caddyfile com headers de segurança
app.exemplo.com {
    reverse_proxy postiz:5000
    encode gzip zstd

    header {
        # HTTPS obrigatório por 1 ano, incluindo subdomínios
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

        # Anti-clickjacking
        X-Frame-Options "DENY"

        # Anti-MIME-sniffing
        X-Content-Type-Options "nosniff"

        # Referrer só para mesma origem
        Referrer-Policy "strict-origin-when-cross-origin"

        # CSP básico — ajuste conforme assets externos do app
        Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self'"

        # Remove header que vaza versão do servidor
        -Server
    }
}

Conceitos-chave

Certificado do Let's Encrypt dura 90 dias. O Caddy renova automaticamente quando faltam ~30 dias — sem cron, sem script, sem intervenção. O que pode dar errado é o desafio ACME falhar em silêncio; o jeito de saber é olhar os logs.

# Acompanhar logs do Caddy (boot + renovações)
docker compose logs -f caddy

# Procurar especificamente eventos de certificado
docker compose logs caddy | grep -iE "certificate|acme|renew"

# Inspecionar certificado emitido (data de expiração)
echo | openssl s_client -servername app.exemplo.com -connect app.exemplo.com:443 2>/dev/null \
  | openssl x509 -noout -dates -issuer

# Forçar reload do Caddyfile sem reiniciar (zero downtime)
docker exec caddy caddy reload --config /etc/caddy/Caddyfile

# Caso renovação falhe: limpar e tentar de novo (cuidado com rate limit!)
docker compose restart caddy

Conceitos-chave