Tu Replit Agent cambia una app que ya recibe pedidos. La nueva pantalla funciona, pero la publicación deja de leer datos. Ves un botón «Rollback to here» y piensas que recuperará código, conversación y base de producción de una vez. Esa suposición es peligrosa: Replit tiene varias capas de historial y la base de producción sigue otro camino. Antes de pedir a un agente una refactorización grande, conviene saber qué puedes restaurar realmente.
Según la documentación de control de versiones de Replit, los Agent Checkpoints aparecen automáticamente en hitos de desarrollo y se guardan como parte del historial Git del proyecto. Capturan archivos, configuración y contexto de la conversación con el agente. El panel Git permite commits manuales, ramas y conexión con GitHub para trabajar fuera de Replit. El historial de archivo sirve para cambios puntuales. Son herramientas relacionadas, pero resuelven necesidades distintas.
Qué vuelve al usar un checkpoint
Al elegir «Rollback to here» desde la pestaña Agent, se restaura el estado de archivos y conversación de ese punto. La guía de checkpoints especifica algo fácil de pasar por alto: la base de datos de desarrollo no cambia por defecto. Para restaurarla hay que seleccionar «Database» en las opciones adicionales del rollback. Eso puede borrar datos de prueba agregados después de ese punto, así que revisa el alcance antes de confirmar. Un rollback modifica tu estado actual; guarda un commit manual de una versión estable antes de experimentar si necesitas un punto fácil de comparar.
Qué aporta GitHub y qué no copia
En Project Editor abre Tools → Git. Si el repositorio aún no existe, inicialízalo; revisa el diff, crea un commit con un nombre entendible y conecta GitHub si quieres una copia del código y su historial fuera de la app. Después del push, abre GitHub y verifica que el commit y los archivos estén allí. No tomes el botón de sincronización como prueba de respaldo hasta hacer esa comprobación.
GitHub es excelente para recuperar una versión de código o revisar qué cambió entre ramas. No es una copia de las filas vivas de tu base de datos ni del estado completo del entorno Replit. Además, evita subir secretos, archivos .env o exportaciones con datos personales al repositorio. Si dependes de un servicio externo como Supabase, su respaldo se gestiona por separado.
Producción tiene otra ruta de recuperación
La documentación de bases de datos distingue desarrollo y producción: el editor y el agente trabajan sobre la primera; la app publicada usa la segunda en la configuración normal. Replit aclara que el rollback de un checkpoint no restaura automáticamente la base de producción. Para un incidente de datos reales hay que usar la recuperación específica de la base de producción y validar que el punto elegido no elimine pedidos o usuarios recientes.
Imagina que la app tenía 100 pedidos al iniciar la mañana y 30 nuevos cuando descubres el error. Volver el código a una versión anterior puede reparar el sitio sin tocar los 130 registros. Restaurar la base a un punto anterior, en cambio, puede eliminar los pedidos recientes. Esa diferencia obliga a decidir por separado: ¿falló el código, el esquema o los datos? Nunca pulses restaurar la base solo porque el deploy anterior funcionaba.
Una rutina de cinco minutos antes del cambio
- Comprueba que existe un checkpoint estable y anota su hora y descripción.
- Revisa el diff, crea un commit manual y verifica el push a GitHub si usas repositorio externo.
- Identifica si tu app usa la base gestionada por Replit o una conexión externa. No copies cadenas de conexión al chat.
- Para producción, comprueba que existe un procedimiento de respaldo y restauración probado; el checkpoint no lo sustituye.
- Pide al agente un plan de cambio pequeño, con una prueba del flujo principal y un criterio claro para revertir solo el código.
Haz un ensayo en un proyecto descartable: cambia un archivo visible y añade una fila de prueba en desarrollo, pide al Agent un checkpoint, modifica ambos otra vez y abre la vista de historial. Antes de confirmar rollback, observa si la opción Database está marcada. Después comprueba archivo y fila por separado. El ensayo te enseña qué cambia en tu plan y tu interfaz actuales; no uses una base con clientes para aprender el comportamiento.
SoyJB no ejecutó un rollback en una cuenta Replit propia para esta guía; los límites descritos vienen de la documentación oficial. El resultado buscado no es acumular tres botones de «backup», sino saber cuál usar: checkpoint para estado de desarrollo y contexto, GitHub para historial externo de código, y recuperación de base para los datos de producción.