Node.js 18

Node.js 18 moved the runtime onto V8 10.1 and OpenSSL 3.0, replacing the older V8 and OpenSSL foundations used by Node.js 16. OpenSSL 3 can expose applications, native modules, or build processes that depend on legacy cryptographic algorithms or provider behaviour. This line also made browser-aligned web APIs more readily available: fetch and its related request and response interfaces were enabled globally, backed by Undici, and Web Streams APIs were available globally. These APIs were experimental within Node.js 18, so teams that adopted them need to account for the behaviour and compatibility expectations of a then-experimental implementation. Node.js 18 also introduced the built-in node:test test runner and watch mode as experimental capabilities, reducing the need for third-party tooling in some projects but not making those interfaces a risk-free replacement for established test and watch tooling.

Node.js 18 has reached end of life. It no longer receives upstream security fixes, bug fixes, or compatibility maintenance, including fixes in Node itself and updates to components distributed with the runtime. Remaining on it leaves production services exposed when new runtime, TLS, HTTP, dependency, or JavaScript-engine vulnerabilities are found. It also increases operational friction: packages, frameworks, build tools, and native-addon releases can raise their minimum supported Node.js version, while CI images and platform tooling increasingly concentrate testing on maintained lines. A project may continue to install and run on Node.js 18, but successful installation is not evidence that its dependency set is supported or adequately tested there. The longer a team defers migration, the more likely it is to combine a runtime upgrade with unrelated dependency, operating-system, compiler, and deployment changes, making diagnosis and rollback harder.

Choose a currently supported Node.js line that fits the application's framework and platform requirements, then define it explicitly in local development, CI, container images, deployment manifests, and version-management configuration. Build a representative migration branch and run the full unit, integration, end-to-end, and performance suites on the target runtime. Audit dependencies for engine constraints and native components, including packages that compile during installation or ship prebuilt binaries; update or replace components that do not support the target line. Exercise cryptographic, TLS, certificate, database-driver, HTTP-client, streaming, and file-processing paths in a staging environment, since these are common places for runtime and OpenSSL-related compatibility differences to surface. If the application uses global fetch, Web Streams, node:test, or watch mode introduced in Node.js 18, verify its assumptions against the target runtime rather than treating Node.js 18 behaviour as a permanent contract. Update lockfiles through the normal controlled dependency process, deploy progressively with runtime version telemetry and error monitoring, retain a tested rollback path, and remove Node.js 18 from supported build and production environments once the migration is complete.