For a long time the rule was simple and you could set your watch by it: Node.js released an even-numbered major every April, an odd-numbered one every October, the even ones became LTS and lived for years, and the odd ones quietly went end-of-life within about six months. That model is going away. Starting with Node.js 27, the project is moving to an annual release cycle in which every major version becomes LTS after its Current phase, and odd-numbered lines stop being throwaway.[1]

This matters if you deploy Node on your own VPS, because your upgrade rhythm has until now been shaped entirely by that cadence. If you want to change as rarely as possible, you picked an even LTS line and stayed on it; the odd Current releases were for people who wanted the newest. Under the new scheme, that mental model stops working, and planning upgrades becomes partly about when a release is ready rather than about which number it carries. Here is what actually changes, verified against the official pages on release day.

The cadence you have been living with

To understand what changes, it helps to pin down the old model precisely. The official release notes describe it as: historically, up to Node.js 26, odd-numbered releases became unsupported after six months, while even-numbered releases moved to Active LTS status and were ready for general use.[1]

Concretely, this meant a two-year rhythm for a given line:

  • Even major (e.g. 22, 24, 26): released in April, six months of Current, then promoted to LTS and supported for about 30 months through Active and Maintenance phases.
  • Odd major (e.g. 21, 23, 25): released in October, six months of Current, then end-of-life. Never an LTS candidate.

The result was that two even lines were sometimes supported in parallel, which gave you slack: you could sit on an even LTS while the next even line matured. The odd Current lines existed to give library authors and early adopters somewhere to test new features off the LTS track.

What changes with Node.js 27

The official releases page now reads: “Starting with Node.js 27, the release cycle will be annual and every major version will move to LTS status after its six-month Current phase (and six additional months of Alpha phase)."[1]

Break the sentence down, because both halves matter:

  • Annual release cycle. Majors now come once a year rather than twice. The even/odd alternation, where one release in two was disposable, is gone.
  • Every major becomes LTS. There is no more “odd release dies in six months” path. Whether the number ends in an odd or even digit no longer determines the fate of the line. Every major gets the full LTS treatment.

The support window is the other headline number. The releases page states that LTS status “typically guarantees that critical bugs will be fixed for a total of 30 months."[1] That 30-month guarantee is what you build your deployment planning around: once a line reaches LTS, you can expect critical fixes for 30 months, and only Active and Maintenance LTS releases are the ones the project recommends for production applications.[1]

So the shape of a line’s life becomes: Current, then an Alpha phase, then LTS (Active then Maintenance), with the LTS portion carrying the 30-month support guarantee.

What the current schedule looks like today

The concrete transition is easiest to see in the dates that are already published and stable. As of October 12, 2026, based on the release working group’s schedule:[2]

  • v26 was released May 5, 2026 and is still Current; it moves to Active LTS on October 28, 2026, then to Maintenance October 20, 2027, reaching end-of-life April 30, 2029.
  • v24 (Krypton) was Active LTS until October 20, 2026, when it moved to Maintenance LTS; it reaches end-of-life April 30, 2028.[2]
  • v22 (Jod) is in Maintenance LTS and reaches end-of-life April 30, 2027.

For v27, the release working group has started publishing the annual-cycle schedule for the new line in its machine-readable schedule, and the working group’s own page carries the standing caveat that dates are subject to change.[2] This is the first major scheduled under the new scheme, so treat the transition dates as the project’s current plan rather than a hard commitment until they are locked in and the line actually ships.

What this means right now, on release day: there are multiple supported lines at once, which is exactly what gives you a decision to make when you plan an upgrade. The project explicitly says production applications should use only Active LTS or Maintenance LTS releases.[1] That guidance does not change.

What this means for deploying Node on a VPS

If you self-host Node on a VPS, the practical questions are: how often do I have to upgrade, when do I plan for it, and what happens to security support. Here is the honest read.

You no longer wait two years between “real” releases

Under the old cadence, the releases people actually deployed were the evens, roughly one per year but effectively every two because each saw a long support tail. The annual cycle collapses that: every single major is now an LTS candidate, so a new production-worthy line appears once a year instead of once every two years on the “safe track.” Even if you never adopt Current or Alpha, you are choosing between LTS lines more frequently.

That is not automatically a burden. The cadence change is a capacity change, not a demand change: the project is promising that every annual major gets the same long support tail. For you, update frequency is still largely your own choice, because a 30-month support window means you are never forced to move the day a new major ships.

