- The first Node.js 27 alpha, published October 29, changes the default memory limit, a serialization format and the OpenSSL requirement, and removes older crypto support.
- The release notes tell teams whose services relied on the old memory behaviour to set a limit explicitly. WebPulse's reading is that other changes also need testing.
- Test the alpha in staging, set memory limits explicitly and ask vendors about FIPS and engine use. It is a pre-release.
Upgrades break on what nobody chose
A runtime upgrade rarely fails where teams look. It fails in the things nobody decided: inherited settings, hidden formats and old components. The first alpha of Node.js 27 shows the range. Its release notes, published October 29, change a few defaults, one data format and the cryptography requirements.
This is an alpha, a pre-release build meant for testing. It is not a production recommendation. The value for a manager is in preparing early.
Memory: the limit now follows the machine
Node.js 27 updates its JavaScript engine, V8, to version 15.6.75.13. Node.js 26 shipped V8 14.6. According to the Node.js project, a service with no explicit heap limit now gets half of the machine's physical memory. That figure is held between 256 MB and 4 GB.
The notes also say memory held by Buffer and ArrayBuffer objects now counts toward that limit. These objects hold raw data such as file contents and network payloads. The notes advise teams whose services leaned on the old memory behaviour to pin the limit with the --max-old-space-size option.
The notes do not state the previous default. So we cannot say whether the limit rises or falls on any given server. On a large machine the 4 GB ceiling applies. Small machines may land somewhere else. WebPulse's reading is that teams should measure real memory use on their own hardware rather than assume.
Data: a new format older releases cannot read
The notes say v8.serialize(), structuredClone() and postMessage() now use a new format. Older Node.js releases cannot read it. This is a format change, not a setting. It matters wherever two Node.js versions run side by side and exchange serialized data.
The notes add a second change. The version tag for cached compiled code, and the compile cache itself, now shift with each Node.js patch to V8. Before, they shifted only when V8 changed version. Caches built under one patch may stop matching the next.
Encryption: older OpenSSL support is removed
The commit list shows a broad cleanup of cryptography. Node.js 27 requires OpenSSL 3 or later and removes the bundled FIPS provider build. It ends OpenSSL engine support and removes legacy OpenSSL code paths. The bundled OpenSSL moves to version 4.1.0.
Two terms need a plain explanation. An OpenSSL engine is a plug-in that lets OpenSSL hand cryptographic work to custom or hardware code. The FIPS provider is the OpenSSL 3 component that carries the algorithms for US government FIPS-approved mode. Anyone who builds Node.js against a system copy of OpenSSL now needs version 3 or later.
The source does not say whether FIPS mode still works through a system OpenSSL. It does not mention FIPS validation or compliance at all. WebPulse's reading is that teams relying on FIPS or custom engines should not assume either way. Ask your vendor or compliance owner to confirm.
Several crypto functions also become stricter. The list includes checks on input and output encodings, and an error when a Diffie-Hellman computeSecret runs without initialization. Code that was sloppy but worked may start to fail.
Smaller shifts that still show up in production
Maths functions now rely on LLVM's libm library, so results may differ in the last bit of the result. Math.random() sequences also change when a fixed --random-seed is used. Tests with fixed seeds, and numerically sensitive calculations, are where this would show.
Reading error.stack no longer falls back to a parent object in the prototype chain. Sorting large arrays now uses an algorithm called PowerSort and stays stable. Capturing a heap snapshot now takes roughly double the time and produces a file roughly double the size. The snapshots also include full script sources. WebPulse's view is that teams should treat those files as sensitive. The notes do not make that point.
On HTTP, responses whose headers exceed the limit are now rejected. The default keep-alive timeout rises to 65 seconds. The notes do not give the earlier value. Nearly every item in the list is labelled semver-major, so the label alone does not tell you which changes matter. The list is a raw commit log, not a ranking by risk. Intel macOS support drops to experimental, and the Intel binary is listed as coming soon.
What to ask your engineering team
Start with five questions. Do we set a heap limit explicitly on every service, and what does each use today? Which services pass serialized data between Node.js versions? Do we depend on a FIPS build or OpenSSL engines, and has our vendor confirmed a path? Can staging run the alpha under realistic load? Who owns the upgrade decision?
Ask for written answers before the stable release, not after. The Node.js notes list the changes. Working out which ones touch your systems is your team's job.
An upgrade is a list of decisions someone else made for you. Reading that list early costs far less than finding it in an incident.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Node.js.
Follow this story: every update on Node.js security releases
