Rollback de un agente IA: Vercel, Railway, Fly y VPS

El CI/CD evita que un test rojo llegue a Production. No evita que un test verde se comporte mal con el LLM a las 2 AM. Rollback es el botón que ya deberías haber ensayado: volver a un deployment que sí contestaba. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

Si no sabes si el proceso vive, mira healthchecks y logs antes de revertir. Rollback no es debug.

La regla de 5 minutos

1. ¿El /health falla? Reinicia o rollback de host.
2. ¿Health 200 y los webhooks 500? Rollback de código.
3. ¿Solo un tool falla? Feature flag o desactivar esa tool; no bajes todo el agente.

Ensayar el rollback en Preview el día 1 cuesta 10 minutos. Inventarlo en el incidente cuesta una hora.

Vercel: Instant Rollback

Vercel guarda deployments previos de Production. Instant Rollback apunta el alias de producción al deployment anterior sin rebuild. CLI: vercel rollback. Dashboard: el deployment previo → Promote / Instant Rollback.

Úsalo cuando el Route Handler nuevo rompe el webhook y el anterior respondía. No sirve si el fallo es una API key rotada: el código viejo usa la misma variable.

Railway: Rollback = redeploy de uno viejo

Railway documenta Rollback como redeploy del deployment seleccionado, usando el código fuente de ese deployment. Notas oficiales:

• No es un puntero mágico: vuelve a construir/arrancar ese source.
• Deployments más viejos que la retención de imágenes del plan no se pueden restaurar y la opción ni aparece.

Remove para el deployment actual (lo marca REMOVED y lo manda al historial). Cancelar un build en initializing o building también lo marca REMOVED. El overlap antes de bajar el anterior se controla con RAILWAY_DEPLOYMENT_OVERLAP_SECONDS. Si dependes de rollback, no dejes que la retención del plan borre el único bueno: la opción de Rollback ni aparece cuando la imagen ya caducó.

Fly: elige la estrategia antes

fly deploy soporta rolling (default), immediate, canary y bluegreen. Canary arranca una Machine, verifica health, y sigue. Bluegreen arranca una nueva al lado de cada una y migra tráfico cuando todas están listas.

Rollback en Fly = fly deploy del commit anterior, o fly machine al image digest previo si lo anotaste. immediate en Production es cómo te quedas sin versión buena a mitad de deploy.

VPS: git + compose

En self-hosting:

git fetch && git checkout <sha-bueno>
docker compose up -d --build

Anota el SHA que está live (git rev-parse HEAD post-deploy). Sin SHA, “el anterior” es folklore. Un tag prod que mueves después de verificar /health alcanza para un agente de un inquilino.

Errores comunes

Síntoma	Causa típica	Fix
Rollback y el bug sigue	El fallo es un secreto o un volumen, no el código	Revisa env vars y estado; no solo el SHA
Railway no muestra Rollback	Imagen fuera de retención del plan	Sube de plan o guarda el image digest
Fly a medias	Estrategia immediate	rolling o canary
Vercel rollback OK, cron nuevo sigue	vercel.json del deployment anterior no tenía ese cron	El rollback restaura todo ese deployment, no un archivo
VPS git checkout y Compose no rebuild	Cache de imagen	--build y prune

Relación con el resto

• Tests antes: CI/CD.
• ¿Está vivo?: healthchecks.
• ¿Por qué falló?: logs.

Rollback sin healthcheck es apagar la luz. Healthcheck sin rollback es mirar el incendio.

Cuándo NO hagas rollback

• El fallo es una cuota del LLM o un 429: el código viejo pega al mismo proveedor. Espera o cambia de modelo, no de SHA.
• El volumen de sqlite quedó a medias: volver el binario no deshace un write. Restaura backup, no el container.
• No tienes el deployment id / SHA bueno: rollback a “algo” es un segundo incidente. Mira logs y el dashboard primero.
• Estás en un deploy canary de Fly que aún no migró tráfico: aborta el canary; no toques las Machines viejas.

El rollback es barato cuando el artefacto anterior existe. Si tu plan ya lo borró, el plan era el bug.

Documenta en el README del agente tres líneas y basta: comando de rollback, id del último bueno, y quién lo ejecuta. Si el “quién” eres tú a las 2 AM, el comando tiene que caber en un comentario, no en un runbook de 12 páginas. En CI/CD el Environment de Production ya es el sitio para exigir un revisor; el rollback de emergencia es la excepción, no el flujo normal.

Checklist (escríbelo el día 1)

• Comando de rollback por plataforma, en un comentario del repo
• SHA o deployment id del último “sí contestaba”
• Retención de Railway/Vercel conocida
• Fly no usa immediate en prod
• Ensayo en Preview al menos una vez

Si el ensayo de Preview nunca se hizo, el primer rollback en Production es un experimento. Hazlo una vez en frío: despliega, rompe a propósito un string, vuelve atrás, confirma /health. Diez minutos que no se negocian.

---

Siguiente paso: si el rollback es frecuente, el problema es el pipeline o las evals, no el botón. Vuelve a CI/CD y a observabilidad. Si todavía no tienes runtime, el curso gratuito deja un agente local para practicar el ciclo deploy → romper → volver.