Viniendo de Vercel
Vercel es excelente para frontends y funciones serverless. Un worker, un bot, una cola o cualquier cosa que necesite correr de forma continua necesita otro tipo de hospedaje.
Por qué los equipos buscan otra opción
Vercel está construido alrededor de funciones: tu código corre por solicitud, por un tiempo limitado, y luego se detiene. Esa es la forma correcta para un frontend y la mayoría de las API. Es la forma incorrecta para un worker en segundo plano, un bot que mantiene una conexión persistente, un consumidor de colas, una tarea cron más larga que el límite de tiempo de una función, o un servidor WebSocket. Las propias guías de Vercel para correr Docker o un proceso de larga duración en la plataforma describen mover esa parte del trabajo a las colas o workflows de Vercel, que es un modelo de programación distinto al de un proceso de servidor normal.
Las bases de datos funcionan igual en Vercel: no hay ninguna base de datos que Vercel corra por sí misma. Postgres, Redis y el resto vienen del Vercel Marketplace, que conecta tu proyecto con un proveedor externo como Neon o Upstash e inyecta las credenciales. Los respaldos, la restauración a un punto en el tiempo y la disponibilidad de la base de datos son responsabilidad de ese proveedor, no de Vercel.
Railyard es un servidor Linux normal en tu propia cuenta de nube. Todo lo que corre como un proceso, sea o no el modelo de Vercel, corre ahí: un worker, un bot, un consumidor de colas, una tarea cron de cualquier duración, Postgres o Redis con los respaldos programados propios de Railyard.
Lo que te acompaña
- El frontend se queda donde ya funciona bien, incluido en Vercel. Esto es sobre las partes de la app que necesitan un servidor, no una migración completa.
- Tu API o backend, construido desde su Dockerfile o detectado desde el repositorio.
- Workers en segundo plano, consumidores de colas y tareas cron, como procesos de larga duración en vez de funciones con un límite de tiempo.
- Un Postgres, MySQL o Redis administrado, aprovisionado en el servidor en vez de a través de una integración del Marketplace.
La migración
- Conecta un servidor: aprovisionado por Railyard en tu propia cuenta de DigitalOcean, Hetzner, Vultr o AWS, o uno que ya tengas.
- Agrega el repositorio de la parte que necesita un servidor real: la API, el worker, el bot. Railyard lo construye desde el Dockerfile o detecta el framework.
- Conecta una base de datos si la app la necesita, con los respaldos programados incluidos.
- Apunta el frontend a la URL del nuevo backend, sea que el frontend se quede en Vercel o también se mude.
- Despliega, revisa los registros y confirma que el proceso de larga duración realmente sigue corriendo.
Lo que cambia
Un proceso que corre de forma continua en vez de esperar una solicitud, una base de datos que Railyard respalda por sí mismo, y un servidor al que puedes entrar por SSH cuando algo necesita una mirada más de cerca.