Next.js hosting: how to deploy a Next.js app outside Vercel (2026 guide)

Next.js does not need a special host

Next.js is a React framework that runs on Node.js. Vercel, the company behind it, offers excellent hosting, but nothing in Next.js requires it: the same app runs anywhere you can run “next build” and “next start”. That matters when you want servers in India close to your users, predictable yearly pricing in rupees, a database on the same server, or simply one bill for your site, API and database.

Everything in a standard Next.js app works on a Node.js host: the App Router and Pages Router, server-side rendering, static and incremental pages, API routes and route handlers, middleware, server actions and image optimisation.

The memory trap: next build

Running a built Next.js app is light. Building it is not: next build compiles every route, and medium-sized apps can need more than a gigabyte of memory while it runs. On a plan with a hard memory limit, an out-of-memory build simply fails.

You have two good options. Choose a plan with room to build — Business gives 1 GB RAM (₹7,188 a year) and Pro 2 GB (₹11,988 a year). Or build somewhere else — on your laptop or in GitHub Actions — with output: "standalone" in next.config, and upload the result, which then runs comfortably on a smaller plan such as Growth (512 MB).

Step 1 — Create the Node.js app

In Create an app choose Node.js, version 20 or newer (current Next.js releases need it), your plan and domain, and pay. The app is created automatically with a placeholder page until your code arrives.

Step 2 — Use the Next.js preset

On App settings choose the Next.js preset. It fills in npm ci as the install command, npm run build as the build, and npx next start -p $PORT -H 127.0.0.1 as the start command, so Next.js listens on the port the platform assigns, behind its web server and SSL. If your package.json already has the right start script, the “use my start script” preset works too.

Step 3 — Environment variables, the Next.js way

Add your variables on the App settings page — paste your .env and it becomes rows. Remember the Next.js rule: anything prefixed NEXT_PUBLIC_ is baked into the browser bundle at build time, so it must exist before you build; server-only secrets (database URLs, API keys) are read at runtime. After changing a NEXT_PUBLIC_ value, deploy again rather than just restarting.

Step 4 — Deploy from GitHub with rollback

Connect your repository on the Git page — public repositories directly, private ones with a deploy key the dashboard creates for you. Each push to your branch runs the pipeline: fetch the commit, install, build, switch the live release, and check that the app answers. If the new release fails, the previous one stays live and you are emailed the log. Keep several releases and roll back to any of them with one click.

Step 5 — Domain, SSL and images

Point A records for @ and www to the server IP on the Domains page. Free SSL issues automatically. For next/image, keep remote image domains listed in next.config; images are optimised on the server, so large galleries benefit from a CDN such as Cloudflare in front, set to SSL Full (strict).

What you get with Cloud Ninza Next.js hosting

Next.js on your own terms, on servers in India:

• SSR, App Router, API routes, middleware, server actions and ISR
• A ready Next.js preset: install, build and start filled in
• Git auto-deploys with health check and automatic rollback
• Environment variables, live build output, logs and restart
• Node.js 18–26; apps run continuously and restart on crash
• MySQL/MariaDB and PostgreSQL on the server; Atlas and external Redis by connection string
• Free SSL issued automatically; WebSockets supported
• Yearly pricing in rupees with GST invoices, from ₹2,388

Next.js plus an API: one plan or two apps?

Many projects pair Next.js with a separate API — NestJS, Express or Django. Route handlers inside Next.js are enough for many apps. When the API is separate, run it as a second app on the same account (Growth and above host more than one) under a subdomain such as api.yourdomain.com. Both apps share the plan's memory, which keeps costs down while you grow.

Static export, SSR or both?

Not every Next.js site needs a server. If every page can be built ahead of time — a marketing site, documentation, a portfolio — next build with output: "export" produces plain HTML, CSS and JavaScript that any host can serve, even a PHP plan's public_html. The moment you use server-side rendering, API routes, middleware, server actions, authentication on the server or incremental regeneration, you need Node.js hosting running next start.

Many real sites are hybrid: most pages static, a few dynamic. Next.js handles that automatically on a Node.js host — static pages are served from the build output, dynamic ones are rendered per request — so you only pay the server cost for the pages that need it.

Caching and performance on your own host

On your own host, performance comes from the same three places it always does. Cache what you can: use fetch caching and revalidate in the App Router, and serve static pages as static. Keep images light: next/image resizes on the server, and a CDN such as Cloudflare in front, set to SSL Full (strict), serves them from the edge. Keep the server warm: apps on Cloud Ninza run continuously and never sleep, so there is no cold start for the first visitor of the morning.

Measure before you tune. Next.js prints route sizes after next build — large client bundles are usually the first thing to fix, long before server resources.

Moving an existing Next.js app from Vercel

Moving is mostly configuration. Copy your environment variables from the Vercel dashboard into App settings, connect the same GitHub repository, choose the Next.js preset and deploy. Check anything Vercel-specific: Vercel Edge Config, KV and Blob have equivalents elsewhere (an external Redis, object storage), and edge-runtime routes can usually run on the Node.js runtime instead. Image domains, redirects and rewrites in next.config work unchanged. When the new deployment answers on its temporary address, switch your domain's A records and let the free SSL issue.

A Next.js launch checklist

Before you point the domain, check a short list. Run next build locally once and fix any warnings about large pages. Confirm every environment variable exists in App settings, especially the NEXT_PUBLIC_ ones the browser needs. Set your canonical site URL so metadata, sitemaps and Open Graph images use the real domain, and generate a sitemap and robots file with the App Router's built-in sitemap and robots routes. Add a custom 404 and error page. Finally, open the site on a phone over mobile data — the fastest way to see what real visitors will see.

Key takeaways

The short version, for anyone skimming:

• Next.js runs on any Node.js host with next build and next start.
• Builds need memory: choose Business, or build in CI with standalone output.
• Use the Next.js preset; NEXT_PUBLIC_ variables must exist before building.
• Git deploys give you health checks and automatic rollback.
• Cloud Ninza Node.js hosting for Next.js starts at ₹2,388 a year.