Skip to content
Next.js hosting

Next.js in production, with a staging copy of every change

DployHub runs Next.js as a real Node server, so server components, API routes, middleware and ISR behave exactly as they do on your machine. We detect next in your dependencies, run your build and start next start. Each push builds once on staging; Go live promotes that same image, so what you tested is what ships.

Free staging (0.25 vCPU · 256 MB · 1 GB) · Live from ₹118.50/month, billed hourly · No servers to manage

What we detect

Sensible Next.js defaults, no config files.

When you connect the repository we read it and fill in the build settings below. Every value can be changed in the app’s settings — see build settings.

Runtime
Node.js 20
Port
3000 (or the -p / --port value in your start script)
Build command
npm run build
Start command
npm start (or npx next start)
Step by step

Deploy Next.js in minutes.

  1. 1

    Check your scripts

    Keep the defaults: "build": "next build" and "start": "next start". If there is no start script we run npx next start for you.

  2. 2

    Create the app from your repo

    In New app, connect GitHub and pick the repo and branch. For a Turborepo or Nx monorepo, set Folder with your app to something like apps/web.

  3. 3

    Add environment variables

    Add server secrets and NEXT_PUBLIC_ values in the Environment variables tab for staging and live. Use Copy from staging to save typing.

  4. 4

    Deploy to staging

    The build runs next build with live logs. Open https://<slug>-staging.apps.dployhub.com and click through the pages that matter.

  5. 5

    Go live and add your domain

    Click Go live to promote the staging image with no rebuild. Then add www.yourdomain.com in the Domains tab with a CNAME; HTTPS is issued automatically.

Tips

Running Next.js well in production.

Staging is free

Every app gets a staging copy in a free, lightweight Docker container (0.25 vCPU · 256 MB · 1 GB). It pauses after 7 days without a deploy — one click starts it again.

  • output: 'standalone' is optional. The default next start works out of the box; only switch to standalone if you also ship your own Dockerfile that copies .next/static and public alongside server.js.
  • NEXT_PUBLIC_ variables are baked into the browser bundle at build time, and Go live reuses the staging image. Set public values on both staging and live, keep them identical, and redeploy after changing them. Put environment-specific settings in server-only variables instead.
  • Server-only variables (no NEXT_PUBLIC_ prefix) are read at runtime, so a restart after saving is enough to pick up a new value.
  • Images optimized by next/image and the ISR cache live inside the container and reset on each deploy. That is fine for caches; store user uploads under /data or in object storage.
  • Next.js servers are memory hungry. 1 vCPU with 1 GB (₹510 a month with 10 GB storage) is a comfortable live starting point; watch the Metrics tab and size up in Settings without a rebuild.
  • Point the health check at a light route such as /api/health if your home page does heavy data fetching, so releases switch over quickly.
Do I need to change next.config.js?

No. A standard Next.js app deploys without config changes. Middleware, route handlers, rewrites and redirects all work because we run the real Next.js server.

Can I use pnpm or yarn?

Yes. Commit `pnpm-lock.yaml` or `yarn.lock` and we use that package manager for install, build and start.

My NEXT_PUBLIC_ value is wrong on live. Why?

Public variables are compiled in during the staging build and that image is promoted as-is. Set the value on staging and live, deploy again to staging, then go live.

Is a static export supported?

Yes. If you use `output: 'export'`, either serve the `out` folder from a small Dockerfile or keep `next start`. Most apps should simply keep the Node server.

Ship your Next.js app today.

Create an account, connect your repository and get a free staging copy plus a live HTTPS address in minutes.