Static Hosting con nginx

nginx sirve el árbol estático construido y reenvía dos familias de URL al daemon del CMS. El repositorio trae dos vhosts de ejemplo; esta página cubre ambos y la sincronización de root en el deploy.

Los dos archivos de ejemplo

deploy/chinaski.nginx.example: el vhost estático mínimo: document root, bloques de proxy /forms/ y /documents/, políticas de caché y cabeceras de seguridad.
deploy/chinaski.nginx.conf.example: el ejemplo por instancia más completo (puerto 80 por defecto; añade TLS vía certbot --nginx -d YOUR_DOMAIN después de habilitar el vhost).
Crea un symlink dentro de sites-enabled/, corre nginx -t, luego recarga (systemctl reload nginx) tras la configuración.

La document root

Apunta root a la salida construida:

/var/www/chinaski<N>/output/<lang>: para multilingüe por ruta (vhosts individuales por idioma; p. ej. uno por site de idioma).
/var/www/chinaski<N>/output: para sites monolingües (el modo de URL none).

El script de deploy te autocorrige el root de nginx: en cada deploy, deploy.sh reescribe la directiva root en cualquier configuración de nginx que referencie ese directorio de instalación para que coincida con el modo de idioma actual (solo output para none; si no, output/<default language>), corre nginx -t, y recarga. Con una advertencia si la prueba de configuración falla para que sepas que debes revisar manualmente.

Bloques de proxy que necesitas

location ^~ /forms/ hace proxy a http://127.0.0.1:CMS_PORT: requerido cuando cualquier formulario del site publica submissions (o renderiza cualquier formulario). Sin él: "cada envío de formulario devuelve 404".
location ^~ /documents/: requerido cuando el site usa la característica documents; el seguimiento de descargas y el estado de publicación de los documents no pueden incrustarse en un build estático.

Las demás rutas estáticas no necesitan nada más allá de try_files $uri $uri/index.html =404 (más directivas de caché por asset y cabeceras de seguridad).

Cabeceras de caché que establecen los ejemplos

HTML: máximo corto (revalidar a los 5 minutos), para que el contenido publicado sea oportuno.
Service worker: no-cache (sw.js).
Fuentes: inmutables 1 año.
Otros assets: 1 día.
Cabeceras de seguridad: como cinturón y tirantes: la app también las establece; el proxy añade una capa para respuestas antes de que la app tenga la oportunidad.

Proxy por loopback (y por qué no requiere configuración extra)

Los ejemplos hacen proxy desde 127.0.0.1: loopback, confiado por defecto en la app. Si tu entorno real hace proxy al CMS desde una dirección que no es loopback (un bridge de contenedores, por ejemplo), añade esa red a CHINASKI_TRUSTED_PROXIES para que las IPs reales de los clientes se registren y el rate limiting funcione por visitante.