Deploy: cómo tu app llega a internet y cómo volver atrás
Cómo llega una app a internet, qué diferencia hay entre vista previa y producción y cómo volver a una versión anterior si un despliegue sale mal.
¿Cómo llega una app a internet?
Tu app vive en tu computador mientras la desarrollas. Para que alguien la use, hay que copiarla a un servidor que la sirva y asignarle una dirección. Ese paso es el despliegue. En muchas plataformas basta con conectar el repositorio (ver Git para diseñadores): cada vez que subes un cambio, se crea un despliegue automáticamente.
La documentación de Vercel, consultada el 30 de octubre de 2026, define un despliegue como el resultado de una compilación exitosa del proyecto, y cada uno recibe una URL única para ver los cambios en un entorno real. La forma más común de crearlo es subir código a un repositorio conectado: cada commit o pull request lanza un despliegue nuevo. También se puede desplegar desde la línea de comandos, arrastrando una carpeta al navegador (Vercel Drop), con un enlace de activación (deploy hook) o con la API (Vercel, Deploying to Vercel).
¿Qué diferencia hay entre vista previa y producción?
| Tipo | Para qué sirve | Quién la ve |
|---|---|---|
| Vista previa | Probar un cambio sin afectar el sitio en vivo | Quien tenga acceso a su URL; según la plataforma y su configuración, puede ser pública o estar protegida |
| Producción | La versión oficial, en el dominio principal | Los usuarios reales |
Vercel separa tres entornos: local (tu computador), vista previa y producción, y permite promover una vista previa a producción cuando está probada. La regla de oro es no probar en producción. La vista previa es el lugar donde ves el cambio con datos de prueba realistas, con alguien que no lo construyó, y solo después lo promueves.
¿Qué hacer cuando un despliegue sale mal?
Lo primero es restaurar el servicio, y lo segundo es entender qué pasó. La guía de Vercel para recuperarse de un despliegue roto sigue ese orden: confirma que producción está rota (mira los registros de errores o los reportes de usuarios), vuelve a un despliegue anterior, comprueba que los errores bajaron y solo después busca la causa (Vercel, Rolling back a production deployment).
Según esa guía, la reversión apunta el tráfico de producción a un despliegue anterior sin reconstruir el proyecto. Ocurre en la capa de enrutamiento, así que tiene efecto en segundos. El alcance depende del plan: en Hobby solo puedes volver al despliegue de producción inmediatamente anterior, mientras que en Pro y Enterprise puedes elegir cualquiera.
Con el servicio restaurado, la guía propone identificar el despliegue que falló, revisar sus registros de compilación (por ejemplo, variables de entorno que faltaban) y comparar los errores con los del último despliegue que funcionaba. Luego se corrige, se prueba en una vista previa y se promueve a producción. Si el fallo viene de un cambio hecho con IA, la búsqueda de causa se parece al método de debugging con IA. Si el despliegue toca datos o pagos, revisa antes cuándo no hacer vibe coding.
¿Funciona igual en otras plataformas?
La idea se repite, con diferencias que importan. Según la documentación consultada hoy:
- Netlify genera Deploy Previews a partir de pull requests, merge requests o ejecuciones de agentes. Para volver atrás, el botón Publish Deploy de un despliegue anterior exitoso lo publica sin compilar de nuevo, y Netlify indica que la reversión es instantánea. Ojo: con la publicación automática activa, el siguiente despliegue de producción sobrescribe la versión restaurada; hay que bloquearla con Lock to stop auto publishing (Netlify, Manage deploys).
- Cloudflare Workers permite volver a una versión anterior, que se convierte en un despliegue nuevo, pero solo entre las 100 versiones publicadas más recientes. La reversión no cambia los recursos conectados, como bases de datos: si cambió la estructura de los datos, el código viejo puede fallar (Cloudflare, Rollbacks).
- Cloudflare Pages crea direcciones de vista previa públicas por defecto; Cloudflare Access las restringe a tu cuenta (Cloudflare, Preview deployments).
Lo que sirve en todas: volver atrás cambia el código, no los datos. Si tu cambio también modificó una base de datos, revertir la app puede no bastar.
¿Qué revisar antes de publicar?
Para un cambio hecho con IA, cuatro puntos bastan para un prototipo:
- La vista previa con una cuenta real. Prueba el flujo principal, no solo que la pantalla cargue. Pide a una persona que no lo construyó que lo haga y te diga qué no entendió.
- Los registros de errores. Una pantalla puede verse bien mientras el servidor falla en silencio. Vercel ofrece, por ejemplo, filtrar los registros de una vista previa por nivel de error.
- Los secretos. Las claves no deben aparecer en el código que llega al navegador. Ver variables de entorno y secretos y seguridad básica en vibe coding.
- El plan de vuelta. Antes de promover, anota la URL del despliegue actual que funciona. Si algo falla, no tendrás que buscarla en el momento más tenso. Anota también la hora de publicación y qué cambió.
Publicar pronto no significa publicar sin plan de vuelta, como en el flujo de de idea a app en un día. Un despliegue también es una decisión de calendario: los cambios grandes conviene publicarlos cuando alguien pueda vigilar los registros después. Un despliegue fallido es un error más del que la persona usuaria debe poder recuperarse; mira errores de IA y cómo recuperarse.
Ejemplo
Ejemplo ilustrativo: una diseñadora publica una nueva página de precios. A los diez minutos de promover el cambio, soporte reporta que el botón de compra da error. Ella revierte producción al despliegue anterior, comprueba en los registros que los errores bajaron y deja de tocar producción. Luego abre la vista previa del mismo cambio, encuentra que una variable de entorno no estaba configurada en producción, la corrige y promueve la versión arreglada. El servicio volvió antes de investigar la causa, que es lo que importaba.
Errores comunes
- Probar cambios directamente en producción.
- Promover un cambio sin revisar los registros de errores.
- No saber qué despliegue anterior funcionaba.
- Revertir el código y olvidar que los datos no se revierten con él.
- Tratar el despliegue como el final del trabajo, cuando solo es el comienzo de la verificación.
- Dejar una clave de servicio en el código que llega al navegador.
- Investigar la causa mientras los usuarios siguen viendo el error.
Fuentes
- Vercel, “Deploying to Vercel”: definición de despliegue, URL única, formas de desplegar y entornos local, vista previa y producción.
- Vercel, “Rolling back a production deployment”: orden de la recuperación, reversión sin reconstruir y límite del plan Hobby frente a Pro y Enterprise.
- Netlify, “Manage deploys”: Publish Deploy y bloqueo de la publicación automática.
- Netlify, “Deploy overview”: Deploy Previews.
- Cloudflare, “Rollbacks” (Workers): reversión a una de las 100 versiones más recientes y recursos que no cambian.
- Cloudflare, “Preview deployments” (Pages): vistas previas públicas por defecto y Cloudflare Access.