Configuración

Chinaski se configura en dos capas: un puñado de variables de entorno establecidas por instancia (los controles a nivel de despliegue) y el área de Settings dentro de la interfaz de administración (configuración a nivel de site, guardada en la base de datos). Esta página explica las seis variables de entorno principales y a dónde pertenece cada otra personalización.

Las seis variables de entorno principales

Por instancia, viven en un archivo de entorno con permisos restringidos (/etc/chinaski<instance>/env, creado en la instalación). Los despliegues offline/hypnotoad las exportan directamente.

Variable	Qué hace	Qué conviene saber
`CHINASKI_SECRET`	Firma las sesiones de admin y da clave al cifrado de credenciales almacenadas	Requerida. El servidor se niega a arrancar sin ella. Generada automáticamente en la instalación, impresa una vez, guardada en el archivo de entorno. Única por instancia; nunca la cambies a la ligera (ver Secrets)
`CHINASKI_DB`	Dónde vive el archivo de la base de datos SQLite	Normalmente derivada automáticamente del nombre de la instancia por la unidad systemd, déjala sin definir
`CHINASKI_OUTPUT`	Dónde se escriben los builds estáticos	Lo mismo: derivada por instancia por la unidad
`LISTEN_URL`	La dirección donde se enlaza el servidor	Enlaza a loopback (patrón `http://127.0.0.1:3001`): el proxy da a internet, el CMS no. Enlazar a una interfaz pública anula la protección contra suplantación de IP del servidor para rate limiting y bloqueos
`CHINASKI_WORKERS`	Número de workers del servidor	Por defecto 2. Súbelo a 4 en hosts de 2+ GB con varios editores concurrentes
`MOJO_MODE`	Modo de ejecución	Los despliegues en producción establecen `production` (la unidad systemd lo hace por ti)

Nota sobre las dos variables de escucha: CHINASKI_LISTEN es el valor que lee directamente el servidor integrado (offline/hypnotoad), por defecto http://127.0.0.1:8080. LISTEN_URL es lo que la unidad systemd pasa al daemon en producción. En un despliegue estándar de producción, establece LISTEN_URL; en modo offline, establece CHINASKI_LISTEN (o déjalo en la configuración del hypnotoad incluido).

Los ajustes que cambias desde la UI de administración

Todo lo demás sobre cómo se comporta el site es Settings, guardado en la base de datos (sobrevive a los rebuilds, se incluye en los backups):

Identidad del site: nombre, eslogan, logo, conjunto de favicon, lista de idiomas, modo de URL
Campos SEO, valores por defecto del sitemap, redirecciones, prefijos de permalinks
Correo (SMTP), textos de seguridad/cookies, claves de verificación de bots
Webhooks de build, autorregistro, caducidad de contraseñas, programación/retención de backups
Design tokens, opciones de PWA, Google Analytics/GTM, etcétera

Si lo que vas a cambiar tiene una pantalla en Settings, cámbialo ahí: las variables de entorno son a nivel de despliegue, no a nivel de site.

Variables de entorno más allá de las seis principales

CHINASKI_AIRGAP=1: hace que la instalación demuestre que nunca llama hacia afuera: webhooks de build y de formularios apagados, verificación de bots apagada, widget de verificación oculto. Establécela antes de arrancar en hosts aislados.
CHINASKI_TRUSTED_PROXIES: IPs o rangos IPv4 separados por comas autorizados a reenviar las IPs de los visitantes (solo hace falta si tu proxy no llega al CMS desde loopback, como en setups tipo Docker).
CHINASKI_ALLOW_BUILD_FAIL=1: se usa antes del script de deploy para enviar una corrección de emergencia solo de código incluso cuando un build está fallando.
Existen otras pocas en el código para verificación de actualizaciones, rutas de docs personalizadas y claves de release; se reconocen pero no están cubiertas como ajustes documentados en este release; trata como interno todo lo que no aparezca aquí.

Dónde surten efecto los cambios

Los cambios en el archivo de entorno requieren un reinicio (systemctl restart chinaski@<instance>); se leen una sola vez al arrancar.
Los cambios en Settings surten efecto de inmediato para el CMS, y llegan al site publicado en el siguiente build.
El secreto maestro afecta tanto a los inicios de sesión (todas las sesiones existentes mueren al rotarlo) como a las credenciales almacenadas: vuelve a guardar la credencial de cada integración después de una rotación (ver Secrets).

La versión corta

Seis variables de entorno manejan el proceso (SECRET requerida; DB/OUTPUT auto-derivadas; LISTEN_URL solo loopback; MODE; WORKERS); todo lo demás que un dueño de site quiera vive en Settings, y cualquier cosa para la que te veas buscando una variable de entorno más allá de estas seis es o bien un flag de operador de la página CLI/Server o algo que el sitio de documentación cubre donde corresponde (airgap, proxies, scripts de deploy).