Vercel is built around requests: a deploy pipeline, edge distribution, and functions that wake up, answer, and stop. Railway is built around processes that stay alive — workers, queues, databases. Most projects want both, and the friction people report with either is almost always a piece of work sitting on the wrong side of that line.
The line between them
Does this thing wake up to answer something, or does it need to stay running?
Rendering a page, handling an API call, processing a webhook — request-shaped. Serverless is excellent at these, and the deployment story around them is genuinely best-in-class.
A queue consumer, a long transcoding job, a websocket server, a scheduled process that holds state between runs — process-shaped. Trying to express these as functions is where people start describing serverless as painful, and they are right, but the pain is a category error rather than a platform flaw.
Side by side
| Vercel | Railway | |
|---|---|---|
| Model | Request / serverless | Long-running processes |
| Frontend deploys | Excellent | Workable |
| Preview per branch | Built in | Available |
| Background workers | Awkward | Natural |
| Databases alongside | External | Same project |
| Execution ceiling | Plan-dependent, often short | Runs until you stop it |
| Cost shape | Usage and bandwidth | Resources while running |
| Cold starts | A consideration | Not really |
The ceiling that breaks AI features
This is the specific thing worth knowing before you build, because it produces a bug that looks like your fault.
A function calls a language model. The model takes longer than the platform’s execution limit. The request gets cut. The caller frequently sees a generic failure rather than a timeout, so it reads as a bug in your own logic and you go looking in entirely the wrong place. On a busy product this is silent and intermittent, which is the worst combination.
The fix is architectural, not a configuration change. Anything that can exceed the ceiling has to stop being a request: one endpoint accepts the work and returns an identifier, a worker does the work, the client polls for the result. Raising the timeout just postpones it, because model latency is not something you control.
That worker is exactly the shape of thing Railway is for. This is the most common reason a project ends up wanting both.
What Vercel is genuinely excellent at
Deployments. A push produces a build, a preview URL, and a production release with a rollback, and that whole loop is fast enough that you stop thinking about it. For a frontend, that is most of the value of a platform.
Per-branch previews in particular change how review works. Sending someone a URL rather than asking them to run your branch is a small thing that compounds.
Things that have bitten me
Not arguments against the platform, just the sharp edges worth knowing.
Client-side environment variables inline at build time. Anything exposed to the browser is baked in when you build, not read at runtime. Changing it in a dashboard does nothing until you rebuild. Every team learns this once, usually mid-incident.
The CLI can report success on a failed deploy, and failure on one that shipped. Do not trust the command output as your verification. Fetch a version endpoint or a content-hashed asset from the live URL and confirm the new code is actually serving. This has cost me real time in both directions.
Deploy order matters across a boundary. If a frontend release expects a new backend signature, ship the backend first, or you leave a window where the app calls something that does not exist.
Commit author can block a deploy. On some team configurations, a push from an unrecognised git author is silently rejected for auto-deploy. If pushes stop deploying and nothing errors, check this before anything else.
How to split
- Frontend and request-shaped APIs on the serverless side.
- Anything with an unbounded runtime — model calls, transcoding, batch jobs — on a process host.
- Queues and workers where processes live.
- Databases wherever they are managed properly; co-locating with workers reduces hops.
- Verify every deploy against the live URL, whichever platform, because both CLIs will lie to you eventually.
The overhead of running two platforms is a second deploy and a second dashboard. The overhead of forcing process-shaped work into a request model is every sprint, forever.
FAQ
Vercel or Railway?
Vercel for frontend and request-shaped work; Railway for long-running processes, workers, queues, and co-located databases.
Biggest serverless limitation?
The execution ceiling. Long model calls get cut and often surface as generic errors, so they read as your bug.
Can I run background jobs on Vercel?
Scheduled functions handle periodic work, but a genuinely long-running stateful worker belongs elsewhere.
Do I have to choose?
No. Splitting is common and usually correct: frontend one side, workers and databases the other.
Related: Supabase edge functions vs Vercel functions and Astro vs Next.js.