Estado
Activo, reemplazado, falló, revertido o expirado. La versión en el aire aparece destacada arriba de la lista.
Deploys · rollback · sin downtime
Cada deploy se convierte en una versión. Volver lleva un clic.
Todo envío de código, desde GitHub, la CLI o el panel, entra en el historial de la app. Si la versión nueva da problemas, vuelves a la anterior sin rehacer nada. En los planes mayores, la plataforma vuelve sola o ni siquiera saca la app del aire.
vertracloud.app/dashboard/apps/tienda-api/deploys
tienda-api
4 versionesRollback automático
ActivoBuild de 41 s
- Ver log
feat: cupón de primera compra
Falló7c4e2f1mainBuild de 38 s
fix: timeout en el checkout
ReemplazadoCLIBuild de 12 s
Enviado desde el panel
ReemplazadoPanel
≤ 30versiones anteriores guardadas
≤ 30días de validez por versión
60 sde ventana del rollback automático
Pestaña Rollbacks
El historial del código, versión por versión.
Cada envío de código se convierte en una versión completa, venga de donde venga. La pestaña Rollbacks muestra cuál está en el aire y qué vino antes. Quién hizo qué sigue en la pestaña Actividades.
Commit y mensaje
El SHA corto y el mensaje del commit. Un envío sin mensaje recibe una etiqueta según su origen, como “Enviado desde la CLI”.
Origen
GitHub con la rama, CLI, panel o editor de archivos. Un rollback también entra en la lista, como versión nueva.
Build y log
Cuánto tardó el build. Cuando una versión falla, “Ver log” abre el registro de esa caída.
En Economy, la pestaña muestra el historial sin volver a versiones. En apps que ya existían, el historial empieza en el próximo envío de código.
Rollback · desde Pro
El código vuelve. Los datos se quedan.
Elige la versión y confirma. La plataforma cambia los archivos y reinicia la app en la misma operación. El rollback entra en el historial como una versión nueva, así que puedes deshacerlo de la misma forma.
El código vuelve
Todos los archivos del código vuelven a como estaban en esa versión. Los archivos que llegaron por commits posteriores se eliminan.
Los datos se quedan
Lo que la app escribe mientras corre, como una base SQLite o archivos subidos, no forma parte de ninguna versión y se queda como está. Para volver datos, usa los Snapshots.
Variables, solo si lo marcas
Por defecto, las variables actuales se quedan. Marca la opción para volver a las variables con las que corría esa versión. El diálogo lista cuáles cambiarían, solo por nombre, sin mostrar valores.
Volver a 3b9a0d4
“fix: timeout en el checkout” (ayer, 18:04)
Archivos del código: siempre vuelven.
Volver a las variables de entorno de ese deploy
Variables que cambian
- DISCORD_TOKENmodificada
- NEW_FEATUREse eliminará
Los datos que la app creó mientras corría no vuelven. La app se reinicia al confirmar.
Rollback automático · desde Intermediary
Si la versión nueva cae al iniciar, la anterior vuelve sola.
Viene activado en los planes que lo incluyen, y puedes desactivarlo en la configuración de la app.
- 01
El deploy reinicia la app
La versión nueva arranca con el código que acaba de llegar.
- 02
Cayó en el primer minuto
Si la app se detiene en los primeros 60 segundos, el auto-restart no insiste con la versión nueva: la plataforma vuelve a la anterior, una sola vez.
- 03
Te enteras
Una notificación dice que el deploy cayó y a qué versión volvió la app, con enlace al log de la versión que falló.
- Solo vuelven los archivos del código. Las variables se quedan como están.
- Si la versión anterior también cae, la app queda detenida y recibes un aviso. No hay bucle de rollbacks.
- Una caída después del primer minuto se trata como una caída normal, con el auto-restart.
Deploy sin downtime · Enterprise
La versión nueva arranca al lado. El tráfico solo cambia cuando responde.
En una app que recibe tráfico web, el deploy no tira la versión en el aire: la nueva arranca junto a ella, pasa el chequeo de salud y solo entonces toma el control.
- 01
Arranca al lado
La versión nueva instala las dependencias, hace el build y arranca mientras la actual sigue atendiendo.
- 02
Chequeo de salud
La plataforma hace peticiones a la ruta configurada (“/” por defecto) hasta tener dos respuestas buenas seguidas. Cualquier respuesta HTTP cuenta, incluso un 404; un error 5xx o una conexión rechazada, no.
- 03
Cambio
Ya saludable, la versión nueva empieza a recibir el tráfico y la anterior se apaga.
- 04
O se descarta
Si la versión nueva no queda saludable en unos 2 minutos, se descarta y la anterior sigue en el aire, sin haberse detenido.
Qué saber antes de activarlo
La segunda copia no cuenta en la RAM de tu plan durante el cambio. Si el servidor no tiene memoria libre para ella, el deploy detiene la versión actual antes de arrancar la nueva, con el rollback automático activo.
- Las dos versiones usan la misma carpeta y corren juntas hasta unos 2 minutos. Un archivo JSON escrito por las dos a la vez puede corromperse; SQLite suele aguantar. Una migración de base de datos hecha al iniciar corre con la versión anterior todavía atendiendo.
- Una app que lee archivos en cada petición (PHP, sitio estático, Next.js o Nuxt ya compilado, imports tardíos en Python) puede servir archivos mezclados mientras el deploy instala y hace el build. Para esas, usa el modo Desactivado.
- Una app que solo escucha en 127.0.0.1 no pasa el chequeo de salud. El log dice el motivo.
- Durante el build, la terminal muestra la versión que está en el aire. El build aparece en los logs de instalación.
- Cerca del cambio, las dos versiones atienden juntas durante unos segundos.
Bots y workers
Por qué los bots no usan deploy sin downtime por defecto.
Dos procesos con el mismo token reciben los mismos eventos. Durante el cambio, un comando por prefijo se respondería dos veces, un slash command daría error de interacción ya respondida en una de las copias y las tareas programadas correrían por duplicado. Y un bot no recibe tráfico web, así que no hay tráfico que pasar a la versión nueva.
Tres modos, en la configuración de la app
Automático
El predeterminado. Sin downtime solo para apps que reciben tráfico web; bots y workers se detienen y arrancan, con el rollback automático.
Activado
Fuerza el deploy sin downtime en cualquier app, bots incluidos. Sin tráfico web, la versión nueva es saludable tras 30 segundos corriendo sin caer. Durante el cambio, un evento puede responderse dos veces.
Desactivado
La versión actual se detiene antes de que arranque la nueva. Sirve para apps que leen archivos en cada petición; la app queda unos segundos fuera del aire.
Límites por plan
Cuántas versiones se guardan, y por cuánto tiempo.
Las versiones cuentan además de la que está en el aire. La validez empieza cuando la versión deja de ser la activa; la versión en el aire nunca expira. Tras su validez, la versión sigue en el historial, pero ya no se puede volver a ella.
| Plan | Versiones anteriores | Validez | Rollback automático | Sin downtime |
|---|---|---|---|---|
| Economy | Solo lectura | No incluido | No incluido | |
| Pro | 3 | 7 días | No incluido | No incluido |
| Scale | 5 | 14 días | No incluido | No incluido |
| Intermediary | 10 | 30 días | Incluido | No incluido |
| Enterprise-4 · 6 · 8 | 15 | 30 días | Incluido | Incluido |
| Enterprise-12 · 14 · 16 | 20 | 30 días | Incluido | Incluido |
| Enterprise-18 · 20 · 22 · 24 | 25 | 30 días | Incluido | Incluido |
| Enterprise-26 · 28 · 30 · 32 | 30 | 30 días | Incluido | Incluido |
En Enterprise, el número de versiones crece con el nivel del plan.
Comparar planesPreguntas frecuentes
Antes de tu próximo deploy
Qué pasa con el código, los datos y las variables cuando vuelves a una versión.
¿El rollback borra los datos de mi app?
No. El rollback solo cambia el código. Lo que la app escribe mientras corre, como una base SQLite o archivos subidos por los usuarios, se queda como está. Un archivo que tú mismo commiteaste vuelve como cualquier otro archivo del código. Para volver datos, usa los Snapshots.
¿Puedo volver también las variables de entorno?
Sí, si marcas la opción en el diálogo. Vuelve a las variables con las que corría esa versión. Antes de confirmar, el diálogo lista solo los nombres de las variables que cambiarían; los valores nunca aparecen.
¿Funciona con GitHub, la CLI y la subida desde el panel?
Sí. Todo envío de código se convierte en una versión completa, venga de donde venga, y cualquiera de ellas puede ser destino de un rollback mientras esté dentro del límite y la validez del plan.
Mi app ya existía. ¿Puedo volver a versiones antiguas?
El historial empieza en el primer envío de código después del lanzamiento de la función. Las versiones anteriores no se guardaron, así que no hay forma de volver a ellas.
¿Qué pasa con las versiones si cambio de plan?
Valen el número de versiones y la validez del plan nuevo. En un downgrade, las versiones que superan el límite dejan de estar disponibles; en un upgrade, lo que ya se borró no vuelve.
¿Puedo desactivar el rollback automático?
Sí, en la configuración de la app o por la API, en PATCH /v1/apps/:id/config. Desactivado, una caída justo después del deploy sigue el auto-restart normal.
Desde Pro
Haz deploy sabiendo que puedes volver.
Crea la cuenta, sube la app y el historial empieza en el primer envío de código.