This Next.js production checklist covers the 25 things worth checking before you point a real domain at your app: build and runtime, configuration and secrets, caching and images, SEO, security, error handling, monitoring and the go-live itself. Each item is short and specific, so you can work through it in an afternoon. It applies to Next.js 15 and 16 on any Node.js host.
Build and runtime
1. Production build passes cleanly. Run npm ci && npm run build from a clean checkout. Treat warnings as work to do, not noise.
2. Types and lint run in CI. Next.js 16 no longer runs the linter during next build, and the next lint command has been removed. Run ESLint (or Biome) and tsc --noEmit yourself, ideally on every pull request:
{
"scripts": {
"lint": "eslint .",
"typecheck": "tsc --noEmit"
}
}
3. Node.js version pinned. Use an LTS release (Node.js 24 is Active LTS) and pin it in engines so your laptop, CI and server match. Next.js 16 requires Node.js 20.9 or later.
4. Lockfile committed. package-lock.json (or your package manager's lockfile) is in Git, and the server installs with npm ci.
5. Tested with npm start. Run the production build locally and click through the key flows. Development mode hides problems like static rendering surprises and caching behaviour.
Configuration and secrets
6. All environment variables set on the host. Compare your .env.example with the production settings. Missing variables are the most common cause of "works locally" failures.
7. No secrets in NEXT_PUBLIC_ variables. Anything with that prefix is visible in the browser. See Next.js environment variables in production.
8. Secret modules marked server-only. Add import "server-only" to modules that read secrets or talk to the database, so an accidental client import fails the build.
9. Environment validated at startup. A schema (for example with zod) that fails fast beats a vague error on the first request.
Caching, data and images
10. Each route renders the way you expect. The build output marks routes as static or dynamic. Check that pages you expect to be static are, and that per-user pages are not accidentally cached.
11. Revalidation strategy chosen. Decide between time-based revalidate, on-demand revalidatePath/revalidateTag from your CMS, or dynamic rendering. If you run more than one instance, set up a shared cache. Details in ISR and caching in self-hosted Next.js.
12. Images configured. remotePatterns lists only the hosts you use, responsive images have a correct sizes prop, and the main above-the-fold image uses preload (Next.js 16) or priority (Next.js 15).
13. Database connections pooled. Use one shared client or pool per process, not a new connection per request, and check your connection limit against your plan.
SEO and metadata
14. Metadata on every page. Titles and descriptions via the metadata export or generateMetadata, plus metadataBase set to your production URL so Open Graph image URLs are absolute.
15. sitemap.ts and robots.ts in place. Generate them from your routes and content in the app folder. Make sure preview and staging URLs are not indexed.
16. One canonical domain. Pick www or the bare domain, redirect the other to it, and redirect HTTP to HTTPS.
17. Redirects for old URLs. If you are replacing an older site, add permanent redirects in next.config so existing links and search rankings carry over.
Security
18. Security headers set. A starting point in next.config.ts:
import type { NextConfig } from "next";
const nextConfig: NextConfig = {
poweredByHeader: false,
async headers() {
return [
{
source: "/:path*",
headers: [
{ key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
{ key: "X-Content-Type-Options", value: "nosniff" },
{ key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
{ key: "X-Frame-Options", value: "DENY" },
],
},
];
},
};
export default nextConfig;
Add a Content Security Policy when you can; the Next.js CSP guide shows nonce-based setups. Test headers carefully, because a strict CSP can break third-party scripts.
19. Server Actions and Route Handlers check authorisation. Every Server Action is a public endpoint. Check the session and permissions inside each action, not only in the page that renders the form, and validate all input.
20. Forms protected from abuse. Contact and sign-up forms need rate limiting and spam protection. Login routes need rate limiting too.
21. Dependencies audited. Run npm audit and update Next.js to the latest patch release of your major version, because security fixes ship in patches.
Errors and monitoring
22. Error pages exist. Add app/not-found.tsx, app/error.tsx and app/global-error.tsx, so users see a helpful page instead of a blank screen, and so stack traces never reach the browser.
23. Errors are logged somewhere you look. Log to stdout, and consider instrumentation.ts with an onRequestError hook to send server errors to your error tracker. Add uptime monitoring on the home page or a health route.
Go-live
24. Backups and restore tested. Know what is backed up (database, uploads), how often, how long backups are kept and how to restore. Do one test restore before launch, not during an incident.
25. DNS and SSL ready. Lower the DNS TTL a day before switching, point the records, confirm the SSL certificate is issued, and check the site over HTTPS on a phone using mobile data, not just your office Wi-Fi.
After launch
Once you are live, keep an eye on:
- Core Web Vitals from real users (Search Console reports them once you have traffic)
- server memory, because leaks and heavy image optimisation show up over days
- error logs after every deploy
- POPIA: if you collect personal information through forms or analytics, your privacy notice and consent must match what you actually do
How NewHost helps with the checklist
Several of these items are handled by the platform when you use NewHost Next.js hosting:
- Git push to deploy with configurable build and start commands (items 1, 4, 5)
- encrypted environment variables (item 6)
- free Let's Encrypt SSL and DNS in the same dashboard (items 16, 25)
- automatic backups on every plan, plus on-demand backups before risky changes (item 24)
- preview deploys per branch on the Developer plan and up, for testing before merging
- managed MySQL databases close to your app (item 13)
Frequently asked questions
What should I check before deploying Next.js to production?
At minimum: a clean production build, all environment variables set, no secrets in NEXT_PUBLIC_ variables, error pages, security headers, a canonical domain with HTTPS, and a tested backup restore. The 25 checks above cover the rest.
Does next build still run ESLint?
Not in Next.js 16. The built-in lint step during next build and the next lint command were removed, so run ESLint or Biome directly in your scripts and CI.
How do I know if my Next.js pages are static or dynamic?
The next build output lists every route with a symbol showing whether it is static, dynamic or uses partial prerendering. Review it after each significant change.
Should I use standalone output for production?
Only if it suits your deploy method. It makes container images small, but on a host that installs dependencies and runs npm start, the default build works fine. See Next.js standalone output explained.
Ready to launch? Deploy your Next.js app on South African servers with NewHost Next.js hosting, from R99 a month excluding VAT.