Railway vs Vercel for Beginners

Vercel is a frontend cloud optimized for Jamstack and Next.js. It builds your site, serves static assets from a global CDN, and runs serverless functions for API routes with strict time and memory limits. It is not designed to run a Django process listening on a port 24/7.

Railway is a general-purpose app host. It builds containers from your GitHub repo, runs long-lived processes (gunicorn, node server.js, uvicorn), and offers add-on databases like PostgreSQL. It behaves more like a traditional server — without you managing Linux yourself.

Both connect to GitHub and redeploy on push. Both have dashboards for environment variables. The difference is what kind of process they expect to run after the build finishes.

Neither replaces the other for every app. Many production teams use both simultaneously.

Next.js is the clearest Vercel case. Framework detection, incremental static regeneration, middleware, and edge functions are first-class. If your AI tool generated a create-next-app project, start with Vercel unless you have a strong reason not to.

Static React + Vite SPAs also deploy cleanly on Vercel. Build to dist/, serve from CDN — fast and cheap for frontend-only projects.

Marketing sites, landing pages, documentation, and portfolios fit Vercel well. Low operational overhead, automatic HTTPS, preview URLs per branch.

Choose Vercel when your backend logic lives inside Next.js API routes or Route Handlers and stays within serverless limits (short requests, no WebSocket servers, no heavy background workers).

• Next.js (App Router or Pages Router)
• React + Vite static SPAs
• Frontend-heavy apps with light serverless APIs
• You want the fastest path from GitHub to a public URL for a JS frontend

Django is the canonical Railway app. You need gunicorn running continuously, PostgreSQL, migrations, and static files via WhiteNoise. Railway provides DATABASE_URL when you add Postgres — Vercel does not natively host this pattern for beginners.

FastAPI, Flask, Express APIs, and custom Node servers that listen on a PORT variable belong on Railway (or similar: Render, Fly.io). These are persistent processes, not ephemeral serverless invocations.

Background workers, cron jobs, queue consumers, and WebSocket servers need a always-on host. Railway supports multiple services in one project — web + worker + database.

Choose Railway when your repo root has manage.py, a Procfile with gunicorn, or a main.py running uvicorn — not when it only has a Vite frontend.

• Django, FastAPI, Flask Python backends
• PostgreSQL or Redis in the same project
• Long-running Node or Python servers
• Monorepo where the primary app is a backend API

The most common production pattern for AI-built full-stack apps: Vercel hosts the React or Next.js frontend; Railway hosts the Django/FastAPI API and PostgreSQL database. The frontend reads import.meta.env.VITE_API_URL or NEXT_PUBLIC_API_URL pointing at the Railway URL.

Monorepo layout often looks like /frontend and /backend folders. Create two deploy projects — one on Vercel (root: frontend), one on Railway (root: backend). Each has its own environment variables and build commands.

Single-framework full-stack on Next.js can stay entirely on Vercel if database access uses a hosted service (Supabase, PlanetScale, Neon) via server-side env vars — no separate Railway service needed.

Single-repo Django with templates (no separate SPA) can live entirely on Railway. You do not need Vercel at all for server-rendered Django HTML.

Avoid deploying the same Python backend to both platforms 'just in case' — pick one API host and one frontend host. Double deploys double confusion.

Free tiers change. Do not build your business plan around today's limits — check vercel.com/pricing and railway.com/pricing before you launch.

Vercel Hobby (free) suits personal and small projects with bandwidth and serverless execution caps. Commercial use may require a paid plan depending on current terms. Preview deployments and HTTPS are included.

Railway historically offered trial credits for new accounts rather than unlimited forever-free hosting. Small apps with one web service and a modest Postgres instance often cost a few dollars per month after credits expire. Budget accordingly — 'free' may mean 'cheap to start,' not 'free forever at scale.'

Database storage and egress add cost on both platforms as you grow. For learning and MVPs, both are affordable. For high-traffic production, plan paid tiers early.

Do not choose a host only because it is free. Choose because your stack fits. A wrong host costs more in debugging time than a $5 monthly bill.

Start here: open your repo root. Do you see manage.py or a Python WSGI/ASGI app as the main entry point? If yes → Railway for that service. Skip Vercel for the Python part.

Do you see next in package.json with an app/ or pages/ directory as the main product? If yes → Vercel for that service. Add Railway only if you also have a separate Python backend folder.

Do you see only vite.config.ts and a React src/ folder with no backend in the repo? If yes → Vercel or Netlify for static deploy. Add Railway later only when you deploy a separate API.

Does your app need PostgreSQL that you manage yourself (not Supabase hosted)? If yes → Railway (or Render) for the database plus backend. Vercel connects to external databases but does not provision Postgres for you.

Still unsure? Describe your stack to your AI editor: 'Given this package.json and folder structure, should I use Vercel, Railway, or both?' Paste the answer into a launch checklist before signing up.

Django on Vercel: build may succeed but requests fail or timeout because Vercel expects serverless handlers, not gunicorn. Fix: move Django to Railway.

DisallowedHost on Railway: you deployed Django correctly but forgot ALLOWED_HOSTS — not a platform mismatch, but beginners often blame the host. Add your *.railway.app domain.

Next.js API routes with 10-second timeouts: heavy ML inference or long DB migrations in a serverless function exceed Vercel limits. Move heavy work to Railway background worker or optimize.

Vite SPA on Railway without a static server config: Railway expects a process. A raw dist/ folder needs npx serve or similar — easier to use Vercel/Netlify for pure static.

CORS errors after split deploy: frontend on Vercel, API on Railway, but backend only allows localhost. Update CORS allowed origins to your Vercel domain.

SQLite in production on Railway: containers restart and lose local SQLite files. Use Railway PostgreSQL instead.

Deploy order matters: backend first. Get Railway API URL live, run migrations, test /health or /api endpoint with curl. Then set VITE_API_URL or NEXT_PUBLIC_API_URL on Vercel and deploy the frontend.

Keep environment variables separated. Railway holds DATABASE_URL, SECRET_KEY, Django settings. Vercel holds public frontend vars and any Next.js server secrets for server components.

Custom domains: api.yourdomain.com on Railway, yourdomain.com on Vercel. Update CORS, ALLOWED_HOSTS, and OAuth callbacks on both sides when domains change.

One GitHub repo, two deploy hooks — totally normal. Each platform watches the same repo but different root directories or branch filters if configured.