Lista de comprobación antes de dar por lista una aplicación nueva en producción. Cada punto está aquí porque ya ha causado un incidente real o es la causa más probable de uno.
Antes de esto, lee Capacidad y límites de la infraestructura si no lo has hecho: esta checklist da por hecho ese contexto.
/data-raid/apps/<app>/, voluminosos o regenerables → fuera del scope de backupglobaldb Tengo un endpoint /api/health (o /health, /healthz — cualquiera vale, pero documenta cuál usas)
Ese endpoint es ligero: responde 200 sin consultar la base de datos, sin llamar a APIs externas, sin hacer trabajo pesado. Se va a ejecutar cada pocos segundos indefinidamente
El healthcheck está activado en Coolify con esta configuración de referencia:
Path: /api/health
Interval: 30s
Timeout: 10s
Retries: 5
Start period: 60s (120s si hay migraciones de BD al arrancar)
Un start_period demasiado corto (5s es habitual por error) puede hacer que Coolify mate una aplicación sana que simplemente tarda en arrancar.
He verificado que el healthcheck realmente falla si la app está rota. No sirve un endpoint que siempre devuelve 200 pase lo que pase.
.gitignore excluye: .env, ficheros de base de datos (*.db, *.sqlite), credenciales, node_modules/, venv/, y cualquier fichero mayor de 100 MBalgo.pampl.ing coherente con el nombre de la aplicacióncurl -s https://tu-app.pampl.ing/api/health
running:healthy, no running:unknownSi solo puedes hacer cinco cosas de esta lista, que sean estas — son las que han causado incidentes reales:
start_period suficiente. El error más caro: convierte un despliegue roto en una caída de producción en lugar de un deploy rechazado./data-raid/apps. Evita inflar el backup diario con basura reproducible./dev/sdX. Las letras de disco rotan entre reinicios.