Vercel vs Railway vs Render depende del riesgo de reversión

Un SaaS en Next.js heredado no es seguro porque su proveedor tenga un botón de Revertir. Es seguro cuando la aplicación anterior aún puede ejecutarse con la base de datos actual y los secretos correctos mientras alguien que no escribió el sistema averigua qué cambió. Según esa prueba, Vercel ofrece la reversión de código más limpia para una aplicación Next.js convencional, Render presenta el modelo de entorno completo más explícito y Railway ocupa un punto intermedio práctico para una pila de servicio y base de datos.

Mi elección predeterminada es Vercel cuando la aplicación encaja en su modelo administrado de Next.js y la base de datos ya cuenta con un proceso disciplinado de migraciones. Elijo Render cuando necesito copias desechables de varios servicios y almacenes de datos definidos como infraestructura. Elijo Railway cuando la aplicación heredada se comporta más como un servicio en contenedor y el equipo quiere un panel de proyecto sencillo con entornos aislados. Ninguna opción puede deshacer una migración SQL destructiva ni revertir la rotación de una credencial.

Por tanto, la decisión empieza por el límite de recuperación, no por una tabla de funciones. El código, la configuración, los datos, los trabajos en segundo plano y los recursos del navegador avanzan con ritmos distintos. Un proveedor puede cambiar el código a la perfección y el sistema seguir roto porque uno de los demás elementos ya avanzó.

El mismo fallo revela tres modelos de recuperación distintos

Una comparación justa necesita un único incidente. Pensemos en este: una agencia hereda un SaaS en Next.js con Postgres, inicio de sesión por correo, un webhook de facturación y un worker que envía mensajes en cola. Una versión cambia el nombre de users.plan por users.plan_code, modifica la carga del worker y rota AUTH_SECRET. El desarrollador probó una vista previa de la página con datos de producción, fusionó el cambio a las 16:00 y vio comprobaciones de estado correctas. A las 16:07, las sesiones existentes empezaron a fallar, el worker anterior comenzó a rechazar las cargas nuevas y una ruta de administración poco usada seguía consultando users.plan.

El operador quiere volver a publicar el código anterior. Parece una acción sencilla, pero plantea cinco preguntas distintas:

• ¿Puede el proveedor dirigir el tráfico a una compilación conocida sin volver a compilarla?
• ¿Qué valores de variables de entorno recibirá esa compilación?
• ¿La migración eliminó datos que necesita la compilación anterior?
• ¿El tráfico de la vista previa puede acceder a datos reales o enviar correos reales?
• ¿Un despliegue automático sustituirá de inmediato la compilación de recuperación?

Vercel puede redirigir el tráfico de producción a un despliegue anterior válido en la capa de enrutamiento. Su guía actual de reversión dice que esto ocurre sin recompilar, y su documentación de Instant Rollback advierte que las bases de datos y las API externas no vuelven atrás con el despliegue. Esa advertencia ocupa el centro de esta comparación, no una nota al pie.

Railway describe la reversión como un nuevo despliegue de la versión anterior seleccionada que restaura tanto su imagen Docker como sus variables personalizadas. Render inicia un despliegue nuevo con el artefacto de compilación elegido y reutiliza las variables de entorno del servicio de ese despliegue, mientras algunos valores compartidos de grupos de entorno permanecen como están. Los tres conservan parte del estado anterior de la aplicación. Difieren en qué conservan exactamente y con qué rapidez lo devuelven al servicio.

En este incidente, la primera reversión solo restaurará probablemente la ruta de administración si la base de datos todavía expone users.plan. Puede invalidar todas las sesiones si el despliegue restaurado recibe el AUTH_SECRET equivocado. También puede dejar dos versiones del worker consumiendo trabajos incompatibles. Un evento verde en la plataforma demuestra que la maquinaria de despliegue funcionó. No demuestra que el SaaS se haya recuperado.

Un despliegue inmutable no equivale a una versión reversible

Los tres proveedores conservan artefactos de despliegue de alguna manera, pero un despliegue inmutable no implica que la versión pueda revertirse. La inmutabilidad indica que el artefacto compilado no cambia después de crearlo. La reversibilidad indica que todo el comportamiento visible para el usuario puede regresar a un estado conocido después de cambiar código, configuración y datos. La primera propiedad ayuda a la segunda, pero no puede garantizarla.

