Node.js has three lines worth running on October 28, 2026: Node.js 22 (Jod), Node.js 24 (Krypton) and Node.js 26. The project is also moving to annual major releases, and Node.js 27 is scheduled to enter its Alpha phase today. That timing makes the Node JS LTS question messier than usual, because the line most teams want next sits mid-promotion.
The messy part is the label on Node.js 26. The published schedule puts its move to LTS in October 2026, yet the official release page still tagged 26.12.1 as Current when the October security release shipped. Sources disagree on the exact day, so this guide treats the label on nodejs.org as the final word and tells you how to check it in ten seconds.
Here is the short version. Run Node.js 24.22.1 for production today, keep Node.js 22.23.4 only where a dependency forces it, and test Node.js 26.12.1 in CI now so the move in 2027 is boring. The rest of this comparison backs that call with release data, security advisories, platform signals, a migration guide and a decision table for six common jobs.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Where Node.js LTS Stands on October 28, 2026
Three release lines receive fixes right now. Node.js 22 carries the codename Jod and sits at version 22.23.4. Node.js 24 carries the codename Krypton and sits at 24.22.1. Node.js 26 has no codename on the official release table and sits at 26.12.1. All three versions shipped together on October 21, 2026, as part of one coordinated security release.
The labels matter more than the numbers. LTS stands for long-term support, which means a line gets critical bug fixes and security patches for an extended window. Node.js describes that window as typically 30 months in total. Current is the opposite pole: the newest features, a shorter safety net and a higher chance that a dependency has not caught up yet.
On October 21, the official pages labeled Node.js 24.22.1 and 22.23.4 as LTS and Node.js 26.12.1 as Current. The same schedule that lists those releases also says Node.js 26 enters LTS in October 2026, and its end of life lands in April 2029. A third-party schedule summary and the official release table disagree by about a week on the promotion date, with dates of October 20 and October 28 both circulating.
What should you do with that conflict? Check the machine-readable answer on the build you plan to ship. Run the command below. If it prints a codename, your binary carries an LTS label. If it prints undefined, you are on a Current build.
node -p "process.version + ' ' + process.release.lts"Node.js 24 is the safe read of the situation. Safeguard’s October 23 governance write-up and several other sources point teams to 24 for new production work, with 22 as the compatibility fallback and 26 as the line to test. That guidance matches what the release pages show, and it is the baseline for everything below.
One more status note. Node.js 27 has not shipped. Its Alpha phase is scheduled to begin today, October 28, 2026, and the project says the schedule may still change. Treat any production claim about Node.js 27 as premature until the April 2027 release.
Node.js 22 vs 24 vs 26: Specs Side by Side
The table below sticks to what the official release pages and schedule confirm. Rows marked as analysis reflect our judgment, not a project statement. For single-source details, such as exact first-release dates, the sections that follow hedge them in prose.
| Attribute | Node.js 22 | Node.js 24 | Node.js 26 |
|---|---|---|---|
| Codename | Jod | Krypton | None listed |
| Status label on Oct. 21, 2026 | LTS | LTS | Current (LTS promotion scheduled for October 2026) |
| Latest version | 22.23.4 | 24.22.1 | 26.12.1 |
| Latest release date | Oct. 21, 2026 | Oct. 21, 2026 | Oct. 21, 2026 |
| Part of Oct. 21 security release | Yes | Yes | Yes |
| End of life | Shorter runway than 24 | See schedule (hedged below) | April 2029 |
| Download price | $0 | $0 | $0 |
| Paid tiers listed by project | None | None | None |
| Odd/even release model | Old model | Old model | Last line under old model |
| Production default (analysis) | Only if pinned by a dependency | Yes | Not yet for risk-averse teams |
| Upgrade effort from previous line (analysis) | Baseline | Low to moderate | Moderate, native modules first |
| Best fit (analysis) | Legacy services | New and existing production | CI canaries, greenfield, libraries |
Two rows deserve a closer look. The end-of-life row shows how uneven the public data is. Node.js 26 has a clear April 2029 date in the official schedule. For Node.js 24, a schedule summary reportedly lists April 30, 2028, which fits the 30-month LTS math, but we flag it as single-source. For Node.js 22, OpenJS materials only say its remaining support lifetime is shorter than 24’s.
The price rows read as boring because they are. Node.js is open-source software with no purchase price, and the project lists no paid editions, subscriptions or support plans. Any money you spend on Node.js goes to engineering hours, managed hosting, or a third-party support contract, a point the cost section picks up later.
The New Release Model: One Major a Year, Every Major Becomes LTS
A major structural change landed in March 2026 and received an update on October 21. Starting with Node.js 27, the project moves from two major releases per year to one, published each April. Every one of those majors becomes LTS, with promotion each October. The old rule that odd-numbered releases never reach LTS ends after Node.js 26.
The schedule for Node.js 27 reads as follows: Alpha phase from October 28, 2026, the general release in April 2027, LTS promotion in October 2027, and end of life in April 2030. The project also states that the schedule may be amended, so pin your planning to the next official update rather than to this paragraph. ADTmag covered the shift on October 26 under the headline about annual major releases.
What the Alpha Phase Means for You Today
Alpha is a signal for library authors, tooling vendors and the curious. It is not a signal for production teams. No released Node.js 27 version is confirmed, which is one more reason to test it on its own instead of mixing it into your 26 canary.
Why the Change Helps Planners
Two lines per year created a yearly puzzle: which release gets promoted, which gets skipped, and when does the skipped one die? Under the new model every major gets the same treatment. A team can write a standing policy, such as upgrading to the newest LTS within six months of its October promotion, and apply it every year without reading the calendar.
The tradeoff is fewer shipping windows for new V8 and platform features. Under the old model, a feature could land in a Current release within six months. Under the new one, the next major arrives only in April, and contributors who want something in the release will need to plan around that single date. For application teams that value stability, that is a feature rather than a cost.
Node.js 26: What It Adds and What It Removes
Node.js 26 is the newest major line and the last under the old model. According to Fireup’s October 27 upgrade write-up, 26.0.0 shipped on May 5, 2026 with the Temporal API enabled by default, V8 14.6, and Undici 8.0, plus a set of deprecations and removed APIs. We rely on that single source for the feature list, so check the official changelog before you act on any individual item.
Temporal is the headline for application developers. It is the long-awaited replacement for the Date object, and shipping it on by default removes one reason to carry a date library in new code. Teams that maintain date-heavy code, such as scheduling, billing or calendar products, have the most to gain.
The removals are the headline for upgraders. Any removed API turns into a runtime error in the one code path nobody exercises until a customer hits it. That is why a Node.js 26 trial belongs in your test pipeline long before it reaches production traffic.
The patch cadence also tells a story. Release listings put 26.7.0 on August 5, 26.10.0 on September 22, 26.11.0 and 26.11.1 on October 7, 26.12.0 on October 14, and 26.12.1 on October 21. That is a line shipping something every week in October. Fast releases are healthy for a Current line, but they are also why risk-averse teams wait for the LTS label before adopting.
Where does Node.js 26 stand against the other two on the risk scale? It carries the same fixes as them for the October 21 advisory, since the release series covered all three lines. It carries more recent code and more moving parts. Its support horizon, through April 2029, is the longest of the three, which is the strongest argument for adopting it once the LTS label is confirmed and your dependency tree has caught up.
Node.js 24 Krypton: The Production Default
Node.js 24 is the line most guidance points to for new production services, and the facts back that up. Version 24.22.1 carries the LTS label, received the October 21 security fixes, and has a schedule that reportedly runs to April 30, 2028. Its codename is Krypton.
Node.js 24 also has the widest practical runway among the lines you can adopt without caveats. It is newer than 22, so it starts with more support left. It is older than 26, so the ecosystem has had time to catch up, and cloud platforms have had time to ship managed images. When teams ask which version to pick without a special requirement, 24 is the answer that almost never produces a regret.
The previous patch, 24.22.0, reportedly introduced crypto.parsePKCS12() and a generic MAC API. Version 24.22.1 then superseded it with the security fixes and dependency refreshes. Single-source reports list NSS root certificates at 3.131.1, c-ares at 1.34.9, timezone data 2026e and OpenSSL 3.5.9 in that update. If your image still runs 24.22.0, rebuild it.
The practical lesson is about patch discipline, not just major version choice. A team on an old 24.x patch is worse off than a team on current 22.x. Pinning to a major line without a process for taking patch releases leaves you exposed to exactly the kind of TLS and DNS input bugs listed in the October advisory.
For many teams, the remaining question is not 24 versus 22 but when to stop evaluating. Set a rule: new services start on the newest LTS line that has been LTS for at least one quarter. Today that rule picks 24. In early 2027 it will likely pick 26, assuming the promotion is confirmed.
Node.js 22 Jod: Who Should Stay and for How Long
Node.js 22 remains an officially supported LTS line. Version 22.23.4 shipped in the October security release with the same coordinated security fixes as the other lines, and nothing in the official material suggests a retirement or rename. New projects should generally prefer Node.js 24 LTS unless a dependency or deployment constraint requires 22.
The right reason to stay on 22 is a blocker, not a habit. Three blockers come up most. A native module has no build for Node.js 24 yet. A managed platform or internal base image lags behind. Or a regulated change-control process means a runtime bump takes a quarter to approve. Each of those is a scheduling problem, and each has a deadline attached.
Teams that stay on 22 should do three things. Take every patch release promptly, since 22.23.4 replaced earlier 22.x patches that lack the October fixes. Track the one blocker that keeps you there, with an owner and a date. And run your test suite on 24 in CI so the eventual move carries no surprises.
The wrong reason to stay is fear of change in a service that has good tests. If your suite passes on 24 and your dependencies list it as supported, the move costs a few hours and buys you months of extra support runway. Delay only has a price: each month on 22 moves you closer to a forced upgrade under pressure.
One more point for library maintainers. Keeping 22 in your supported matrix is still reasonable, since your users may stay there. Dropping it is a semver-major decision, and you should announce it with notice rather than slip it into a patch. The new annual cadence will make that kind of matrix pruning more regular, not less.
Security: What the October 21 Release Changed
The October 21, 2026 release was a coordinated security update across Node.js 26.12.1, 24.22.1 and 22.23.4. The official 26.12.1 page lists eight advisory entries, and the first entry carries two CVE IDs, so the page names nine IDs in total. Hostinger’s write-up of the same release counts seven vulnerabilities in its headline, which shows how counting rules differ between sources. The table lists the entries as they appear on the official page.
| CVE ID(s) | Component and fix | Severity |
|---|---|---|
| CVE-2026-106069, CVE-2026-106072 | tls: reject non-canonical IP addresses | High |
| CVE-2026-105482 | dns: validate resolve inputs for null bytes | High |
| CVE-2026-105483 | tls: fix IP normalization regression | High |
| CVE-2026-111497 | deps: Brotli fix cherry-picked | High |
| CVE-2026-105481 | http: ensure agent data guard works without I/O | Medium |
| CVE-2026-106074 | crypto: reset random caches across snapshots | Medium |
| CVE-2026-106070 | zlib: avoid caching invalid ZIP local headers | Low |
| CVE-2026-106073 | permission: check permission model in realpathSync | Low |
Four entries rate High, two Medium and two Low. The High items cluster around input handling in networking code: TLS address parsing, DNS resolve inputs and a bundled Brotli decoder. Those are the code paths that touch untrusted data in almost every Node.js server, so the severity ratings make sense for internet-facing services.
Credit lines on the official page name several well-known contributors, including Matteo Collina, James M Snell, Filip Skokan, RafaelGSS and Evgenii Kliuchnikov. The release also refreshed root certificates to NSS 3.131.1, c-ares to 1.34.9 and Undici to 8.12.2 in the 26.12.1 listing. Which fixes apply to which line depends on the code each line carries, so read the per-line notes in the advisory before you triage.
The security process itself changed this autumn. The OpenJS Foundation’s CVE Numbering Authority took a coordinated break from September 17 to October 6, 2026, citing volunteer burnout tied to a surge of AI-generated vulnerability reports, and returned on October 7. On October 22, the foundation announced that the Sovereign Tech Agency invested in work on when vulnerabilities should be fixed openly. A Q2 2026 foundation update, reported October 27, reportedly describes an 18-vulnerability release, a release process cut from 36 to 7 steps, and an LLM-assisted report classifier.
What does this mean for line selection? It means patch speed will matter more than the badge on your major version. A maintained line that you patch within days beats a newer line you patch within months. Whichever line you choose, wire up an automated check that fails builds on a Node.js patch older than the latest for your line.
Benchmarks and Evidence: What the Data Shows
Here is a plain statement: we found no verified, repeatable benchmark that compares Node.js 22.23.4, 24.22.1 and 26.12.1 on the same hardware, and we will not publish a number we cannot source. A throughput chart without a method is marketing. What the record does support is a set of evidence from three independent sources that bear on the decision.
The first source is adoption. The 2025 Stack Overflow Developer Survey publishes usage data on its technology results page. Node.js is still a near-default tool for web development, which means ecosystem lag hits more teams than almost any other runtime issue.
The second source is the project’s own advisory data. The October 21 security release page lists High, Medium and Low severity entries across the lines. That is the strongest hard evidence that staying on a supported, patched version matters more than the choice between two supported versions.
The third source is platform behavior. AWS Elastic Beanstalk‘s October 22 release notes for Amazon Linux 2023 list Node.js 24.22.1 and 22.23.4, both labeled LTS. Azure App Service for Linux published an emergency Node.js and Python runtime update the same day. Both clouds reacted to the advisory within one day, and both put LTS lines first. If you rely on a managed platform, its supported list is your real menu.
A Reproducible Benchmark Harness
Performance claims should come from your own workload. The script below measures three things that matter to most backends: a CPU-bound loop, JSON parse and stringify throughput, and a short async fan-out. Run it with each version under identical conditions and compare medians, not single runs.
// bench.mjs
import { performance } from 'node:perf_hooks'
const payload = JSON.stringify(Array.from({ length: 20000 }, (_, i) => ({ id: i, name: 'item-' + i, tags: ['a', 'b', 'c'] })))
function time(label, fn, runs = 15) {
const samples = []
for (let i = 0; i < runs; i++) {
const t0 = performance.now()
fn()
samples.push(performance.now() - t0)
}
samples.sort((a, b) => a - b)
console.log(label, 'median ms:', samples[Math.floor(runs / 2)].toFixed(2))
}
time('cpu loop', () => { let x = 0; for (let i = 0; i < 5e7; i++) x += i % 7; return x })
time('json parse', () => JSON.parse(payload))
time('json roundtrip', () => JSON.stringify(JSON.parse(payload)))
const t0 = performance.now()
await Promise.all(Array.from({ length: 5000 }, () => new Promise((r) => setImmediate(r))))
console.log('async fan-out ms:', (performance.now() - t0).toFixed(2))Run it like this on each machine, with the same laptop plugged in, the same background load and no thermal throttling.
for v in 22 24 26; do
echo "== Node $v"
nvm exec $v node bench.mjs
donePublish nothing from a single run. Repeat the loop at least three times and keep the raw output. If one version wins by a margin smaller than the run-to-run spread, call it a tie and decide on support runway instead.
Cost and Pricing: A $0 License, Real Spend Elsewhere
Node.js costs nothing to download. The official release pages list installers, binaries and source archives for Windows, macOS, Linux, AIX and other platforms without a price, and the project shows no paid edition or subscription. That is true for all three lines. The pricing question for a Node.js decision is therefore about the cost around the runtime.
| Cost item | Node.js 22 | Node.js 24 | Node.js 26 |
|---|---|---|---|
| Runtime license | $0 | $0 | $0 |
| Official paid support from project | None listed | None listed | None listed |
| Security patches | Free, shipped Oct. 21 | Free, shipped Oct. 21 | Free, shipped Oct. 21 |
| Engineering cost to adopt (analysis) | None if already there | Low to moderate from 22 | Moderate from 24 |
| Cost of staying put (analysis) | Rises as runway shrinks | Low until 2027 | Lowest long-term |
| Managed platform availability (analysis) | Broad | Broad | Check your provider |
| Third-party support contracts | Vendor-priced | Vendor-priced | Vendor-priced |
The rows marked analysis are our reading of where the money goes. The runtime license row is the only number, and it is $0 for all three.
Engineering time is the real cost. Moving a mature service between LTS lines is usually a few days of work for a small team with good tests, and a few weeks for a large monolith with native modules and a slow release process. Those numbers are experience, not measurement, so treat them as a prompt to estimate your own.
Cost of delay is the second item. Every quarter on an older line shrinks your remaining support window and bunches migrations together. A team that moves one line at a time spends less than a team that waits and jumps two. That logic favors a standing policy over heroic upgrades.
Managed platforms add a third line item. Check which lines your provider offers before you plan. AWS and Azure both patched LTS lines within a day of the October advisory, but provider timelines for Current lines vary, and a Current line that your host does not support is a line you cannot ship.
Six Real-World Signals From the Past Two Weeks
Concrete events from the last fortnight show how the ecosystem is treating these three lines. None of them is a lab test, and all of them are verifiable on the public pages named.
- AWS Elastic Beanstalk, October 22. Amazon’s release notes for Amazon Linux 2023 platforms list Node.js 24.22.1 and 22.23.4, both labeled LTS. A major cloud picked up the October 21 fixes in one day, which tells you the LTS lines are the managed default.
- Azure App Service for Linux, October 22. Microsoft’s App Service team published an emergency Node.js and Python runtime update. The word emergency is the signal: the advisory was serious enough for an out-of-band platform release.
- OpenJS CNA pause, September 17 to October 6. The foundation’s CVE numbering authority took a three-week break, and the October 21 release arrived two weeks after it returned. Expect the security pipeline to stay busy, and plan your patch process around that.
- Brotli CVE-2026-111497, October 22. Safeguard published a patch guide covering servers, container images and apps. The container-image angle matters, because a base image pinned to an older patch stays vulnerable until someone rebuilds it.
- Hostinger’s customer advisory. Hostinger’s October 22 post frames the release as seven new vulnerabilities that need no action from its customers. That is the experience managed hosting sells: the provider patches, and you pay for not thinking about it.
- Stack Overflow’s 2025 survey. With Node.js used by close to half of respondents, any compatibility gap in a popular package affects a large share of developers. That is why ecosystem readiness, not raw runtime speed, usually decides when a Current line becomes safe.
The pattern across all six is consistent. Clouds, hosts and security teams treat the LTS lines as the supported surface and move quickly on them. Current lines get attention from early adopters and library authors. Pick your line to match the support you have, not the support you hope to get.
Use-Case Recommendations: Which Line for Which Job
Here are six common situations and the line we would pick for each. The first four follow directly from the release data. The last two are judgment calls with the reasoning shown.
- New production API or web service. Start on Node.js 24.22.1. It carries the LTS label today, has cloud support, and leaves the longest stable runway among the lines without caveats.
- Existing service on Node.js 22. Take 22.23.4 now, then schedule the move to 24. If a single dependency blocks you, track it with an owner and a date rather than waiting.
- Libraries and npm packages. Test on 22, 24 and 26 in CI. Support the two most widely used lines in your documentation, and decide when to drop 22 by announcing it in a major release.
- Teams that want the longest runway. Plan for Node.js 26, whose end of life is April 2029. Adopt it after the LTS label is confirmed on nodejs.org and your native modules build cleanly.
- Serverless and managed platforms. Use whichever LTS line your provider lists as supported. Provider support lists lag the project, and a runtime your platform cannot run is not an option.
- Containers and CI images. Pin a major tag such as 24, rebuild on a schedule, and fail the build if the patch version is older than the latest for the line. The October Brotli fix lives in the image, not in your code.
For a quick way to match your situation to a line, use the decision table below.
| Situation | Pick | Why |
|---|---|---|
| Greenfield backend, no constraints | Node.js 24 | LTS label, broad platform support |
| Dependency blocks Node.js 24 | Node.js 22 | Supported, shorter runway |
| Want newest APIs such as Temporal | Node.js 26 | Newest features, longest horizon |
| Regulated change control | Node.js 24 | Stable label, predictable patches |
| Library author | All three in CI | Users sit on every line |
| Experimenting with the new model | Node.js 27 Alpha, sandbox only | Not for production |
Teams that fall between rows should default upward in safety, not in novelty. If you cannot decide between 24 and 26, take 24, and add 26 to your CI matrix so you learn about breakage early. You can find more developer tooling comparisons in our software coverage if you are evaluating the rest of your stack at the same time.
Migration Guide: Moving Between Node.js LTS Lines
A line-to-line upgrade is mostly a process problem. The steps below work for 22 to 24 and for 24 to 26 alike. Budget a day for a small service and a sprint for a monolith.
Step 1: Inventory and Baseline
Record the Node.js version on every machine that runs your code: laptops, CI runners, container images and production hosts. Then run your full test suite on the current line and save the results. Without a baseline, you cannot tell a regression from a pre-existing failure.
Step 2: Install the Target Line Side by Side
Use a version manager so you can switch without touching the system install.
nvm install 24
nvm use 24
node -p "process.version + ' ' + process.release.lts"
echo 24 > .nvmrcStep 3: Declare What You Support
Tell your tools and your teammates which versions the project supports. The engines field in package.json documents the range, and a package manager can enforce it when you turn on strict engine checks.
{
"engines": {
"node": ">=24 <27"
}
}Step 4: Rebuild Dependencies and Native Modules
Reinstall from a clean lockfile install, rebuild native addons and watch for build failures first. Native modules are where line-to-line upgrades break most often, because they compile against Node.js internals.
rm -rf node_modules
npm ci
npm rebuild
npm auditStep 5: Run the Matrix in CI
Add the target line next to the current one so every pull request tests both. Mark the newest line as allowed to fail until you trust it, then flip that flag once it passes for a week.
jobs:
test:
runs-on: ubuntu-latest
continue-on-error: ${{ matrix.experimental == true }}
strategy:
fail-fast: false
matrix:
node-version: [22, 24, 26]
include:
- node-version: 26
experimental: trueStep 6: Update Containers
Move your base image to the new major tag and rebuild from scratch rather than layering over a cached image. Pin by digest in production if your policy allows it, and set a rebuild schedule so patch releases reach you without a human remembering.
FROM node:24-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]Step 7: Canary, Watch, Roll Out
Send a small share of production traffic to the new line first. Watch error rates, memory, latency and TLS handshake failures, since the October advisory touched TLS and DNS input handling. Roll forward in stages, and keep the old image available until the new line has run through a full release cycle.
Step 8: Retire the Old Line From Your Matrix
Once production has moved, remove the old line from your CI matrix and your documentation. Leaving stale versions in the matrix costs build minutes and gives readers the wrong idea about what you support.
Watch for three common failure modes. Removed or changed APIs show up as runtime errors in rarely used code paths. Native addons fail to compile until the vendor ships a compatible build. And stricter TLS or DNS validation, as in the October 21 fixes, can break integrations that relied on sloppy inputs. Test integrations with older partner systems early.
Pros and Cons of Each Line
Every line trades something. This table collects the tradeoffs in one place, and the lists after it give the short version for each.
| Line | Strengths | Weaknesses |
|---|---|---|
| Node.js 22 (Jod) | Mature, widely deployed, supported LTS | Shorter remaining runway, no longer the newest LTS |
| Node.js 24 (Krypton) | LTS label, broad platform support, balanced runway | Not the newest APIs, will need its own migration by 2028 |
| Node.js 26 | Newest features, longest horizon to April 2029 | Label still settling, ecosystem catching up, removed APIs |
Node.js 22 wins on familiarity. Teams know its quirks, hosting is everywhere, and nothing about it will surprise an on-call engineer. It loses on runway, and every month you stay increases the size of the eventual jump.
Node.js 24 wins on balance. It is the line with the fewest regrets: supported, patched, recognized by managed platforms and far enough from the edge to have settled. Its weakness is the one every middle child has, which is that it will need a migration of its own before its 2028 horizon.
Node.js 26 wins on ambition. It brings Temporal by default, a newer V8 and the longest runway, and it ends the odd/even era on a high note. It loses on proof: the LTS label needs confirming, fewer production systems have run it for a full quarter, and removed APIs are real work for old codebases.
Verdict: Run Node.js 24 Now, Plan for 26
For production work on October 28, 2026, run Node.js 24.22.1. It carries the LTS label, it received the October 21 security fixes, and it has the clearest combination of platform support and remaining runway. The official guidance and the major cloud platforms point the same way.
Keep Node.js 22.23.4 only where a named blocker forces it, and give that blocker a deadline. The line is supported, but it is the oldest of the three and its runway is the shortest. Teams that stay put should still take every patch, because the October 21 release shows how quickly a High-severity input bug can land.
Test Node.js 26.12.1 now. Add it to your CI matrix as an allowed failure, read the removal list, rebuild your native modules, and check process.release.lts on the build you plan to ship. If the label is LTS and your tests pass, you have the longest runway on the board, through April 2029, and a clean move in the first half of 2027 becomes a planned upgrade instead of a scramble.
Ignore Node.js 27 for production until its April 2027 release. The Alpha phase starts today, the schedule may change, and the new annual cadence means the next major only matters to you once it has had time to settle in the field. Build the habit this autumn: a standing policy, a CI matrix with three versions, and a patch-age check. That habit pays off under any release model.
Frequently Asked Questions
Which Node.js LTS version should I use in October 2026?
Use Node.js 24.22.1 for most new and existing production services. It carries the LTS label, received the October 21, 2026 security fixes, and is widely supported by managed platforms. Choose 22.23.4 only if a dependency or platform blocks 24, and treat 26.12.1 as a test target until its LTS label is confirmed on nodejs.org.
Is Node.js 26 an LTS release?
The published schedule says Node.js 26 enters LTS in October 2026. The official release page still labeled 26.12.1 as Current on October 21, and sources give different promotion dates. Check nodejs.org or run node -p process.release.lts on your build. A codename means LTS, and undefined means Current.
Is Node.js 22 still supported?
Yes. Node.js 22.23.4, codename Jod, shipped in October 2026 as an LTS security release. Take all patches and plan the move to 24.
What changes with Node.js 27?
Node.js 27 is the first release under the annual model. Its Alpha phase starts October 28, 2026, the general release is planned for April 2027, LTS promotion for October 2027, and end of life for April 2030. The project says the schedule may change. Every major release from 27 onward is meant to become LTS, so the odd/even rule ends.
How much does Node.js LTS cost?
The runtime costs $0. The official pages list no paid editions, subscriptions or support plans for Node.js 22, 24 or 26. Your real costs are engineering time, managed hosting and any third-party support contract you choose to buy.
Did the October 21 security release affect all three lines?
Yes. The Node.js project published coordinated updates for 26.12.1, 24.22.1 and 22.23.4. The 26.12.1 page lists eight entries, four High, two Medium and two Low. Read the per-line notes in the advisory to see exactly which fixes apply to your version.
Should I upgrade right now or wait?
If you run an old patch of any line, upgrade to the latest patch today. For a major-line move, plan it instead of rushing it. Add the target line to CI this week, fix the failures you find, and schedule the production move for a quiet release window. Waiting is fine for a stable service, but waiting with no plan is how teams end up in forced upgrades.
Can I use Node.js 26 in production today?
You can, but it is a judgment call. Teams that need Temporal or the longest support horizon, and that have strong test coverage and clean native builds, can run it. Teams that prefer proven stability should stay on 24 until the LTS label is confirmed and the ecosystem has had a quarter to settle.
