What does Next.js maintenance involve?
Next.js maintenance involves keeping four layers current: Next.js itself, React, the Node.js runtime and the npm packages your site depends on. Each releases fixes on its own schedule. Maintenance is the routine of applying those updates, testing them and shipping them without breaking the live site.
It's the part of owning a code-based site that hosted builders hide. On Framer or Webflow, the platform updates its own stack. On Next.js, your team or your developer does. That's not a reason to avoid Next.js, which we build most custom sites on, but it's a cost to plan for. For how this fits with the rest of upkeep, see our guide to website maintenance.
Layer | What changes | Suggested rhythm |
|---|---|---|
npm dependencies | Patches, minors and occasional majors | Monthly, via automated pull requests |
Next.js | Patches often; major versions periodically | Patches monthly; majors planned |
React | Usually tied to Next.js majors | With Next.js upgrades |
Node.js | LTS releases with published end-of-life dates | Before the current version's end of life |
Security advisories | Unscheduled | Within days of disclosure |
How often should you update Next.js?
You should apply Next.js patch and minor releases about monthly, and security fixes as soon as they're announced. Major versions can wait a little while the ecosystem catches up, but plan to adopt each one within a few months rather than skipping several. Staying one major behind is manageable. Staying three behind is a rebuild.
The reason is compounding change. Each major Next.js release can change defaults, deprecate APIs and require newer React or Node.js versions. Upgrading one step at a time means reading one set of release notes and running one set of codemods. Jumping several at once means untangling them all together, often alongside dependencies that dropped support for the old versions.
How do you update Next.js and npm dependencies safely?
You update safely by making every update a small, reviewable change that's built and tested before it merges. Automation opens the pull requests, the build and tests catch obvious breakage, and a preview deployment lets a person confirm the site still looks and works right.
Automate update pull requests
Use Dependabot or Renovate to open pull requests for outdated packages. Group minor and patch updates into one weekly or monthly batch to reduce noise.
Keep the lockfile committed
The lockfile pins exact versions, so the build that passed review is the build that ships. Never delete it to fix an install error.
Build and type-check in CI
Every pull request runs a production build, type-check and lint. Most breaking changes show up here.
Check the preview
Open the preview deployment and click through key templates: home, pricing, a blog post, a form. Submit a test form.
Read release notes for majors
For major versions of Next.js or React, read the upgrade guide and run the official codemods before fixing the rest by hand.
Merge and watch
Merge during working hours, then check error logs and Core Web Vitals over the following days.
The official Next.js documentation includes upgrade guides for each major version, and the Next.js codemod tool automates many of the mechanical changes. Preview deployments make step four painless, and Vercel, Netlify and Cloudflare all create them automatically for each pull request.
Handling npm audit warnings without panic
npm audit often reports many vulnerabilities, and most are in development tools that never ship to visitors, or in code paths a marketing site doesn't use. Don't run a forced fix blindly: it can jump packages across major versions and break the build.
Instead, check whether each advisory affects production code, whether a patched version exists and whether your site actually uses the vulnerable feature. Fix the ones that ship to the browser or run on the server first. Advisories for Next.js or React themselves should always be treated as urgent.
How should you handle Next.js security updates?
Handle Next.js security updates as same-week work: read the advisory, check whether your version and setup are affected, patch, test on a preview and ship. Framework vulnerabilities are rare but serious, and once they're public, automated scanning for unpatched sites starts quickly.
2025 showed why this matters. Next.js shipped a fix for a middleware authorization bypass in the spring, and late in the year a critical vulnerability in React Server Components required patches across frameworks that use them, including Next.js. Teams with a monthly update routine applied the fixes in an afternoon. Teams several majors behind had to upgrade first, sometimes under real time pressure.
Hosting can add a layer of protection. Platforms like Vercel and Cloudflare sometimes deploy mitigations at the edge for widely exploited issues, but treat that as a bonus, not a plan. Patch your own code. For the non-code side of security, such as access, two-factor login and form spam, see website security basics.
What else needs maintaining on a Next.js marketing site?
Beyond dependencies, a Next.js marketing site needs its rendering, performance, CMS integration and hosting setup kept healthy. These drift as content and features are added, and they're where most real-world problems on code-based sites come from.
- Rendering: marketing pages should stay statically generated or cached, so search and AI crawlers get full HTML. Our guide to server-side rendering for AI crawlers explains why.
- Performance: Core Web Vitals field data for Q2 2026 shows only about two-thirds of Next.js sites pass INP, with a median around 236ms. Third-party scripts and heavy client components are usual causes.
- Design system: components and tokens need tending as pages are added, or the site fragments. See building a design system for a Next.js marketing site.
- Styling stack: Tailwind and similar tools have their own major versions; our Next.js and Tailwind v4 setup covers the current approach.
- Hosting adapters: if you run on Cloudflare, the adapter that runs Next.js there also needs updating. See hosting Next.js on Cloudflare Workers.
How much upkeep does Next.js need compared with no-code?
Next.js needs more technical upkeep than Framer or Webflow, because your team owns the code and its dependencies. In return, you get full control, no platform lock-in and the ability to build anything. Whether that trade is worth it depends on how much the site needs to do and who's available to maintain it.
Next.js | Framer or Webflow | |
|---|---|---|
Framework and security updates | Your team or developer | The platform |
Custom features and integrations | No limits | Within platform limits |
Portability | Full: host anywhere | Tied to the platform |
Who can edit content | Editors in a headless CMS | Editors in the visual builder |
Typical upkeep | A few hours a month, plus planned upgrades | Mostly content, forms and speed checks |
If upkeep is the deciding factor, our guide to choosing a platform for your marketing site compares all four main options. Some teams move the other way, from code to a visual builder, when nobody can maintain the code; moving from Next.js to Framer or Webflow covers when that makes sense.
Who should maintain a Next.js marketing site?
A Next.js marketing site should be maintained by someone comfortable reading release notes, running builds and debugging when an update breaks something. That can be an in-house engineer, a freelance developer or a studio on retainer. What matters is that it's a named person with time set aside, not whoever on the product team has a spare afternoon.
Product engineers can maintain the marketing site, but it often loses to product work in prioritization, and updates slide. That's the most common reason we see marketing sites fall behind. If that's your situation, compare the options in who updates your website after launch, and see what each typically costs in our website maintenance cost guide.
