Next.js Hosting in 2026 — Vercel, Cloudflare Pages, or Your Own VPS?

Verdict at the top: For a typical small-to-medium Next.js project, the honest first answer is: don't host it yourself. Vercel's free tier or Cloudflare Pages handles 95% of Next.js workloads better than you can on a VPS, with zero operational overhead. Self-host on a Domain India VPS when (a) you've genuinely outgrown the free tiers, (b) you have data-residency constraints (DPDPA-driven hosting in India), (c) you need to keep frontend + Node backend + database on the same machine for cost, or (d) you're already running other services on the box and want to consolidate. For pure-static Next.js sites, cPanel/DirectAdmin works fine — output: 'export', upload out/ to public_html/, done. This guide covers all four paths honestly.

The four paths — when each is right

The decision lands on the question: does your app need long-running Node-server features (SSR, API routes, middleware, ISR)?

• No — static export is great; pick whichever host you already use.
• Yes — pick one of Vercel / Pages / VPS. Don't try to make it work on shared hosting.

Latency — the part most "X vs Y" articles fudge

For an Indian audience, latency from CDN edge to user matters. Rough numbers (typical Indian broadband to nearest PoP):

Takeaway for Indian-audience sites: Cloudflare Pages and Cloudflare-fronted VPS are tied for best Indian latency. Vercel Hobby (free) is significantly worse for India because Mumbai edge is Pro-tier only. If your audience is India-heavy and you want to use Vercel, factor in the Pro upgrade.

Path 1 — Vercel (the default)

Best when: you want zero ops overhead, your project is Next.js-centric, and you can stomach the pricing model.

The good: instant deploys from git, first-class Next.js features (every Next.js feature works because Vercel made the framework), built-in image optimisation, edge functions, free SSL, automatic preview deploys per PR, free analytics.

The catches:

• Hobby (free) tier excludes commercial use. If you're shipping a product, you're technically required to be on Pro ($20/mo per user, ~₹1,700). Vercel's enforcement is light-touch but the licence is clear.
• No India edge on Hobby. Mumbai edge region is Pro-only. Free-tier Indian users get routed via Singapore or US West.
• Bandwidth pricing is the gotcha. Pro includes 1 TB/month; overage is $0.15/GB. A medium-traffic site can hit thousands of dollars/year if it goes viral.
• Vendor lock-in is real. Vercel-specific features (ISR On-demand, Edge Config, Vercel KV) tie your app to their platform. Migrating later is painful.

Setup:

npm install -g vercel
cd my-next-app
vercel                 # interactive setup
vercel --prod          # deploy production

That's it. Push to git → auto-deploy. Custom domain via Vercel's dashboard.

When to graduate off Vercel: when bandwidth bills exceed ~$200/month, when you need data residency in India (DPDPA), when you want to colocate with your own backend services, or when ops capacity to self-host is no longer the bottleneck.

Path 2 — Cloudflare Pages

Best when: you want low-cost India-edge hosting and your Next.js app fits within Cloudflare's runtime constraints.

The good: Cloudflare's full India PoP coverage (BOM, MAA, DEL, BLR, HYD, CCU); free tier includes unlimited bandwidth, unlimited requests, build minutes, custom domains; tight integration with Workers, D1, R2, KV.

The catches:

• Edge runtime, not Node.js runtime. Many npm packages assume Node-specific APIs (fs, full Buffer, native modules) — these don't work. Common packages that break: image-processing libs (sharp), some ORMs, anything using child_process.
• Less battle-tested for full Next.js feature set than Vercel. ISR, complex SSR with streaming, App Router edge cases sometimes need workarounds.
• Build limits on free tier: 500 builds/month, 20 minutes per build. Plenty for most projects.
• Bandwidth to your own origin, when needed, costs nothing — uniquely good story.

Setup: connect Pages to your GitHub repo, choose Next.js framework preset, deploy. Auto-deploy on push.

For Next.js apps that primarily use SSG with a few API routes, Cloudflare Pages is excellent and free. For apps using complex middleware, image optimisation, or non-edge-compatible packages, Vercel is the safer bet.

Path 3 — Domain India VPS (self-host)

Best when: you want infrastructure control, need data residency in India (or in EU under Hetzner), have multiple services to colocate, or want a fixed monthly cost regardless of traffic.

Build for production

Configure next.config.js for standalone output:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
  // If using next/image with non-localhost domains:
  images: {
    remotePatterns: [
      { protocol: 'https', hostname: 'cdn.yourdomain.com' },
    ],
  },
};

module.exports = nextConfig;