Esta distinción atrapa a los sistemas Next.js heredados porque un repositorio suele contener varias unidades de publicación que parecen una sola aplicación. El despliegue web puede incluir componentes del servidor, controladores de rutas y recursos estáticos. Otro proceso puede ejecutar consumidores de colas. Una tarea programada puede ejecutarse desde la configuración de la plataforma. Postgres, el almacenamiento de objetos, el proveedor de facturación y el de correo conservan su estado en otros lugares. Revertir un artefacto inmutable solo cambia una fila de ese inventario.

Las comprobaciones de estado reducen aún más la visión. Una consulta a /api/health puede demostrar que el proceso arrancó y responde por HTTP. No demuestra que pueda leer una sesión cifrada existente, actualizar una fila antigua de la base de datos, verificar la firma de un webhook o consumir un trabajo en cola. En este SaaS, la comprobación útil de la versión debe recorrer esas rutas sin provocar efectos reales sobre clientes.

Uso dos niveles de comprobación. El endpoint de estado de la plataforma es rápido y no tiene efectos secundarios, para que el proveedor decida si una instancia debe recibir tráfico. Una prueba de publicación aparte inicia sesión con una cuenta sintética, lee y cambia un registro desechable, envía un trabajo de prueba y confirma el resultado del worker. Esa prueba se ejecuta antes de promocionar y después de revertir; el balanceador de carga nunca debe invocarla.

El navegador añade otro límite de versión. Un usuario puede mantener una pestaña abierta durante el despliegue y después enviar un formulario o solicitar una acción del servidor desde código cargado antes del cambio. Skew Protection de Vercel resuelve el desfase entre recursos y funciones de Next.js compatibles, pero los contratos de la aplicación todavía necesitan tolerancia. Los despliegues de Railway y Render también exigen que la aplicación procese solicitudes que comenzaron antes del cambio de tráfico. Evita modificar identificadores de acciones, formatos de cookies y campos obligatorios de modo que una sesión abierta falle de inmediato.

Los trabajos en segundo plano crean el solapamiento más largo. Un trabajo escrito a las 15:58 puede ejecutarse después de la versión de las 16:00, y un reintento puede ocurrir después de la reversión de las 16:07. Por eso, productores y consumidores necesitan una ventana de compatibilidad mayor que el cambio de tráfico web. Versiona las cargas, empieza haciendo opcionales los campos nuevos y permite que los consumidores manden una versión desconocida a cuarentena en lugar de descartarla o reintentarla sin fin.

También conviene desconfiar de la reproducibilidad de las compilaciones. Una reversión que reutiliza un artefacto conservado es más segura que recompilar un commit antiguo con el registro de paquetes, la etiqueta de imagen base y las herramientas de hoy. Vercel apunta a un despliegue existente. Render afirma que reutiliza un artefacto conservado en una reversión normal. Railway restaura la imagen Docker seleccionada en su flujo documentado. Los límites de retención siguen decidiendo si ese artefacto existirá cuando haga falta.

Las etiquetas mutables de contenedor debilitan la promesa. Render advierte expresamente que al revertir una imagen de registro referenciada por etiqueta puede descargar lo que esa etiqueta señale ahora, mientras que un digest identifica la misma imagen. La regla general va más allá de un proveedor: registra un digest de imagen o un identificador de despliegue de la plataforma como objetivo de recuperación. Un commit de Git no es un binario, y recompilarlo constituye un evento nuevo.

Llama reversible a una versión solo cuando el equipo pueda restaurar un conjunto probado de versiones web, worker, esquema y configuración sin adivinar. Esta definición es más estricta que el vocabulario de las plataformas y evita la peor sorpresa de un incidente: descubrir que el botón funcionó exactamente como decía la documentación mientras la aplicación seguía caída.

Vercel gana en la reversión pura de código Next.js

Vercel es la primera opción más segura cuando la unidad de recuperación es un despliegue de Next.js y los sistemas con estado quedan fuera. Cada despliegue recibe una dirección única y los dominios de producción apuntan a uno de ellos. Instant Rollback cambia ese puntero a un despliegue de producción anterior en vez de recompilar el código fuente. De las tres opciones, es lo más parecido a un cambio atómico de código.

