Hospedagem estática

Um site Chinaski construído é uma árvore simples de HTML/CSS/imagens preparada para servimento estático; o deployment típico, novamente, é um reverse proxy ou um host estático lendo essa saída. Esta página cobre o servimento com nginx ou Caddy, como funcionam os arquivos de redirecionamento (hospedagem estilo Netlify) e quais rotas um site “estático” ainda precisa encaminhar ao CMS.

A saída construída

Um diretório por idioma (ou uma raiz única para sites monolíngues):

index.html por diretório, com semântica de try-files traduzindo URLs em caminhos.
_redirects: as regras de redirecionamento estilo Netlify que o builder gera a cada build (redirecionamentos de slug com seus códigos de status configurados).
_redirects.caddy: um arquivo complementar com os mesmos redirecionamentos na sintaxe nativa do Caddy, pronto para incluir em um Caddyfile.
Arquivos de PWA (sw.js, manifest, página offline) com suas próprias diretivas de cache.
Imposição completa de domínio canônico: um bloco gerado no _redirects que aplica 301 ao host alternativo www/nu para o que corresponde à sua URL de Site (veja a página de domínio canônico para a sintaxe exata).

As rotas que um site estático ainda precisa encaminhar

Duas famílias de URL não podem ser servidas estaticamente e precisam de reverse proxy para o daemon do CMS:

/forms/*: páginas públicas de formulários e os POSTs de submissão. Sem encaminhamento, cada envio de formulário retorna 404.
/documents/*: downloads de documentos (contagem de downloads, bloqueio por estado de publicação). Sem encaminhamento, cada URL de documento dá 404.

Ambos os exemplos embarcados fazem exatamente isso

O repositório traz vhosts prontos para copiar e editar:

nginx (deploy/chinaski.nginx.example e seu irmão mais completo -conf.example): serve por document root, encaminha /forms/ e /documents/ para 127.0.0.1:<porta do CMS>, define long-cache para fontes/assets, no-cache para o service worker, short-cache no HTML, além dos headers de segurança de nível de app como cinto-e-suspensório. TLS: rode o certbot contra o vhost habilitado.
Caddy (deploy/chinaski.Caddyfile.example): um bloco por instância, proxy da porta do CMS no loopback, define X-Forwarded-For/Proto/Host explicitamente, adiciona políticas de cache espelhando as do nginx e roteia caminhos de honeypot de scanner (/.env, /.git/config, sondagens wp-login…) ao CMS para que sejam registrados e retidos (tarpit) em vez de respondidos pelo servidor web.

O proxy pelo loopback é deliberado: proxies conectando a partir de 127.0.0.1 são confiáveis por padrão, então nenhuma CHINASKI_TRUSTED_PROXIES extra é necessária. Se o seu proxy está a um salto de rede de contêiner de distância, adicione essa rede à CHINASKI_TRUSTED_PROXIES.

A sincronização da root do nginx no deploy.sh

A cada deploy o script sincroniza a document root do nginx com o modo de idioma atual: para output/ em sites monolíngues ou output/<idioma padrão> caso contrário, editando apenas configs que referenciam essa instalação. Ele roda nginx -t antes do reload e avisa, saindo em segurança, se o teste de configuração falha.

Os arquivos de redirecionamento

O builder emite três arquivos gerados na raiz da saída relativos a redirecionamentos. Veja a página de formatos de redirecionamento para o detalhamento arquivo por arquivo, incluindo a linha específica do Caddy para domínio canônico.

Hospedagem estilo Netlify

O builder escreve regras de redirecionamento no formato _redirects do Netlify (linhas simples slug-antigo → slug-novo com o código de status escolhido por você). Duas coisas para saber antes de apontar o Netlify para a saída:

Redirecionamentos com padrão (curingas * com placeholders de captura) são deliberadamente não escritos no _redirects; o formato simples de arquivo não pode expressá-los com segurança; eles vivem na configuração do seu proxy.
O bloco gerado de domínio canônico usa a sintaxe de força 301! do Caddy no mesmo arquivo. Um parser estrito de _redirects do Netlify rejeitará essa linha; confira/edite-a antes de enviar o arquivo a um host não-Caddy, ou sobrescreva-a.

Nota de cinto-e-suspensório: os headers de segurança definidos pelo app do CMS também estão presentes nos vhosts de exemplo, porque um proxy pode servir respostas em cache antes que o app tenha chance de responder.

Nesta seção

Também em Hospedagem estática

Hospedagem Estática com Caddy

Sirva a árvore estática gerada com Caddy e TLS automático: o que o exemplo de Caddyfile incluído configura e o que editar em cada instância.

Hospedagem Estática com nginx

Sirva a árvore estática com nginx: os dois vhosts de exemplo, o proxy de /forms/ e /documents/ para o daemon do CMS e a sincronização da raiz.

Formatos de Arquivo de Redirecionamentos

Os arquivos de redirecionamento que cada build grava na raiz da saída, seus formatos para Netlify e Caddy, e a linha que só funciona no Caddy.