Next.js, run the way it’s actually built.
Server-rendered routes and API handlers get a dedicated instance sized to the app; a fully static export runs for a fraction of that. Either way, deploys are a push to main and CodeHerder ships the small stuff in between.
When this isn't the right fit If the app is a fully static export with no API routes at all, this page still applies to the build pipeline — but the hosting itself is a Static Starter, not a dedicated instance. Say so on the quote form and we’ll size it down.
What it needs to run
The shape of the workload, before any hosting decision gets made.
- Runtime
- Node.js, long-running
- Build step
- next build, run on every push
- Standing process?
- Yes, if any route is server-rendered or an API handler
- Data store
- Optional — whatever the app talks to (often Postgres)
- Verdict
- Dedicated by default · Static if the whole app exports
How it runs here
The same management as every other tier we run, written in Next.js's own terms.
Provisioning
A dedicated instance sized to the app, with Node installed and the process manager already wired to restart on crash or on deploy.
Deploys
Push to main, the pipeline we already run builds and restarts the app — no separate CI to maintain on your side.
Data + backups
If the app talks to Postgres, it’s a managed tier backed up nightly alongside the app itself, not a separate thing to remember.
TLS / DNS / monitoring
Certificates auto-renew, DNS is managed end to end, and monitoring restarts a hung process before a visitor notices.
Moving it in
Already running somewhere else? See the full migration playbook — here's what's specific to Next.js.
- 1
Point us at the repo
Read access is the whole ask — we work out the output mode from the config, not a questionnaire.
- 2
We stand up a copy
Provisioned as code, built the same way your deploys will run, checked before anything is live.
- 3
Cutover on your schedule
DNS and TLS switch over with little-to-no downtime, rollback ready if anything looks wrong.
- Which output mode matters most: `output: "export"` needs nothing but a static host; anything using middleware, route handlers, or server actions needs a standing process.
- Environment variables baked in at build time versus read at runtime behave differently across a redeploy — worth checking before the first cutover, not after.
- Image optimisation and incremental static regeneration both assume a server process is present; a static export silently drops them.
The loop, on Next.js
Next.js apps change constantly after launch — a new route, a copy tweak, a dependency bump — which is exactly the shape the loop is built for.
- 01Build
CustomLabs
Bring an app you already built, or have CustomLabs design and build the first version against the framework’s own conventions.
- 02Iterate
CodeHerder
Brief a new route, a copy change, or a small feature in plain language — an agent opens a pull request against the real Next.js app, in its own file structure.
- 03Run
CustomHosted
A dedicated instance sized to the app (or a static export, if that’s all it needs), deployed on every push, patched and backed up without you doing anything.
- Brief
- Briefed: add a `/pricing` route with data pulled from an existing API route, styled to match the rest of the app.
- Pull request
- CodeHerder’s agent added the route and the fetch against the real repo, opening a pull request the same day.
- Shipped
- Reviewed, merged, and live on the next push — no separate deploy step to remember.
Which output mode are you actually running?
The single biggest cost lever on a Next.js app isn't the instance size — it's whether the app needs a server at all.
Next.js ships three genuinely different deployment shapes under one framework name, and the pricing difference between them is the whole reason this page exists as its own line item instead of a generic "Node app" entry. A route using generateStaticParamsand no server-only APIs compiles down to plain HTML, CSS, and JS — that's a Static Starter site, full stop, and paying for a dedicated instance to serve files that never change at request time is money spent on nothing.
The moment one route uses middleware, a server action, a route handler that touches a database, or revalidate-based incremental static regeneration, the app needs a long-running Node process to answer requests — that's the dedicated shape this page quotes by default, and it's the right call the instant any of those show up, however small the rest of the app looks.
Most real apps are a mix: a marketing shell that could be static sitting next to an authenticated dashboard that can't be. We don't force a single verdict on the whole repo — describe the split on the quote form and we'll size the instance to the parts that actually need one, not the parts that don't.
A starting configuration
A server-rendered app: a dedicated instance sized for Next.js, plus the iteration add-on.
- Base plan
- Dedicated S
- Iteration — CodeHerder loop
- +$25/mo
- Estimated total
- $54/mo
Next.js questions
The questions this stack raises on its own. General hosting questions live on the homepage.
01Do I need a dedicated instance for every Next.js app?
Only if any route is server-rendered, uses middleware, or exposes an API handler. A pure static export runs on Static Starter instead — tell us which output mode you’re using and we’ll size it correctly.
02Do you support the app router and server actions?
Yes — both need a standing Node process, which is exactly what the dedicated tier provisions.
03What about incremental static regeneration?
ISR needs a running server to revalidate pages on a schedule — it works on the dedicated tier, but not on a static export.
04Can CodeHerder work in a monorepo?
Yes — briefs can target a specific app or package inside a monorepo; the agent opens its pull request against just the paths that matter.
05What if we outgrow Dedicated S?
Move up a tier any time — more CPU and RAM for the same Node process, no rebuild or redeploy required beyond the usual push.
Keep exploring
- Dedicated compute
A fixed-price instance sized to the workload, with a static IP and full control.
- Static hosting
For the export-only path — a fully static Next.js build on the global edge network.
- Migrations
Already running Next.js somewhere else? A rehearsed cutover with little-to-no downtime.
- Scaling
What "move up a tier" above actually means: the ladder, the move minute by minute, and no rebuild required.
Ready to start?
Tell us what you're running — one fixed monthly rate, within a business day.