La ventaja operativa es una menor carga mental durante un incidente. Un operador puede revisar despliegues recientes, localizar un commit conocido, revertir, comprobar el estado y comparar registros. La secuencia de CLI tiene una forma clara de salida:

vercel list
vercel inspect <bad-deployment-url>
vercel rollback <good-deployment-url>
vercel rollback status

vercel list devuelve despliegues recientes con sus direcciones y antigüedad; el operador elige el candidato de producción. vercel inspect vincula ese candidato con su commit de Git y sus metadatos de configuración. vercel rollback status indica si terminó el cambio de enrutamiento. La documentación del proveedor también dice que una reversión desactiva la asignación automática del dominio de producción hasta que alguien promocione un despliegue, lo que evita que el siguiente push deshaga en silencio la recuperación.

Hay límites. Las cuentas Hobby solo pueden volver al despliegue de producción inmediatamente anterior, mientras que los planes superiores permiten seleccionar otros despliegues de producción válidos. Una vista previa que nunca recibió un dominio de producción normalmente no puede usarse como objetivo de Instant Rollback. Conviene revisar la política de retención antes de un incidente, aunque Vercel conserve despliegues de producción recientes según sus reglas documentadas.

Vercel también ofrece Skew Protection para versiones compatibles de Next.js. Ayuda a mantener al navegador en recursos y funciones de servidor de un mismo despliegue mientras se publica una versión nueva. Reduce el desfase de versiones durante publicaciones normales, pero no concilia dos esquemas de base de datos ni dos formatos de trabajo. Es una protección contra recursos mezclados de la aplicación, no una transacción que abarque toda la pila.

Elige Vercel para este SaaS heredado solo después de confirmar que sus supuestos de ejecución de Next.js encajan en la plataforma, que su trabajo de larga duración tiene un lugar adecuado y que cada cambio de base de datos sigue siendo compatible con la aplicación anterior. Si esas condiciones fallan, el rápido cambio de puntero puede devolver código antiguo a un mundo que ya no entiende.

Railway mantiene comprensible una pila de servicios

Railway suele ser más fácil de entender cuando la aplicación Next.js es un servicio entre Postgres, un worker y quizá una API privada. Su modelo de proyecto y entornos agrupa esos recursos sin fingir que forman un único objeto reversible. Los entornos de Railway aíslan cambios de configuración, y los entornos temporales de PR pueden aprovisionar los servicios afectados por una solicitud de cambios.

Una reversión de Railway usa el código fuente o la imagen del despliegue seleccionado y restaura las variables personalizadas asociadas, dentro de la retención del plan. Esa combinación importa en este incidente porque la aplicación anterior y su antiguo AUTH_SECRET pueden volver juntas. Sigue siendo un nuevo despliegue y no un cambio de puntero, así que la recuperación incluye el arranque y las comprobaciones de estado. Mídela con tu servicio en vez de asumir que la palabra reversión significa instantáneo.

Los entornos de PR pueden copiar la forma de un entorno base, incluidas las referencias entre servicios y las variables. La guía actual de Railway explica que los entornos de PR estándar replican todo el entorno base, mientras que los enfocados despliegan los servicios afectados y sus dependencias. Esto vuelve accesible un repositorio heredado con varios servicios: quien revisa puede comprobar si el servicio web y el worker coinciden en el formato de la carga antes de fusionar.

El peligro está en la herencia. Si un entorno de PR hereda credenciales de producción o una cadena que llega a datos reales, el aislamiento del panel es cosmético. Asigna a las vistas previas una base de datos aparte, un receptor de correo, una cuenta de facturación de pruebas y secretos incapaces de autorizar acciones de producción. Un entorno temporal debe fallar de forma segura cuando falta una variable exclusiva de producción.

Railway permite un comando previo al despliegue que se ejecuta después de compilar y antes de iniciar la aplicación, con acceso a la red privada y a las variables. Es un lugar razonable para una migración, pero su ubicación no la hace reversible. Si el comando elimina users.plan con éxito y el servicio nuevo falla después, una reversión de la aplicación no puede recrear el contenido de la columna.