Plan upgrades against the six-month Current gate

The most useful new discipline is the Current gate. A major is not recommended for production until it has moved out of Current into LTS, which now happens after six months of Current plus the Alpha phase.[1] If your instinct is to stay on a supported production line, the practical rule is: do not adopt a new major on day one. Let it sit through its Current and Alpha period, and target the LTS transition.

That is a shorter gate than before in one sense (every major passes through it now), but identical in another: adopting an odd major in the old world was always a bad idea for production, and the new schedule removes that trap entirely. There is no version of the future where a line is guaranteed to die in six months, because every major gets the full LTS treatment.[1]

Security support is what changes least

The 30-month support guarantee for LTS lines does not shrink.[1] If anything, the new model is a commitment that no annual major is a dead end, so the predictable security-and-critical-bug window stays at 30 months per line once it reaches LTS.

The real security consideration is the gap between Current release and LTS. During Current and Alpha, a line is moving fast and is not what you should run for a service with an exposed port. The project’s own guidance is unambiguous: production applications should use Active LTS or Maintenance LTS.[1] So your security posture still hangs off the LTS lines, and the new annual cadence keeps the supply of those lines steady.

A practical upgrade plan for your self-hosted app

Putting it together, here is a repeatable approach for a Node app deployed on a single VPS:

  1. Stay on an LTS line for anything exposed. As of today that means v24 (Maintenance LTS since October 20, 2026, supported until April 30, 2028) or adopt v26 when it reaches Active LTS on October 28, 2026.[2] v22 is still supported until April 30, 2027 if you need more runway, but it is already in Maintenance, so only critical fixes come in.[2]
  2. Track the Current-to-LTS transitions, not release dates. Watch the release working group schedule for when a line actually reaches Active LTS, and schedule your jump for that moment. For the lines in flight, the May/October milestone markers are the ones that decide when a new major is production-safe.[2]
  3. Do not adopt Current or Alpha for production. New features land and break fast during those phases; the project points production users to LTS lines for a reason.[1] If you want to test the next major safely, spin up a scratch VPS or a container, never your main box.
  4. Re-check version lifecycles before the year rolls over. Because more lines now become LTS, the set of “supported, worth considering” versions changes once a year rather than every two. A quick check of the schedule in your upgrade review keeps you from planning against a line that has already reached end-of-life.

None of this requires learning a new tool or reconfiguring your stack on a VPS. It is a change to your mental model and your calendar, not to how you build or run the app. The binaries, the deployment, the process manager, and the reverse proxy all work exactly as before. What you adjust is when you schedule major upgrades and which number you think of as “the safe one.”

The takeaway

Node.js is not speeding up its releases in a way that forces you to upgrade faster. It is changing which releases live long enough to matter: starting with v27, every annual major gets the full LTS treatment with a 30-month support guarantee after its Current and Alpha phases, instead of only every other release being a keeper.[1]

For a VPS operator, the concrete consequences are modest and manageable. Keep running an Active or Maintenance LTS line for production, plan your major upgrades around the Current-to-LTS transition rather than the release announcement, and re-check the lifecycle schedule once a year. The cadence that used to make every two years feel like a “big” Node upgrade now makes every year one - but with the same long support tail to land on.

Sources

  1. Node.js - “Node.js Releases” (previous releases page; wording: “Historically (up to Node.js 26), odd-numbered releases… become unsupported after six months, and even-numbered releases… move to Active LTS”; “Starting with Node.js 27, the release cycle will be annual and every major version will move to LTS status after its six-month Current phase (and six additional months of Alpha phase)”; “LTS… typically guarantees that critical bugs will be fixed for a total of 30 months”; “Production applications should only use Active LTS or Maintenance LTS releases”; v26 Current, released 2026-05-05, updated 2026-10-07). https://nodejs.org/en/about/previous-releases - checked 2026-10-12
  2. nodejs/Release working group - release schedule and machine-readable schedule.json (v22: maintenance, EOL 2027-04-30; v24 Krypton: Active LTS, Maintenance 2026-10-20, EOL 2028-04-30; v26: Current, Active LTS 2026-10-28, Maintenance 2027-10-20, EOL 2029-04-30; v27: first major under the annual scheme, initial schedule published, dates subject to change). https://github.com/nodejs/Release - checked 2026-10-12