FAQs

Node.js 24 (Active LTS), latest patch 24.18.0 as of this writing.

Yes during the Maintenance LTS window (through April 2027). Prefer Node 24 for new services.

Odd majors (23, 25) are "Current" - shorter support, more churn, and not covered by typical enterprise LTS policies.

Roughly every few weeks for security and bug fixes. Subscribe to nodejs-security announcements.

Active LTS backports V8 updates with new language features. Maintenance LTS is conservative - mostly fixes.

Node 20 reached End-of-Life. Upgrade to Node 22 (temporary) or Node 24 (target).

Check https://nodejs.org/en/about/previous-releases or the schedule.json in the Node.js GitHub repository.

Pin the full patch (24.18.0) or a digest for reproducibility. Floating 24 tags drift on every patch release.

Partially - but you still choose the runtime version in config. Verify it maps to Active or Maintenance LTS.

Node bundles OpenSSL; LTS patches include OpenSSL security updates. Running EOL Node means stale TLS primitives.

Possible but costly. Standardize on one Active LTS per org; allow Maintenance only during a timed migration.

Adopt each new Active LTS within 6 months of promotion. Exit Maintenance LTS at least 3 months before EOL.

Version drift is the root cause of most "works locally" incidents - wrong APIs, failed native builds, and unmatched security patches.

New services should use ESM on Node 24. CJS is legacy maintenance - exceptions need an ADR and sunset date.

Many libraries (Express in production mode, some log formatters) still branch on it. Set explicitly - do not rely on absence.

>=24.18.0 <25 for Node 24 Active LTS. During migration, document a temporary dual-range with an expiry date.

Treat critical/high severities as blockers. Fundamentals list focuses on runtime; see Security section for full policy.

Orchestrators may restart pods with stale images. Health output proves the running binary matches the intended patch.

Module-level singletons (DB pool, config) are fine. Per-request data on globals is not - use AsyncLocalStorage.

Add to .npmrc:

engine-strict=true

Allowed if production stays pinned Node 24 and CI tests against the production runtime - not dev-only shortcuts.

Every release candidate and within one week of any Node security advisory affecting your major line.

No. This list covers fundamentals; pair with Event Loop Best Practices for async performance.

status, node version, and build/git SHA. Optional: ltsPolicy field from your version gate script.

JavaScript execution within a single Node process is single-threaded - your callbacks all run on one thread. libuv uses additional threads internally (its thread pool, plus OS-level async handling), but none of that JavaScript-visible work runs in parallel with your code.

libuv is the C library that gives Node its event loop, cross-platform async I/O (wrapping epoll/kqueue/IOCP), timers, and a thread pool for the handful of operations with no async OS equivalent. V8 runs your JavaScript; libuv is what makes that JavaScript able to do non-blocking I/O at all.

Every request handler in a Node process shares the same single JavaScript thread. A synchronous, CPU-bound section of code - a big loop, a large JSON.parse - occupies that thread completely, so no other handler's callback can run until it finishes, even if those other requests were otherwise ready to complete instantly.

One thread runs your JavaScript. libuv additionally runs a thread pool (four threads by default, configurable via UV_THREADPOOL_SIZE) for operations like some fs calls, crypto.pbkdf2, DNS lookups, and zlib - plus whatever threads V8's garbage collector and the OS use internally.

No. await pauses the current function and returns control to the event loop. When the awaited operation finishes, its continuation is scheduled as a microtask that runs on the same original JS thread - no new thread is created for the await itself.

V8 is just the JavaScript engine - the same one Chrome uses - and knows nothing about files, sockets, or servers. Node is V8 plus libuv (event loop, async I/O, thread pool) plus built-in modules (fs, http, crypto, …), the module loader, and npm - the pieces that turn "a JS engine" into "a server runtime."

Load balancing distributes requests across processes (or machines), but within a single process every request still shares one JS thread. A CPU-bound loop on that thread blocks all requests currently routed to that specific process - the fix is offloading the work (worker_threads), not just adding more load-balanced instances, unless you also route around the affected process.

• worker_threads - CPU-bound JavaScript that needs to stay in the same process and can share memory via SharedArrayBuffer.
• cluster - using multiple cores for HTTP traffic on a single machine, with each worker as its own independent process.
• child_process - running a separate program or a different runtime entirely, where full OS-level isolation is worth the overhead.

Not at the core level - both still run JavaScript on a single thread per process with a non-blocking I/O event loop. The differences are mostly tooling, startup performance, and built-in APIs, not the underlying concurrency shape.

