NextJS hosting on your own server, with ISR and images that just work
Next.js runs well on a plain Linux server once a few details are right: the standalone build, a cache directory that survives releases, image optimization with sharp, and environment variables that differ between staging and production. Deployment handles those details for every Next.js app you connect, then ships each push with a health-checked switch and one-click rollback.
What Deployment detects in a Next.js project
next in package.json marks the project as Next.js, and next.config.js, next.config.mjs or next.config.ts tells Deployment how it is built. If output: 'standalone' is set, the release runs the small standalone server instead of the full node_modules. If output: 'export' is set, the site is served as static files by nginx or Caddy with no Node process at all. The App Router or Pages Router does not matter for hosting, but middleware, route handlers and server actions all need the Node server, and Deployment plans for it.
- Node LTS version from engines or
.nvmrc - Package manager from the lockfile
- Standalone, default or static export output
sharpfor image optimization, installed when missing from your dependencies
What Deployment installs for Next.js hosting
The server gets the usual hardening (firewall, key-only SSH, unattended security updates, swap), then Node LTS, your package manager, and nginx or Caddy as a reverse proxy with gzip and long-lived cache headers for /_next/static. Hashed static assets are served straight from disk by the proxy, which takes load off the Node process. Builds can be memory hungry, so Deployment sizes swap to match the server and lets you cap Node memory with NODE_OPTIONS per site.
A Next.js deploy script with standalone output
The process command is node .next/standalone/server.js with PORT and HOSTNAME set by Deployment. You can change any line in the panel, for example to run a database migration or to upload source maps to your error tracker.
cd "$RELEASE_PATH" npm ci npm run build cp -r public .next/standalone/public cp -r .next/static .next/standalone/.next/static ln -sfn "$SHARED_PATH/cache" .next/standalone/.next/cache
ISR cache that survives every deploy
Incremental Static Regeneration writes rendered pages into .next/cache. If that folder lives inside the release, every deploy throws the cache away and the first visitors pay the render cost again. Deployment keeps the cache in a shared folder linked into each release, so regenerated pages stay warm across deploys, and revalidatePath and revalidateTag keep working as they do in development. If you run more than one server, point Next.js at a shared cache handler (Redis works well) and Deployment provisions the Redis instance for you.
Image optimization on your own server
next/image resizes images on request and stores the results in the same cache. With sharp installed this is fast and light on memory. Remote image domains you allow in next.config are fetched by your server, so their traffic stays within your bandwidth, not a vendor's per-image billing.
Environment variables per environment
Next.js reads NEXT_PUBLIC_ variables at build time and the rest at runtime. That is why each environment (production, staging, preview branches) has its own encrypted set of variables in Deployment, injected into the build and into the running process. Before a deploy the panel shows a diff of what changed, so a missing API key is caught before users see a broken page. Branch per environment is described on deploy from git.
Zero downtime and rollback for Next.js
A Next.js build can take minutes. During that time the current release keeps serving traffic. When the build finishes, Deployment starts the new server, calls the health route, and switches the proxy only after it answers 200. The old process then drains and stops. Because each release folder keeps its own .next/static, browsers that loaded the old version can still fetch their chunks for a while, which avoids the chunk load errors that hit naive deploys. Rollback switches back to a previous release in seconds with no rebuild. See zero downtime deployment for the details.
Databases and APIs next to your frontend
Many Next.js apps talk to PostgreSQL through Prisma or Drizzle. Deployment creates the database, user and grants, and backs it up to your S3-compatible storage. If your API runs separately, host it on the same server or another one and connect it privately: see node js hosting for Express and NestJS services.
Which plan fits your Next.js hosting
| Plan | Monthly | Yearly, per month | Servers | Uptime checks |
|---|---|---|---|---|
| Starter | 49 USD | 24 USD | 3 | 5, every 5 min |
| Team | 199 USD | 99 USD | 15 | 50, every 1 min |
| Agency | 499 USD | 249 USD | 60 | 250, every 1 min |
| Enterprise | 1 499 USD | 749 USD | 250 | 1 000, every 30 s |
A marketing site and an app on one server fit Starter. A product team with preview, staging and production fits Team. Agencies running many client frontends pick Agency.
Next.js hosting questions
Do I have to use standalone output?
No, but it is recommended. Standalone releases are smaller and start faster. Without it Deployment runs next start with production dependencies installed.
Does middleware run on my server?
Yes. Middleware, route handlers and server actions run in the Node server on your machine, with the same environment variables as the rest of the app.
Can I host a static export instead?
Yes. With output set to export, Deployment serves the out folder through nginx or Caddy with cache headers and no Node process.
Can I try Deployment before I pay?
Yes. The home page has a free one-time demo: paste a public repository URL and see the detected stack, the server plan and the first lines of the deploy script. Plans start at 49 USD a month, or 24 USD a month billed yearly.
Host Next.js where you decide
Bring a server or a cloud account and push your next build.
$ git push origin main
✓ build release 20261019-142210
✓ health check 200
✓ switch current 0.4 s
$