Estático Primero
El site público de Chinaski es HTML estático simple servido desde el disco, y la base de datos solo se toca mientras autoras contenido. Esta página explica por qué está construido así y qué significa para tu trabajo diario.
Cómo se entrega tu site realmente
Chinaski corre como dos piezas que cooperan:
- El CMS, una aplicación de administración privada donde escribes y organizas el contenido. Lo guarda todo en una base de datos integrada y trae la interfaz de administración del site.
- El builder, un proceso separado que lee esa base de datos, renderiza tus páginas a través de plantillas y escribe archivos HTML estáticos simples al disco.
Tu servidor web sirve esos archivos estáticos directamente. La aplicación del CMS nunca está en la ruta de peticiones públicas. En el despliegue de fábrica los hosts públicos son servidores de archivos estáticos, y la configuración del servidor respalda esta arquitectura, sirve el directorio de salida generado desde el disco, con una excepción estrecha descrita abajo.
Por qué es estático, no dinámico
Porque el site publicado son solo archivos:
- Ningún tracker puede colarse. Nada se ejecuta en el site público por defecto, y no existe ningún mecanismo que pudiera inyectar un beacon en tus páginas.
- La superficie de ataque permanece pequeña. La aplicación de admin corre enlazada a una dirección loopback (solo localhost), no a una interfaz pública.
- Nada que filtrar. La base de datos, contenido, cuentas, drafts, vive del lado de la autoría y no está expuesta a peticiones públicas.
Los builds son explícitos
Guardar o publicar contenido no reconstruye el site automáticamente. Un build se dispara cuando lo inicias desde el dashboard del admin, mediante un webhook configurado o ejecutando el builder tú mismo. Los builds son operaciones deliberadas con un log visible, no efectos secundarios en segundo plano. Cada build queda registrado para que puedas revisar exactamente qué se escribió.
Solo un build corre a la vez; un segundo disparador reporta que el build ya está en curso en lugar de competir. Los builds son incrementales por defecto, con un rebuild completo disponible cuando se necesita.
El site nunca cae a mitad de una actualización
La escritura de la salida es deliberadamente defensiva:
- Los archivos se escriben atómicamente: el contenido nuevo se prepara en staging y se renombra a su lugar, así que el servidor público nunca sirve un archivo a medio escribir.
- Si el build falla o expira, el site construido anteriormente sigue en vivo, intacto y sin tocar.
- Antes de que un build nuevo pase a producción, el builder lo compara con el último build bueno. Si algo salió mal, una caída repentina en el conteo de páginas, un pico contado de enlaces rotos, el builder se niega a promoverlo y el site anterior sigue sirviendo. Una salida obsoleta es el peor caso, no una salida rota.
- Los builds tienen un tope de presupuesto de escritura de 2 GiB, con limpieza automática para que un desbordamiento aborte el build en lugar de llenar el disco.
La única excepción: formularios
Como el site público es estático, los envíos de formularios no pueden ser manejados por el servidor de archivos. Esto afecta a los formularios en los blocks de contacto y newsletter: los envíos hacen POST a /forms/<the form's address>, que el servidor web proxifica a la aplicación del CMS. La configuración del despliegue de fábrica incluye este proxy; quitarlo solo es seguro si el site no tiene formularios.
Las páginas protegidas con contraseña también son estáticas: el contenido protegido viaja dentro del archivo HTML y se desbloquea en el navegador del visitante mediante una verificación de contraseña. Eso significa que el contenido está técnicamente presente en la página incluso con la barrera cerrada, un visitante que lea el HTML crudo puede extraerlo.