Railway es mi elección intermedia. Expone la relación entre servicios mejor que una vista centrada en el frontend y exige menos definición de infraestructura que un Blueprint completo de Render. Pierde seguridad cuando la gente edita variables de producción sin cuidado o permite que cada servicio se despliegue por separado sin registrar qué versiones pertenecen al mismo conjunto.

Render hace explícito el límite del entorno

Render destaca cuando la recuperación incluye un servicio web, un worker, una base de datos y configuración compartida declarados. Un Blueprint puede definir esos recursos, y un entorno previo puede crear instancias nuevas de servicios y almacenes para cada PR. La documentación de Render deja claro que los almacenes de datos de las vistas previas no copian los datos de producción. Ese valor predeterminado obliga al equipo a decidir cómo aparecen los datos de prueba, lo cual conviene.

Los entornos previos requieren un Blueprint y un plan compatible. Pueden aplicar valores previewValue y ejecutar un initialDeployHook después del primer despliegue correcto de la vista previa. En un SaaS heredado, esto permite una prueba contenida: crear la base vacía, aplicar migraciones, cargar cuentas sintéticas y probar el comportamiento de la web y del worker. Exige más preparación que una vista previa de página, pero prueba el límite de fallo relevante.

La reversión de Render no cambia un puntero. La plataforma inicia un despliegue nuevo desde un artefacto retenido. El despliegue objetivo aporta el artefacto, el comando de inicio, la ruta de estado, el número de instancias y las variables del servicio. La configuración actual sigue rigiendo elementos como discos y dominios personalizados, mientras que los grupos de entorno tienen un comportamiento mixto. La tabla oficial de reversión es muy franca sobre esta división.

La división tiene dos consecuencias. Una variable del servicio guardada con el despliegue antiguo puede volver, pero un valor de un grupo compartido puede permanecer en su versión actual. Además, un disco persistente nunca se revierte con el servicio. Render permite restaurar instantáneas de disco por separado, pero revertir la aplicación y recuperar el disco son operaciones distintas y con riesgos distintos.

Una reversión iniciada desde el panel desactiva los despliegues automáticos, mientras que una iniciada mediante API no lo hace. El manual de incidentes debe nombrar la ruta que usa el operador; de lo contrario, dos personas pueden ejecutar reversiones aparentemente iguales y dejar estados de automatización distintos. La retención de artefactos también varía por plan, así que comprueba hasta qué fecha aparece la acción Revertir.

Para este escenario, Render ofrece la mejor fidelidad previa si toda la pila está descrita en un Blueprint. También da al operador más detalles de configuración que entender durante la recuperación. Elígelo cuando esa explicitud encaje con el equipo. No lo elijas porque el Blueprint parezca documentación mientras los secretos, servicios externos o cambios manuales del panel sigan sin documentar.

La migración de base de datos decide si la reversión existe

La compatibilidad de la base de datos pesa más que el proveedor cuando una versión cambia datos persistentes. Una reversión segura implica que la versión N y la versión N menos uno pueden funcionar durante la ventana de recuperación. El patrón fiable añade estructuras nuevas primero, mueve lecturas y escrituras poco a poco y elimina lo antiguo solo cuando la aplicación anterior ya no pueda regresar.

Para cambiar el nombre de plan, no renombres ni elimines la columna en la misma versión que modifica el código. Añade la columna nueva, completa sus valores y mantén ambos campos sincronizados mientras pueda ejecutarse código antiguo:

ALTER TABLE users ADD COLUMN plan_code text;
UPDATE users SET plan_code = plan WHERE plan_code IS NULL;

La aplicación nueva debe leer plan_code con una alternativa temporal a plan y escribir ambos campos. Otra versión posterior puede dejar de leer el campo antiguo. Solo cuando venza la ventana de reversión debe otra migración eliminar plan. Requiere más versiones que un cambio directo, y esa molestia compra recuperación real.

La misma regla se aplica a las cargas de trabajos. Añade un campo de versión y haz que los consumidores acepten el formato antiguo y el nuevo antes de que los productores emitan solo el nuevo:

{"version":2,"userId":"usr_123","template":"welcome"}

