Despliegue SSH / rsync

Chinaski puede empujar su site estático recién construido a un host remoto después de cada build exitoso, por SSH, usando rsync. Configuras un destino, y cada build termina con la salida espejada en ese host. Esta página cubre la configuración, las barandillas de seguridad y el comportamiento ante fallos.

Configuración

Bajo Settings → Deploy, dos interruptores deciden si un deploy se dispara automáticamente:

Deploy automatically after a successful build es el interruptor maestro. Apagado por defecto; tanto el deploy rsync como el deploy S3 permanecen inactivos hasta que esto esté activado, aunque sus propias configuraciones de abajo estén completamente listas.
Enable SSH/rsync deploy (también apagado por defecto) activa este destino concreto una vez que el interruptor maestro está activado.

Luego llena:

Host: un hostname como web01.example.com (solo letras, dígitos, puntos y guiones).
User: la cuenta SSH (opcional; omítelo para usar la cuenta ya conocida por tu configuración ssh local).
Remote path: el directorio de destino, solo absoluto (/var/www/site, sin espacios).
SSH key path: la clave privada en el host del CMS usada para autenticar (opcional, tu configuración ssh puede que ya tome una; si se define, también debe ser una ruta absoluta sin espacios).

Tras configurar ambos interruptores, guarda; los deploys ocurren automáticamente en el siguiente build exitoso. Si tus configuraciones fallan la validación (un espacio en la ruta, una ruta de clave relativa, metacaracteres de shell en cualquier parte), el deploy simplemente se omite en lugar de ejecutarse a medias.

Qué ocurre realmente

Después de que un build promociona su salida, el CMS lanza un rsync en segundo plano del directorio de salida live hacia el destino:

La forma del comando es rsync -az --delete sobre SSH: modo archive, compresión y espejado exacto (los archivos obsoletos se eliminan en el destino).
SSH se conecta de forma no interactiva (BatchMode): solo autenticación por clave, sin prompt de contraseña. Configura el host de destino para autenticación por clave por fuera.
Las primeras conexiones auto-aceptan el fingerprint del host remoto (accept-new); las conexiones subsecuentes verifican contra la clave recordada.
Corre en segundo plano: un deploy no retrasa la contabilidad del build, y el éxito del build es independiente del del deploy.

En modo air-gap todo esto está deshabilitado. El deploy nunca corre sin importar la configuración.

Validaciones integradas

Las configuraciones de deploy están protegidas antes de la ejecución:

Host y usuario: sin metacaracteres de shell (; | & \ $ comillas etc.), solo caracteres plausibles de hostname.
Remote path y key path: ambos deben empezar con /, no deben incluir metacaracteres de shell ni espacios.
Cualquier cosa que falle la validación significa que el deploy silenciosamente no corre a ningún lado, con una línea en el log; el site en sí igualmente se construyó y se sirve localmente.

Estado en el admin

Mientras un deploy corre, el admin muestra un banner de estado en vivo (que consulta cada pocos segundos) que avanza de “Building your update…” a “Build complete. Publishing your update…” y de ahí a “Your update is live.”, o muestra un estado de error si el build o el deploy fallaron. El banner se guía por el estado real del deploy, no por un temporizador, así que sigue mostrando “publishing” durante todo el tiempo que una sincronización siga corriendo de verdad, incluida una subida lenta por una mala conexión. No desaparece antes de tiempo solo porque un deploy tarde un poco.

Fallos y qué revisar

Los resultados del despliegue aparecen en el journal (journalctl -u chinaski@<N>):

rsync deploy failed (rc=N): …: la línea con la razón exacta; las causas comunes son host inalcanzable, fallo de autenticación (clave no autorizada en el destino), o remote path faltante/incorrecto.
rsync deploy complete -> user@host:/path: el éxito limpio.

Un deploy que falla nunca afecta el contenido del site en el host del CMS. La salida anterior sigue sirviéndose; reintenta disparando un rebuild o arreglando el acceso SSH y reconstruyendo.

La hermana: deploy S3

Un segundo canal de salida usa el mismo pipeline de build: S3 deploy (bucket, endpoint, región, access key, secret key en Settings → Deploy), corriendo vía rclone después del paso de rsync. Puedes usar uno, otro o ambos: ambos corren en cada build exitoso cuando están habilitados. Todos los destinos de despliegue se disparan en el mismo orden por build: webhooks primero (build webhook), luego rsync, luego S3.