Coming from Vercel
Vercel is excellent for frontends and serverless functions. A worker, a bot, a queue or anything that needs to run continuously needs a different kind of host.
Why teams look elsewhere
Vercel is built around functions: your code runs on request, for a limited time, then stops. That’s the right shape for a frontend and most APIs. It’s the wrong shape for a background worker, a bot that holds a persistent connection, a queue consumer, a cron job that runs longer than a function’s time limit, or a WebSocket server. Vercel’s own guides for running Docker or a long-running process on the platform describe moving that part of the work to Vercel’s queues or workflows, which is a different programming model than a normal server process.
Databases on Vercel work the same way: there’s no database Vercel runs itself. Postgres, Redis and the rest come from the Vercel Marketplace, which connects your project to a separate provider like Neon or Upstash and injects the credentials. Backups, point-in-time restore and the database’s own uptime are that provider’s responsibility, not Vercel’s.
Railyard is a normal Linux server in your own cloud account. Anything that runs as a process, Vercel’s model or not, runs there: a worker, a bot, a queue consumer, a cron job of any length, Postgres or Redis with Railyard’s own scheduled backups.
What comes with you
- The frontend stays wherever it already works well, including on Vercel. This is about the parts of the app that need a server, not a wholesale move.
- Your API or backend, built from its Dockerfile or detected from the repo.
- Background workers, queue consumers and cron jobs, as long-running processes instead of functions with a time limit.
- A managed Postgres, MySQL or Redis, provisioned on the server instead of through a Marketplace integration.
The move
- Attach a server: provisioned by Railyard in your own DigitalOcean, Hetzner, Vultr or AWS account, or one you already have.
- Add the repo for the part that needs a real server: the API, the worker, the bot. Railyard builds it from the Dockerfile or detects the framework.
- Attach a database if the app needs one, with scheduled backups included.
- Point the frontend at the new backend’s URL, whether the frontend stays on Vercel or moves too.
- Deploy, check logs, and confirm the long-running process actually stays running.
What’s different
A process that runs continuously instead of waiting for a request, a database Railyard backs up itself, and a server you can SSH into when something needs a closer look.