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
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)
Deploy Next.js in minutes.
- 1
Check your scripts
Keep the defaults:
"build": "next build"and"start": "next start". If there is no start script we runnpx next startfor you. - 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
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
Deploy to staging
The build runs
next buildwith live logs. Openhttps://<slug>-staging.apps.dployhub.comand click through the pages that matter. - 5
Go live and add your domain
Click Go live to promote the staging image with no rebuild. Then add
www.yourdomain.comin the Domains tab with a CNAME; HTTPS is issued automatically.
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 defaultnext startworks out of the box; only switch to standalone if you also ship your own Dockerfile that copies.next/staticandpublicalongsideserver.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/imageand the ISR cache live inside the container and reset on each deploy. That is fine for caches; store user uploads under/dataor 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/healthif your home page does heavy data fetching, so releases switch over quickly.
Trigger
git push
Promote
same image
Rollback
1 click
Next.js questions.
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.