Node.js Moves to One Major Release Per Year, Starting with Node 27 (InfoQ) became a major topic of discussion. While Node.js previously released major versions semi-annually, it is transitioning to one major release per year starting with Node 27. By reducing the release frequency, the lifespan and support period of each version become easier to forecast, making it easier to formulate version roadmaps for long-term systems.
Meanwhile, in the field of custom development, incidents where "Node.js, though up-to-date at delivery, reaches end-of-life a few years later and continues running with unaddressed vulnerabilities" occur constantly. From the standpoint of supporting system development for clients, we view this not simply as a matter of "chasing the newest release," but rather as a challenge to incorporate into contracts "which LTS to select, when to upgrade, and who will monitor for end-of-life before handover." Connecting with the runtime migration covered in Serverless Migration for Clients Using AWS Lambda Web Adapter (GH Media), the backend reliability explored in Persistent Workflows for Clients with Postgres / SQLite (GH Media), and the infrastructure standardization discussed in OS Standardization for Clients Using Azure Linux 4 (GH Media), this article organizes "Runtime LTS Strategy and Maintenance" into a custom development package.
Why a Node.js LTS strategy "right now"?
| Dimension | Semi-annually (conventional) | Annually (Node 27 onwards) |
|---|---|---|
| Major release frequency | Twice a year | Annual |
| Lifespan predictability | Short and hard to predict | Long and easy to predict |
| LTS planning | Frequent upgrade decisions | Planned upgrades |
| Support period | Cumbersome to track | Manageable |
| Maintenance burden | High upgrade frequency | Planned and distributed |
| Long-term operation | Prone to version drift | Easy to strategize |
In other words, because the release frequency has stabilized, it has become easier in custom development to establish operational models that "design from the start which LTS to build with and when to upgrade next, monitoring for end-of-life to perform ongoing maintenance." This enables us to guarantee "safe operations without unaddressed end-of-life software" as a deliverable.
Three structural changes beneficial to custom development projects
Structure 1: From "building on the latest" to "building on LTS"
The latest version often has an unpredictable lifespan and may be unsuitable for production. In custom development, we base our selections on Active LTS to achieve both stability and a reliable support window.
Structure 2: From "build and leave alone" to "monitoring for end-of-life"
Continuing to run systems past their EOL without noticing is a severe risk. In our client services, we offer operations that monitor with an EOL calendar and update in a planned manner.
Structure 3: From "haphazard updates" to "planned updates"
Sudden major upgrades invite trouble. In custom development, we formulate update schedules tailored to annual cycles and upgrade through phased validation.
Five phases of "runtime LTS strategy and maintenance" provided in custom development
Phase 1: Current state audit (1 week)
- Inventorying Node.js versions in running systems
- Checking EOL / support status
- Checking compatibility of dependent packages
- Vulnerability scanning (npm audit, etc.)
Phase 2: LTS strategy design (1 week)
- Selecting the target LTS version
- Planning the update cycle (annual)
- Identifying compatibility risks
- Formulating rollback / validation policies
Phase 3: Update implementation (1–2 weeks)
- Upgrading to the target LTS
- Addressing incompatible APIs and dependencies
- Regression verification in tests and CI
- Phased deployment
Phase 4: Validation and stabilization (1 week)
- Operational validation in a production-equivalent environment
- Verifying performance / memory
- Rescanning for vulnerabilities
Phase 5: Continuous maintenance (ongoing)
- Monitoring via EOL calendar
- Periodic dependency and security updates
- Planned migration to the next LTS
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Runtime | Node.js Active LTS | Bun / Deno (depending on requirements) |
| Version control | Volta / nvm / .nvmrc | asdf |
| Vulnerability monitoring | npm audit / Dependabot | Renovate |
| CI | GitHub Actions (multi-version validation) | GitLab CI |
| Containers | Fixed LTS base image | distroless |
| Monitoring | EOL calendar | Referencing endoflife.date |
Which projects need this and which do not
| Projects requiring this | Low-priority projects |
|---|---|
| Core / mission-critical systems operated long-term | Short-lived evaluation environments |
| Strict security requirements | Experiments not exposed externally |
| Maintenance contract exists post-delivery | One-off project ending at delivery |
| Managing across multiple systems | Single small script |
| Looking to avoid risks of unaddressed EOL | Updates can be completed entirely in-house |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Adopted version | LTS and rationale for selection | Agreement on lifespan |
| Update cycle | Policy for annual updates | Staffing structure during updates |
| EOL monitoring | Monitoring for end-of-life | Scope of monitoring |
| Handling compatibility | Handling of incompatibilities | Boundary for additional development |
| Handover | Procedures / runbook | Prerequisites for in-house operation |
| Ongoing maintenance | Vulnerability / dependency updates | Operating costs |
Estimated client-side ROI (assuming business systems / avoiding unsupported software)
| Item | Existing (neglected) | LTS strategy and maintenance | Difference |
|---|---|---|---|
| Vulnerability risk | Exposed due to end-of-life | Prevented via monitoring | Avoidance of critical incidents |
| Emergency response | Hurried migration after EOL | Planned upgrades | Reduction in emergency hours |
| Dependency obsolescence | Frozen due to inability to update | Continuous updates | Curbing technical debt |
| Audit compliance | Inability to explain version status | Explainable via strategy | Improved compliance |
| Annual benefit | — | — | Avoidance of vulnerability incidents + suppression of emergency migration costs |
Even with a commensurate initial investment, it can be amply justified by avoiding a single critical incident caused by neglected end-of-life software.
Five common pitfalls
Pitfall 1: Building production on the latest major release
Its lifespan is unpredictable and unstable. You should choose Active LTS.
Pitfall 2: Not monitoring EOL
It will be neglected unnoticed. Monitor using an EOL calendar.
Pitfall 3: Failing to check dependency compatibility
Updates will break the application. Verify compatibility in advance.
Pitfall 4: Upgrading across multiple major versions at once
Risks become concentrated. Update in phases.
Pitfall 5: Omitting updates from the maintenance contract
This becomes a breeding ground for neglect. Specify continuous maintenance in the contract.
90-day action plan
| Week | Action |
|---|---|
| Week 1 | Version inventory + EOL verification |
| Week 2 | LTS strategy + formulating update plan |
| Week 3〜4 | Upgrade + addressing compatibility |
| Week 5〜6 | Verification + vulnerability rescanning |
| Week 7〜13 | EOL monitoring + launch of routine maintenance operations |
Summary — From "building with the latest and leaving it alone" to "selecting LTS, maintaining, and handing over"
With Node.js shifting to an annual major release cycle, the lifespan of each version has become easier to predict, making long-term version planning straightforward. From the standpoint of supporting system development for clients, our "Runtime LTS Strategy and Maintenance"—which builds on Active LTS, monitors EOL, performs planned updates, and hands over systems backed by maintenance contracts—is a new flagship service delivering secure operations free from neglected end-of-life software as a tangible outcome.
If you have concerns like "Node.js is running past its support period," "we do not know when to upgrade," or "we want continuous monitoring for vulnerabilities," please feel free to reach out via our contact form.
Sources
- Node.js Moves to One Major Release Per Year, Starting with Node 27（InfoQ 2026-06-03）
- Serverless Migration for Clients Using AWS Lambda Web Adapter (GH Media)
- Persistent Workflows for Clients with Postgres / SQLite (GH Media)
- OS Standardization for Clients Using Azure Linux 4 (GH Media)
- IaC Standardization for Clients Using CDK / Terraform (GH Media)
