Qué incluye
Tres scripts bash pequeños, un helper de alertas compartido y los archivos de configuración para conectarlo todo. Se leen en diez minutos y no hay nada que instalar, aparte de las herramientas que llaman.
| Archivo | Qué hace |
|---|---|
deploy.sh | Clona una release, la compila, comprueba su health check y hace rollback si falla. Tiene dos modos: restart (symlink más reinicio con pm2) y bluegreen (cero peticiones fallidas en la prueba de más abajo). En modo blue/green, deploy.sh rollback vuelve a la versión anterior. |
backup.sh | Hace dumps seguros de las bases SQLite y Postgres y luego los respalda con restic (por defecto 7 diarios, 4 semanales y 6 mensuales) y comprueba el repositorio. Si un dump está corrupto, la ejecución se detiene antes de crear ningún snapshot. |
restore-test.sh | Restaura el último snapshot en un directorio temporal, verifica los dumps de las bases, ejecuta tu propia comprobación (opcional) y lee una muestra de los datos. |
notify.sh | Envía un mensaje de Telegram o un POST a un webhook cuando falla cualquiera de los scripts. Si todo va bien, no dice nada. |
| Configuración | kit.env.example, Caddyfile.example, ecosystem.config.js, cron.example |
Deploys sin caídas, con mediciones
En modo bluegreen, la nueva release arranca en el puerto libre y se comprueba directamente. Después Caddy cambia hacia ella con un reload sin cortes, y solo entonces se detiene la release anterior. Una release que no pasa el health check nunca recibe tráfico.
Configuración de la prueba: un container Debian 12, Caddy 2.6.2 desde apt, pm2, una app Node que tarda 1.5 segundos en arrancar y una carga de 20 peticiones por segundo a través de Caddy durante todo el deploy (una de cada cinco va a un endpoint que tarda 300 ms). Una petición cuenta como fallida si hay un error de conexión, un timeout de más de 3 segundos o cualquier estado distinto de 200.
| Escenario | Peticiones | Fallidas | Duración del deploy |
|---|---|---|---|
Modo restart, release correcta | 116 | 32 (todas HTTP 502) | 2.4 s |
Modo restart, release rota (con rollback) | 380 | 67 (todas HTTP 502) | 16.8 s |
bluegreen, release correcta | 211 | 0 | 7.6 s |
bluegreen, release rota (el health check devuelve 500) | 373 | 0 | 16.6 s |
bluegreen, release que se cae al arrancar | 371 | 0 | 16.5 s |
bluegreen, rollback | 208 | 0 | 7.5 s |
En la ejecución blue/green correcta, la carga vio las dos versiones (115 respuestas de v1 y después 96 de v2), así que el tráfico se movió de verdad. En varias ejecuciones, el modo restart falló entre 31 y 35 peticiones, y blue/green no falló ninguna.
Backups que de verdad has restaurado
- Las bases de datos se vuelcan como toca. SQLite usa su backup en línea y una comprobación de integridad; Postgres usa
pg_dump -Fcypg_restore -l. Copiar el archivo de una base en uso es la forma clásica de acabar con un backup corrupto. - Un dump malo detiene la ejecución. En la prueba, un archivo SQLite corrupto abortó el backup sin crear ningún snapshot.
- No se cuelan dumps viejos. Una base que quitas de la configuración deja de aparecer en los snapshots nuevos.
restore-test.shlo demuestra. Restaura, comprueba los dumps y ejecutarestic checksobre una muestra. Lánzalo cada semana desde cron.- Repositorio remoto. Los repositorios
sftp:funcionan con ambos scripts (probados contra un servidor OpenSSH local).
Alertas de fallo
Define TELEGRAM_BOT_TOKEN y TELEGRAM_CHAT_ID, o bien NOTIFY_WEBHOOK_URL. Si falla un deploy, un backup o una prueba de restauración, se envía exactamente un mensaje por canal; si todo sale bien, no se envía nada. El token se pasa a curl por stdin y nunca se imprime, y si la API de notificaciones no responde, el código de salida del script no cambia.
Instalación en cinco pasos
- Instala
restic,git,curlypm2(ycaddypara blue/green, ysqlite3opostgresql-clientsegún las bases que uses). - Copia la carpeta al servidor, ejecuta
cp kit.env.example kit.envy edita el archivo. - Guarda la contraseña del repositorio en un archivo con permisos 600.
- Ejecuta
./backup.sh,./restore-test.shy luego./deploy.sh. - Añade las líneas de cron de
cron.example.
Cómo se probó
59 comprobaciones en un container Debian 12 limpio (Node 22, restic, PostgreSQL 15, Caddy 2.6.2 y OpenSSH desde apt, pm2). Cubren: backup de carpetas, SQLite y Postgres; restauración y comparación de filas; repositorio equivocado; base de datos corrupta; dump ausente; deploy y rollback en ambos modos bajo carga; alertas contra una API falsa local; y restic sobre SFTP.
Para quién es
Para desarrolladores individuales y equipos pequeños que llevan una o dos apps Node o Go en un único VPS Linux y quieren deploys y backups de fiar, sin tener que adoptar Kubernetes.
Requisitos
Linux, bash, pm2, restic, y Caddy para blue/green. Tu app lee su puerto de PORT. Blue/green mantiene dos releases en paralelo durante unos segundos, así que las migraciones de base de datos deben ser retrocompatibles.
Preguntas frecuentes
¿Necesito el kit para tener deploys sin caídas?
No. La técnica está explicada en este artículo con los comandos esenciales. El kit la empaqueta con health checks, rollback, manejo de estado, alertas y la batería de pruebas.
¿Qué stack da por supuesto?
Linux, bash, pm2, Caddy para blue/green, restic para los backups y una app que lee su puerto de la variable de entorno PORT.
¿Funciona con Postgres y SQLite?
Sí. De ambas se hace el dump y se verifica.
¿Lo puedo usar con varias apps?
Usa un kit.env por app y elige el archivo con KIT_CONF.
¿Qué licencia tiene?
Úsalo en tus propios servidores. No revendas los archivos.
Historial de cambios
- 0.3.0: deploys blue/green con rollback, alertas de fallo (Telegram y webhook), repositorios SFTP probados, todos los mensajes en inglés.
- 0.2.0: dumps de SQLite y Postgres en
backup.sh, verificación de dumps enrestore-test.sh. - 0.1.0: primera versión.
Leer más
- Zero-downtime deploys on one VPS with Caddy and pm2 (en inglés)
- restic forget and prune: how the keep flags decide (en inglés)
- A restic backup recipe for SQLite and Postgres on one VPS (en inglés)
- Monitoring backups so that silence never means success (en inglés)
- The 3-2-1 backup rule applied to a single VPS (en inglés)
Obtener
Polar, como merchant of record, se ocupa del pago, los impuestos y las facturas. Al terminar la compra recibes un enlace de descarga.