Main-thread blocking (a synchronous loop) shows up as CPU pegged near 100% with everything stalled. Thread-pool saturation (too many concurrent pbkdf2/fs/zlib calls) shows up as requests silently queueing behind the pool's fixed size, often with CPU looking normal - the symptoms point to different fixes.

import { monitorEventLoopDelay } from 'node:perf_hooks';
const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();

Sample h.percentile(99) on an interval and ship it to your metrics pipeline - a rising p99 event-loop delay is one of the earliest signals that something synchronous is stalling the process, often before error rates move.

No - Node 24 ships a newer V8, a stable built-in fetch, and an improved node:test, but the V8-plus-libuv-plus-single-JS-thread architecture is the same one Node has used since its earliest releases.

Non-blocking I/O is a strong default for high-concurrency, I/O-bound workloads - APIs, reverse proxies, streaming, real-time gateways - because idle connections cost almost nothing while waiting. Runtimes that default to a thread (or process) per request instead pay memory and scheduling overhead for every idle connection, which shows up as a lower practical concurrency ceiling on the same hardware.

Visit https://nodejs.org/docs/latest-v24.x/api/index.html or run node -p "process.version" and match the major in the version picker.

An environment variable enabling internal Node tracing. Common values: module, esm, http, net. Output goes to stderr.

Run with node --trace-warnings or set NODE_OPTIONS=--trace-warnings.

A JSON file with stack, heap, uv handles, and environment snapshot. Triggered on fatal errors or via SIGUSR2 when configured.

In the Node.js CHANGELOG on GitHub and in release blog posts for each major. Search for "Semver-Major".

NODE_DEBUG=esm shows import decisions. Also read package.json exports.

Search issues first. Open a new issue with reproduction version (node -v), platform, and minimal repro script.

Treats pending deprecations as active warnings - useful when preparing for the next major upgrade.

Run the same script on both versions with fnm exec 22.23.1 -- node script.mjs and fnm exec 24.18.0 -- node script.mjs.

node:fetch is documented under Web-compatible APIs. MDN covers API shape; Node docs cover Node-specific options.

https://nodejs.org/en/blog/vulnerability and the nodejs-sec mailing list.

Node.js 24.18.0 (Active LTS) for new deployments. Node 22.23.1 (Maintenance LTS) is acceptable during migration but plan to upgrade before maintenance ends.

Both swap Node versions via shell hooks. fnm is faster (written in Rust) and supports the same .nvmrc file format.

Yes. Commit .nvmrc or .node-version so every developer and CI job resolves the same version.

Add a volta section to package.json:

"volta": { "node": "24.18.0", "npm": "10.9.0" }

Volta switches automatically when you enter the project directory.

When engine-strict=true in .npmrc, npm refuses to install if the running Node/npm does not satisfy engines.

Yes. corepack enable activates the package manager version declared in packageManager field:

"packageManager": "pnpm@9.15.0"

Match CI to .nvmrc:

- uses: actions/setup-node@v4
  with:
    node-version-file: '.nvmrc'

fnm, nvm-windows, and Volta all support Windows. Document one canonical tool in the team README.

No for production. Odd releases are "Current" and short-lived. Use Active LTS (even numbers) for services.

npm list -g --depth=0

Prefer project-local devDependencies over globals for reproducibility.

Alpine uses musl libc - some native addons need extra build steps. bookworm-slim (Debian) is safer for native modules.

Upgrade dev machines and CI first, run the test suite, check deprecated API warnings with NODE_OPTIONS=--pending-deprecation, then roll production.

Yes in Node 24. You can await fetch(...) directly at the prompt without an async wrapper.

Start with node --env-file=.env (Node 20+). Variables appear on process.env immediately.

The built-in REPL is JavaScript. Use npx tsx for a TypeScript-aware REPL.

-p evaluates and prints the expression (implies -e). node -p "2+2" outputs 4.

Press .break or Ctrl+C twice. .break aborts without killing the REPL session.

~/.node_repl_history by default. Set NODE_REPL_HISTORY to change the path.

In a project with "type": "module", use await import('pkg') instead of require.

After a thrown error, _error references it. console.error(_error) prints the stack.

No. Never open REPL on production servers - use read-only logs, metrics, and local reproduction instead.

Yes via NODE_REPL_HISTORY, custom repl servers, or programmatic repl.start({ prompt: 'api> ' }).

Copy the validated logic into a node:test file and replace manual console.log assertions with assert.equal.