How to migrate from Vercel to Railway (2026)
Developers rarely leave Vercel because it stopped working — they leave because their app changed shape. A project that started as a static frontend grows a real backend: a database, WebSockets, a queue worker, a process that needs to run all night. That's the point where Vercel's serverless category runs out of road and Railway's always-on services start making sense. This guide covers the honest decision first — including when you shouldn't migrate — and then the migration itself, step by step.
Affiliate disclosure: Some links on this page are affiliate links to hosting providers we cover. If you sign up through them, I may earn a small commission at no extra cost to you. This never affects which hosts are covered or how they're ranked.
Why developers make this move
Not because Vercel is bad — it's excellent at what it does. The move happens when one of these outgrows what serverless offers:
- You need an always-on backend. WebSockets, background workers, scheduled jobs, long-running processes — serverless functions time out; a Railway service just keeps running.
- You want the database on the same platform. Vercel pairs with external database providers; Railway provisions Postgres, MySQL, or Redis next to your app on one bill.
- The pricing shape stopped fitting. Per-seat plans plus metered usage suit some teams; others prefer paying for the resources their services actually consume. Neither is universally cheaper — but one will match your situation better.
How Railway differs — and what that means for the migration
Vercel and Railway aren't two flavors of the same thing; they're different categories. Vercel builds your frontend and runs backend code as short-lived serverless and edge functions, with Next.js as its native framework. Railway runs long-running services — real processes that start once and keep serving — with databases as first-class citizens beside them.
That category difference is the migration: your frontend build mostly moves as-is, but backend code changes shape. Serverless functions become routes in a persistent server, environment config moves platforms, and DNS cuts over at the end. None of it is exotic — but it's a re-architecture of the backend, not a settings change.
Should you actually migrate?
Honest gate before any steps — for plenty of readers the right answer is no:
Stay on Vercel if…
You're running a Next.js app that's working well, or a frontend whose backend needs fit comfortably in serverless functions. Migrating buys you nothing but work — Vercel is the best home for that shape of app.
Pick a static host instead if…
Your goal is just a cheaper home for a static or JAMstack site. Railway is built for running services — paying for an always-on process to serve static files is the wrong shape. Netlify or Cloudflare Pages fit that need better — see the full alternatives guide.
Migrate to Railway if…
Your app needs an always-on backend, a bundled database, or both — the full-stack shape from the sections above. That's Railway's home turf. (Also weighing Render for the same job? That comparison is coming in Railway vs Render.)
The migration, step by step
These steps are deliberately general — platform UIs and CLI syntax change, so treat this as the map and Railway's current docs as the turn-by-turn directions.
1. Create a Railway project and connect your repo
Sign up on Railway , create a project, and connect the same Git repository Vercel deploys from. Railway builds and deploys from pushes, so the Git-driven workflow you're used to carries over.
2. Recreate your environment variables
Copy each variable from your Vercel project settings into the Railway service's variables. Audit your code for Vercel-specific variables (the VERCEL_-prefixed ones the platform injects) — anything that reads them needs an equivalent or a fallback.
3. Provision a database, if you need one
Add Postgres, MySQL, or Redis to the project; Railway exposes the connection details to your service as variables. If you were using an external database provider with Vercel, you can also just keep it — point the same connection string at your Railway service and skip this step entirely.
4. Turn your backend into a long-running server
The conceptual heart of the migration. Standalone serverless functions become routes in a persistent server app (Express, Fastify, or your preference) that listens on the port the platform provides via the PORT environment variable. Next.js apps run their own server, so API routes mostly come along for free.
Set the build and start commands for your service accordingly (build the frontend, start the server). The exact configuration fields are in Railway's docs.
5. Sort out static and SPA routing
If your React frontend is a SPA served by your own server, the classic refresh-404 applies here too: your server needs a fallback that serves index.html for unknown routes. The why and the fixes are covered in our React Router 404 guide.
6. Add your custom domain
Test everything on the platform-generated domain first. Then add your custom domain to the Railway service, create the DNS record it asks for, and let SSL provision. Don't touch your live DNS yet — that's the last step.
7. Test, then cut over DNS
With the Railway deployment fully working on its own URL — routes, API, database, auth callbacks — switch your domain's DNS to Railway. Keep the Vercel deployment alive until propagation settles and you've watched the new one handle real traffic; it's your instant rollback if something surfaces. Lowering the DNS TTL a day before the switch shortens the in-between window.
What to watch after moving
- Usage-based billing needs watching. Your bill now tracks what your services consume. Set up spend alerts early, and check the first few invoices against expectations rather than assuming.
- There's no permanent free tier. Railway offers a trial credit, then you pay for what runs — different from parking a hobby project on a free tier indefinitely.
- Always-on cuts both ways. No cold starts and no function timeouts — but you pay for the process during idle hours too. For steady traffic that trade is usually favorable; for a rarely-visited side project it may not be.
Second-guessing the destination rather than the move? The full React hosting roundup lays out the whole landscape.
Frequently asked questions
Is Railway cheaper than Vercel?
It depends on the shape of your app, not on a universal answer. Railway bills for the resources your services actually consume; Vercel prices per team seat plus metered usage. A small always-on full-stack app often costs less on Railway than the equivalent Vercel plan plus an external database — but a mostly-static site can be cheaper on Vercel's or Netlify's free tiers than on any usage-billed platform. Model your own traffic against both pricing pages before deciding.
Can I run my Next.js app on Railway?
Yes — Next.js runs on Railway as a regular long-running Node server. The caveat is that Vercel-specific conveniences (edge middleware behavior, image optimization, the smoothest ISR experience) are at their best on Vercel, so expect some configuration work and check Railway's current docs for Next.js specifics. If Next.js on Vercel is working well for you, that alone usually isn't a reason to move.
Do I need to rewrite my serverless functions?
Usually yes, and it's the main real work of this migration. Standalone serverless functions (like a Vite SPA with an api/ directory on Vercel) become routes in a persistent server app — Express, Fastify, or similar — on Railway. Next.js API routes are the exception: they travel with the Next server and mostly keep working. The upside of the rewrite is capabilities serverless couldn't give you: WebSockets, background jobs, and processes that keep running.
Can I keep my frontend on Vercel and move only the backend to Railway?
Yes, and it's a legitimate end-state, not a compromise. Many teams serve the static or Next.js frontend from Vercel and run the API, workers, and database on Railway, connected over HTTPS. You manage two platforms instead of one, but each part runs where its category is strongest.
When you're ready to run the migration, start a Railway project and follow the steps above in order.
Written by Andrius Vaitiekūnas
Developer who deploys and hosts React apps. I write the deployment guides I wish existed — tested on real projects, hard parts included.
Related guides
Deploy a React + Express app to Railway
A complete walkthrough for deploying React and Express as one app: project structure, serving the build from Express, the PORT change everyone forgets, Postgres, a custom domain — and when Railway is the wrong choice.
Railway vs Render (2026): which for your full-stack React app?
Railway and Render both host what serverless platforms can't — full-stack apps with an always-on backend and database. The honest difference is pricing philosophy: usage-based vs per-instance. An even-handed comparison.
Best Vercel alternatives (2026): 7 options for React devs
Vercel is excellent — but not right for every project. Seven honest alternatives organized by what you actually need: commercial-friendly free tiers, a real backend with a database, or a managed server with predictable pricing.