Un worker que rechaza toda carga sin version: 2 no puede convivir con trabajos de versión 1 en cola. Revertir el proceso web puede aumentar el desfase al producir más trabajos antiguos. Vacía, pon en cuarentena o transforma deliberadamente los trabajos incompatibles; nunca confíes en un reinicio para volver coherente la cola.

Un comando previo al despliegue resulta útil para ordenar la migración, pero una operación destructiva necesita aprobación aparte y comprobación de la copia de seguridad. Registra el identificador, la hora de inicio, el estado final y la acción de recuperación probada. Si volver atrás exige restaurar una copia, indica antes de publicar la ventana esperada de pérdida de datos. Restaurar una instantánea puede desechar escrituras válidas posteriores al despliegue, por lo que no es una reversión ordinaria.

Desaconsejo la recomendación popular de colocar prisma migrate deploy en el comando de inicio de la aplicación. Parece seguro porque cada instancia se configura sola. En un servicio escalado, varias instancias pueden competir o bloquear el arranque, y un error de migración puede convertir un reinicio rutinario en una caída. Ejecuta la migración una vez como acción de publicación, revisa el resultado y después inicia el código nuevo.

Los secretos tienen versiones aunque el panel las oculte

Una reversión necesita el conjunto de secretos con el que funcionaba la aplicación objetivo, pero restaurar un secreto anterior puede reabrir una credencial rotada por seguridad. Trata la reversión de configuración y la rotación de credenciales como decisiones separadas. El proveedor almacena valores; el manual debe explicar su significado y vigencia aceptable.

Las variables de Vercel se asignan a Production, Preview, Development y entornos personalizados opcionales, y los cambios se aplican a despliegues posteriores. Su documentación advierte que la compilación restaurada puede asumir una configuración distinta de la de los sistemas externos actuales. Railway dice que la reversión restaura las variables personalizadas del despliegue elegido. Render restaura variables del servicio, pero no retrocede los valores de grupos compartidos.

Por esas diferencias conviene un inventario sencillo de secretos. Guarda nombres y responsables junto al código, nunca los valores:

AUTH_SECRET:
  owner: application
  rotation: dual-read
  rollback: previous value valid for 24 hours
BILLING_WEBHOOK_SECRET:
  owner: billing-provider
  rotation: accept old and new signatures
DATABASE_URL:
  owner: operations
  rollback: never point production code at preview data

dual-read significa que la aplicación acepta temporalmente sesiones o firmas creadas con el secreto antiguo o el nuevo mientras emite las nuevas con el secreto actual. La compatibilidad depende de la biblioteca. Si no existe, espera que una rotación o reversión cierre sesiones y anota ese impacto para usuarios en el registro de la versión.

Nunca pongas secretos de producción en una vista previa para darle realismo. Usa credenciales de prueba restringidas y datos separados. Comprueba también la exposición durante la compilación: cualquier variable insertada en un valor NEXT_PUBLIC_ será visible en el navegador por diseño, sin importar la seguridad con la que la plataforma la almacene. En una base heredada, busca nombres de secretos en los paquetes del cliente antes del primer traslado a producción.

Las vistas previas necesitan efectos secundarios aislados

Una vista previa solo es segura cuando sus efectos no pueden escapar. Una URL única y una instancia de cómputo separada no impiden que envíe correos a clientes, cobre una tarjeta, consuma trabajos de producción, modifique una base compartida o acepte un webhook real.

Vercel crea automáticamente vistas previas para ramas que no son de producción y admite variables específicas, incluso por rama. Funciona bien para la superficie Next.js, pero las bases y los workers suelen requerir aprovisionamiento externo. Los entornos de PR de Railway pueden reproducir servicios conectados y variables del proyecto. Los entornos de Render pueden crear servicios y almacenes nuevos desde un Blueprint sin copiar datos existentes.

Usa el mismo contrato de aceptación en cada proveedor:

1. Crea un usuario sintético, inicia sesión y actualiza la sesión después de un nuevo despliegue.
2. Aplica migraciones a una base vacía y a una copia saneada con el esquema anterior.
3. Envía correo a un receptor y solicitudes de facturación a una cuenta de prueba.
4. Procesa una carga de trabajo antigua y otra nueva con el worker candidato.
5. Revierte el candidato y repite el inicio de sesión y la ruta de escritura.

