How to Deploy Next.js for Free — Vercel vs Netlify vs Railway

I'm Safdar Ali. You built a Next.js app — now you need it live without paying ₹5,000/month on day one. I host safdarali.in on Vercel's hobby tier. I've also deployed client MVPs on Netlify and full-stack demos on Railway. This deploy nextjs free guide compares free tiers honestly and gives copy-paste steps for each platform in 2026.

Free tier limits change — bookmark each provider's pricing page and set calendar reminders before client launches. A portfolio that exceeds function invocations because of a viral LinkedIn post is a good problem, but only if you know how to upgrade or add caching before the site returns 503. I configure budget alerts in Vercel and Railway when clients pay for Pro; on hobby projects I still check analytics monthly from Bengaluru.

I wrote this deploy nextjs free guide for developers in India who need a live URL this week, not a cloud architecture committee. Every path below assumes App Router and a GitHub repository — if you are still on Pages Router, the hosts still work, but migrate to app/ when you can so Server Actions and layouts match the docs you are reading in 2026.

Free tier comparison — Vercel vs Netlify vs Railway

*Railway's free tier model changes — check current credits on signup. Treat free tiers as learning and portfolio hosts, not unlimited production SaaS at scale.

Edge middleware and ISR behave differently per host — test your actual features on the platform you choose, not only hello-world. A project heavy on next/image and edge auth may feel identical on Vercel and Netlify until middleware latency or cold starts differ in production. Ship a preview URL, run Lighthouse, and click through auth flows before committing the client to a host for twelve months.

Latency from India matters for TTFB, not just deploy convenience. Vercel edge functions run close to users when you pick regions wisely; pair with Neon or Supabase in ap-south-1 when your audience is mostly domestic. Railway containers run in a region you choose at project creation — wrong region means Bengaluru users wait on US round trips for every API call. Netlify edge is solid for static assets; dynamic Next.js routes depend on their Node runtime location. None of this is fatal on free tiers, but it is worth five minutes in dashboard settings before you share a production URL with paying clients.

Deploy on Vercel — fastest path for Next.js

# 1. Push repo to GitHub
git init && git add . && git commit -m "Initial commit"
git remote add origin https://github.com/you/my-app.git
git push -u origin main

# 2. vercel.com → Import Project → select repo
# Framework preset: Next.js (auto-detected)
# Environment variables: add DATABASE_URL, etc.

# 3. CLI alternative
npm i -g vercel
vercel
vercel --prod

// BEFORE — no build script, deploy fails
// package.json missing "build": "next build"