Build locally or in CI:

npm install --legacy-peer-deps     # only if you have peer-dep conflicts
npm run build

Standalone output structure:

.next/standalone/server.js        ← the entry point
.next/standalone/.next/...
.next/standalone/package.json
.next/static/                     ← copy alongside
public/                           ← copy alongside

Deploy package — what to ship

# On dev machine, build then copy these to VPS
rsync -avz --delete .next/standalone/ user@vps:/opt/myapp/
rsync -avz --delete .next/static/ user@vps:/opt/myapp/.next/static/
rsync -avz --delete public/ user@vps:/opt/myapp/public/

Run via systemd

/etc/systemd/system/myapp.service:

[Unit]
Description=My Next.js App
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
Environment=HOSTNAME=0.0.0.0
ExecStart=/usr/bin/node server.js
Restart=on-failure
User=myapp
Group=myapp

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now myapp
sudo systemctl status myapp
sudo journalctl -u myapp -f       # tail logs

systemd is the right answer in 2026 — PM2 was popular but adds complexity for no real benefit on a single-host setup.

Reverse proxy with nginx

/etc/nginx/sites-available/myapp:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }

    location /_next/static/ {
        alias /opt/myapp/.next/static/;
        expires 365d;
        access_log off;
        add_header Cache-Control "public, immutable";
    }
}

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Or skip nginx and use Caddy, which auto-handles SSL via Let's Encrypt:

yourdomain.com {
    reverse_proxy 127.0.0.1:3000
    handle_path /_next/static/* {
        root * /opt/myapp/.next/static
        file_server
    }
}

For most VPS deployments, Caddy is genuinely simpler than nginx + certbot.

Build memory — the most common deploy gotcha

Next.js builds are memory-hungry. On VPS Starter (2 GB RAM), a medium-sized Next.js app can OOM during npm run build. Symptoms:

<--- Last few GCs --->
[12345:0x...] FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Two fixes:

1. Build elsewhere, deploy artefacts. Run npm run build in CI (GitHub Actions) or on your laptop, then rsync the standalone output. Most-recommended pattern.
2. Add swap on the VPS if you must build on the box:

```bash

sudo fallocate -l 4G /swapfile

sudo chmod 600 /swapfile

sudo mkswap /swapfile

sudo swapon /swapfile

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

```

1. Bump Node's heap limit (less reliable):

```bash

NODE_OPTIONS='--max-old-space-size=2048' npm run build

```

If your app build needs > 4 GB on a VPS Starter, upgrade to VPS Basic (4 GB RAM) — or build in CI.

Path 4 — Static export to Domain India shared cPanel/DirectAdmin

Best when: your Next.js app is genuinely static (no API routes, no SSR, no middleware), and you already have shared hosting at Domain India.

// next.config.js
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,    // built-in optimiser disabled for static export
  },
  trailingSlash: true,    // generates /about/index.html
};
module.exports = nextConfig;

npm run build
# Creates out/ directory with static HTML/CSS/JS

Upload out/ contents to public_html/ via cPanel File Manager, FTP, or GitHub Actions → cPanel.

For clean URLs, drop a .htaccess in public_html/:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1/index.html [L]

What you lose on static export:

• API routes (pages/api/*, app/api/*) — they don't exist; you'll need a separate backend or external service.
• SSR (getServerSideProps) — pages are fully pre-rendered at build time.
• ISR (revalidate in getStaticProps) — same; no runtime regeneration.
• Image optimisation via next/image — served as-is unless you use a third-party loader (Cloudinary, imgix).
• Middleware — edge functions don't run.
• Dynamic routes that can't be enumerated at build time — /users/[id] with arbitrary IDs needs SSR.

If your app is a marketing site, blog, documentation, or portfolio with no user-specific server-side rendering, static export is excellent — fast, cheap, no operational overhead.

ISR — the feature that bites people

Incremental Static Regeneration is genuinely useful: pre-render at build time, regenerate on a schedule (or on-demand). But it has hosting-dependent gotchas:

On Vercel: ISR works out of the box. Revalidate triggers on the next request after the TTL expires.

On Cloudflare Pages: ISR support is partial. Time-based revalidate works; on-demand revalidate via revalidatePath requires Workers + D1 setup.

On a VPS: ISR works, but be aware:

• Revalidation writes to disk under .next/cache/. Make sure your filesystem allows writes (it does on standard VPS, but read-only-rootfs deployments break this).
• Multiple Next.js instances behind a load balancer don't share cache by default — each instance regenerates independently. Use shared cache (Redis adapter for Next.js cache) for multi-instance setups.
• The revalidate: 60 you set in code means "regenerate at most once per 60 seconds, lazily on next request". A site with no traffic doesn't regenerate.

On shared cPanel/DA: ISR doesn't work — there's no Node runtime. Use output: 'export' and forget about ISR; rebuild via CI when content changes.

Domain India + Cloudflare in front (the budget-friendly Indian-latency play)

For Indian-audience Next.js sites that don't justify Vercel Pro, this is often the best cost/performance combination:

1. Deploy Next.js to Domain India VPS Starter (₹553/month) via the systemd + Caddy setup above.
2. Front it with Cloudflare (free plan).
3. Cloudflare's BOM/MAA PoPs serve cached pages and assets at 5-15 ms RTT to Indian users.
4. Cache misses go to your VPS at 130-180 ms (Hetzner DE), which the user perceives as "first slow load, then fast".

For most Indian SaaS landing pages, marketing sites, and brochureware, this stack is significantly cheaper than Vercel Pro and faster than Vercel Hobby (because Vercel Hobby doesn't have Mumbai edge).

For high-dynamism apps (real-time dashboards, e-commerce checkout flows), the cache-miss penalty hurts more — at that point, Vercel Pro's Mumbai edge or hosting closer to your audience is worth the upgrade.

Common errors and what they actually mean

`<Image /> with src "..." has either width or height modified, but not the other.` — Next/Image needs both dimensions to prevent layout shift. Either provide both width and height, or use fill mode with a sized parent.

`A required parameter (params) was not provided as a string in generateStaticParams` — App Router dynamic route's generateStaticParams returned undefined or wrong shape. Must return { params: { id: 'string' } } shape, not { id: 'string' }.

`Module not found: Can't resolve 'fs'` (or `'child_process'`, `'path'`) — you're trying to import Node-only modules in code that runs on the edge / browser. Move the import inside a server component, API route, or getServerSideProps.

`Error: API Resolved without sending a response` — your API route handler ran but didn't call res.end(), res.json(), or res.send(). Add a return.

`Error: ENOSPC: System limit for number of file watchers reached` — dev mode hit Linux's inotify limit. Increase: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p.

`<--- JS stack trace ---> FATAL ERROR: ... JavaScript heap out of memory` — build OOM. See "Build memory" section above.

`Error: getaddrinfo EAI_AGAIN api.example.com` — DNS resolution failed at runtime. Common on isolated build environments. Make sure your VPS has working DNS (/etc/resolv.conf).

`Error occurred prerendering page "..."` followed by network error — you're calling an API at build time that's not reachable from your build environment. Move data fetching to runtime (getServerSideProps) or pre-fetch from CI.

`Error: Page "..." is missing param "..." in "generateStaticParams"` — App Router dynamic route had a request for a slug not in the static-params list. Either add the slug, or set dynamicParams: true (default) and ensure the page handles SSR fallback.

`TypeError: Cannot read properties of undefined (reading 'pathname') at NextRouter` — old next/router used in App Router context. Migrate to next/navigation (useRouter, usePathname).

Hydration mismatch (Text content does not match server-rendered HTML) — server and client rendered different HTML. Common causes: Date.now()/Math.random() outside useEffect, browser-only globals (window, document) accessed during SSR, conditional rendering based on typeof window. Fix: gate with useEffect or useState initialisation.

Performance baselines — what good looks like

For a typical Next.js marketing site with ~10 pages, ~50 KB JS bundle:

The biggest single win is the CDN. Without a CDN, even on a VPS, Indian users see 130+ ms TTFB which Google's Core Web Vitals will flag.

Frequently asked questions

Bottom line

For a new Next.js project starting today: try Vercel free first. If you hit pricing limits or India-latency issues on the Hobby tier, evaluate Cloudflare Pages — it's free for unlimited traffic and has India PoP coverage out of the box.

If you need self-hosted infrastructure (cost ceiling, data residency, colocation with backend), Domain India VPS Starter at ₹553/month + Cloudflare in front is a strong combination — production-ready Next.js for less than ₹1,000/month including the CDN, with no usage-based bandwidth surprises.

For pure-static Next.js (marketing site, blog, documentation), our shared cPanel/DirectAdmin works fine with output: 'export'. Don't try to make API routes / SSR / middleware work on shared — they require a Node runtime that shared hosting deliberately doesn't provide.

If you want help setting up the systemd + Caddy + Cloudflare stack for a Next.js app on Domain India VPS, [email protected] — we troubleshoot Next.js production setups as part of standard VPS support.