La quinta prueba es la que se suele omitir. Los equipos prueban el despliegue hacia delante en la vista previa y presuponen que la reversión funcionará. Una base creada solo con el esquema más nuevo no demuestra que el código antiguo tolere el estado posterior a la migración. Conserva un fixture de la versión anterior, ejecuta la migración, despliega el código nuevo y después vuelve a desplegar el antiguo con ese fixture migrado.

Protege el acceso público a vistas previas con flujos de clientes realistas. Vercel ofrece opciones de protección, mientras Railway y Render permiten controlar el acceso mediante sus modelos de proyecto y la autenticación de la aplicación. El control de la plataforma no sustituye la autorización de la aplicación. Comprueba que un usuario normal de la vista previa no acceda a rutas administrativas ni a integraciones de producción.

El manual de recuperación debe caber en una pantalla

Durante una caída, el proveedor más seguro es aquel cuya secuencia de recuperación haya ensayado el operador real. Un manual debe nombrar pruebas y condiciones de parada, no decir «revertir si hace falta». Guarda este registro compacto en el repositorio y complétalo para cada versión de producción:

release: <git-sha>
previous: <known-good-deployment>
migration: <id-or-none>
compatible_with_previous_code: <yes-or-no>
secret_change: <name-or-none>
web: <deployment-id>
worker: <deployment-id>
recovery_owner: <person>

Cuando comienza el incidente, detén los despliegues automáticos de producción, conserva el despliegue fallido y sus registros, y averigua si cambiaron datos. Si la migración fue aditiva y todavía se acepta el secreto anterior, restaura web y worker como un solo conjunto. Comprueba el inicio de sesión, una lectura, una escritura, un trabajo en cola y el webhook de facturación. Observa los errores antes de declarar la recuperación.

Si la migración fue destructiva, deja de llamar reversión de código a la acción. Elige entre una corrección hacia delante, un parche de compatibilidad para la aplicación anterior o la recuperación de la base. Una corrección hacia delante suele conservar más datos. Restaurar la base puede estar justificado si continúa la corrupción, pero necesita un corte explícito y un plan para conciliar escrituras posteriores a la copia.

En Vercel, registra la dirección exacta del despliegue de producción y confirma el estado de reversión y del dominio. En Railway, registra cada despliegue de servicio porque la web y el worker pueden separarse. En Render, registra el despliegue objetivo, si la reversión salió del panel o de la API y qué grupos o discos siguen actuales.

Ensaya este proceso antes de cambiar de proveedor. Mide la recuperación y después abre una sesión existente y completa una escritura. Si la plataforma marca éxito y ese recorrido falla, añade el paso que falta al manual. Migrar de host no arreglará una dependencia desconocida.

Elige el proveedor después de mapear el sistema heredado

La elección es Vercel para el cambio más limpio de despliegue Next.js, Railway para un espacio compacto de servicios y base de datos, y Render para un entorno declarado de varios recursos con vistas previas muy fieles. Ese orden cambia si el código heredado usa un disco persistente, tareas de ejecución poco habituales, varios workers independientes o infraestructura manual fuera del proveedor.

Antes de decidir, mapea cinco elementos: procesos de ejecución, almacenes de datos, colas y tareas programadas, responsables de secretos y efectos externos. Marca qué objeto del proveedor controla cada uno y si su acción de reversión lo modifica. Cada celda vacía forma parte de tu plan de recuperación, no demuestra que la plataforma se encargue.

Un proyecto heredado generado por IA suele ocultar llamadas a la base en acciones del servidor, repetir lógica de autenticación y mezclar configuración de despliegue con código. FixMyMess puede diagnosticar esa base, reparar fallos de lógica y seguridad, refactorizarla y preparar el despliegue con verificación experta, pero la elección del proveedor aún necesita el límite de recuperación descrito aquí.

Haz un último experimento destructivo antes de aprobar: supone que el código nuevo lleva siete minutos publicado, los usuarios escribieron datos, cambió un secreto y el worker antiguo aún tiene trabajos. Pide al operador que recupere el servicio sin el desarrollador original. Elige el proveedor según la calidad de esa respuesta. Un botón rápido de Revertir solo resulta útil después de que la aplicación se haya ganado el derecho a volver atrás.