// AFTER
{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

Vercel runs next build automatically. Connect custom domain in project settings — DNS A/CNAME from your registrar (Namecheap, GoDaddy, etc.).

Preview deployments per pull request are why I recommend Vercel to clients — designers comment on real URLs, not screenshots. Set Preview environment variables for staging API keys so test payments never hit Razorpay production. Production environment gets live keys only. I have seen interns copy production DATABASE_URL into preview and run seed scripts — use separate Neon branches and read-only credentials where possible.

Vercel Analytics and Speed Insights are optional but useful on hobby projects — I enable them on portfolios to catch regressions after image or font changes. Web Vitals data from real users beats guessing from localhost Lighthouse alone. Build caching on Vercel is automatic when package-lock.json is committed; do not delete lockfiles to fix npm warnings. Inconsistent installs cause ghost build failures that waste an evening. Set Node version in package.json engines or .nvmrc so local Node 22 matches CI Node 20 — version skew breaks native modules like sharp occasionally.

Deploy on Netlify — solid alternative with Git integration

# netlify.toml at repo root
[build]
  command = "npm run build"
  publish = ".next"

[[plugins]]
  package = "@netlify/plugin-nextjs"

# Or use OpenNext — follow Netlify Next.js runtime docs for App Router

# Netlify CLI
npm install -g netlify-cli
netlify login
netlify init
netlify deploy --prod

Set environment variables in Netlify UI → Site settings → Environment. For Server Actions and dynamic routes, ensure you use the official Next.js runtime plugin — static export alone will break API routes.

Netlify Forms and split testing are nice extras if you already host there — less reason to migrate a marketing site that uses them heavily. For App Router with Server Actions, verify the adapter version in release notes when upgrading Next.js — mismatched plugin versions cause obscure build failures that waste an evening in Bengaluru debugging CI logs.

Netlify split testing and branch deploys are underrated for marketing experiments — two hero variants without touching application code. If your client already pays for Netlify Pro for another property, consolidating there reduces invoice fragmentation. Migration to Vercel later is feasible — I have done it twice — but DNS cutover still needs a maintenance window and Search Console resubmission. Pick Netlify when the team already lives there; pick Vercel when Next.js is the only framework you ship and you want the path of least resistance from create-next-app to production URL.

Deploy on Railway — when you need app + database together

# Dockerfile approach (full control on Railway)
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npx prisma generate && npm run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/public ./public
COPY --from=builder /app/package.json ./
RUN npm ci --omit=dev
EXPOSE 3000
CMD ["npm", "start"]

# Railway dashboard:
# 1. New Project → Deploy from GitHub
# 2. Add PostgreSQL plugin → copy DATABASE_URL to service variables
# 3. Set start command: npm run start (after build)
# 4. Generate domain

Pair with my Prisma + PostgreSQL guide for migrations on deploy.

Long-running processes — background workers, cron, websocket servers — fit Railway's container model better than serverless timeouts on Vercel hobby. If your MVP needs a daily report job, Railway cron or a small worker service colocated with Postgres is simpler than stitching Vercel cron plus external queue on day one. You pay in complexity when you outgrow free credits, but day-one shipping wins consulting engagements.

Railway Postgres plugin copies DATABASE_URL into your service automatically — wire the same variable name your Prisma schema expects. Health checks on Railway should hit a lightweight route like /api/health, not a page that runs database queries on every ping. Watch credit burn when containers never sleep on free tiers; scale down preview environments when the client demo ends. For production SaaS I often still split Vercel frontend and Neon database, but Railway remains the fastest teaching path when interns need one dashboard to learn deploy end to end.

Environment variables — never commit secrets

# .env.local (gitignored)
DATABASE_URL="postgresql://..."
NEXTAUTH_SECRET="generate-with-openssl"

# Set same keys in Vercel / Netlify / Railway dashboards
# Production vs Preview vs Development scopes

Generate secrets with openssl rand -base64 32 — never reuse passwords from other projects. NEXTAUTH_SECRET, CRON_SECRET, and webhook signing keys each get unique values. Document required env vars in README so open-source contributors do not DM you at midnight asking why auth fails. I keep a .env.example with empty keys committed to Git — never real values.

Vercel encrypts env vars at rest; rotation means update dashboard, redeploy, and invalidate old sessions if you rotated auth secrets. Railway and Netlify follow the same pattern. For Razorpay and Stripe, use test keys in Preview and Production keys only in Production scope — I label keys with comments in the dashboard because similar-looking sk_test and sk_live strings cause expensive mistakes when tired.

Build pipeline — what runs before your site goes live

A reliable deploy nextjs free flow is: install dependencies, prisma generate, prisma migrate deploy, next build, promote. Skipping migrate deploy ships code that expects columns your database does not have — 500 errors on first login. Add migrate deploy to CI even on hobby tiers; Vercel lets you override the build command to prepend migration steps.

// package.json — scripts I use on Prisma projects
{
  "scripts": {
    "build": "prisma generate && prisma migrate deploy && next build",
    "postinstall": "prisma generate"
  }
}

// Vercel: set Install Command default, Build Command = npm run build
// Netlify: same in netlify.toml [build] command
// Railway: build stage in Dockerfile runs migrate before next build

Typecheck and lint in CI before deploy — vercel build runs next build which catches TypeScript errors, but eslint in CI catches issues earlier. I add a GitHub Action that runs npm run lint on pull requests so broken imports never reach main. Preview deploys then become visual QA, not the first line of defense against syntax errors.

BEFORE / AFTER — manual FTP vs Git deploy

// BEFORE — build locally, upload .next via FTP (broken ISR, no edge)
npm run build
# upload folder manually → cache stale, middleware missing

// AFTER — git push triggers CI build on host
git push origin main
# host runs: install → prisma migrate deploy → next build → promote

Preview deployments — the free feature I use every PR

All three hosts can build a unique URL per pull request. That is how I share work-in-progress with clients in Bengaluru without merging to main. Vercel and Netlify make this automatic on GitHub PRs; Railway can wire preview environments with a bit more config.

# Typical PR flow (Vercel / Netlify)
# 1. Open PR on GitHub
# 2. Bot comments: "Preview ready at https://my-app-git-feature-xxx.vercel.app"
# 3. Client reviews on phone — same build as production, different env vars

# Use Preview scope for staging API keys
STRIPE_SECRET_KEY=sk_test_...
DATABASE_URL=postgresql://staging...

Never point preview deploys at production databases. I duplicate Neon branches or use a separate Railway Postgres instance for staging — five minutes of setup prevents a demo from deleting real user rows.

Common deploy failures — and fixes

// Build fails: "Module not found: @prisma/client"
// Fix: add postinstall or build step
"scripts": {
  "postinstall": "prisma generate",
  "build": "prisma generate && next build"
}

// Runtime: middleware edge size exceeded
// Fix: move heavy logic out of middleware — see middleware guide

// Images 400 from CMS domain
// Fix: remotePatterns in next.config.ts

Read my Next.js middleware guide before stuffing auth database lookups into edge middleware on Vercel — that pattern fails cold starts and burns function duration on the free tier.

Out of memory during next build usually means importing something huge on the server — accidental fs read of a giant JSON file, or bundling onnx in a marketing page. Check analyze output. Sharp image errors on M1 Macs building in CI sometimes need optionalDependencies pinned — search the exact error string before disabling image optimization entirely.

404 on dynamic routes after deploy often means output: export was enabled by mistake — App Router API routes and Server Actions require server output. Another culprit is missing trailingSlash config mismatch between local and host. Compare next.config.ts between environments line by line when routes work locally but fail in production.

Which I pick for what in 2026

Portfolio, blog, marketing site: Vercel hobby — zero config, preview URLs per PR. Client already on Netlify: stay, use Next plugin. MVP with Postgres + background jobs: Railway or Vercel + Neon. Do not pay for hosting until traffic or compliance demands it — free tiers got me through my first two years of public work in India.

After deploy, run image and perf checks from my image optimization guide and performance case study.

Ship today, optimize tomorrow

The biggest mistake is not choosing Vercel vs Netlify — it is never deploying. Push to GitHub, connect a host, add your domain, share the URL on LinkedIn. You can migrate hosts later; you cannot get feedback on localhost.

Free tiers have limits — build minutes, bandwidth, serverless duration. For a portfolio and early MVP that is plenty. When a client site hits real traffic, upgrade one tier on Vercel or add a CDN in front — still cheaper than premature AWS complexity. I have migrated two client sites from Netlify to Vercel without rewriting app code — only config files changed. Host choice is not marriage.

Custom domain on a .in or .com from Namecheap takes 24–48 hours for DNS propagation. Point apex with A record or CNAME www to your host, enable HTTPS (automatic on all three). Add www → non-www redirect in host settings to avoid duplicate SEO. Then submit the sitemap in Google Search Console — deploy is not done until Google can crawl production.

When traffic outgrows free tiers, upgrade one step at a time. Vercel Pro unlocks team seats and higher limits; Neon scales database compute independently; Railway usage-based billing grows with containers. You do not need AWS on day one — I have clients on hobby plus paid database tiers handling thousands of daily users. Monitor function duration and database connections before rewriting architecture. Premature Kubernetes is a tax, not a badge.

deploy nextjs free takeaway: push to Git, connect host, set env vars with scopes, run migrations in build, test preview URLs on real phones, add custom domain, submit sitemap. Ship this weekend from Bengaluru — your portfolio on localhost helps nobody hire you. Host migration is reversible; delaying launch is not.

Related: middleware guide, projects, contact.