Node compatibility
Nimbus’s Node.js runtime compatibility is evidence-backed and deliberately bounded: a surface is documented as supported only when it has checked-in fixture, canary, oracle, or classification evidence. This page is the contract — the supported Node versions, the vocabulary behind every support claim, and the headline numbers.
Supported Node versions
Section titled “Supported Node versions”| Target | Status | Release phase | Default | LTS support | Upstream line |
|---|---|---|---|---|---|
| Node20 | Supported for local development only | EOL legacy | no | no | v20.20.2 |
| Node22 | Supported in process | Maintenance LTS | no | yes | v22.22.3 |
| Node24 | Supported in process | Active LTS | yes | yes | v24.16.0 |
| Node26 | Supported in process | Current non-LTS | no | no | v26.2.0 |
- Node24 is the default compatibility target. The default is a routing default, not an evidence priority.
- Node22 and Node24 are the supported LTS targets, each with its own per-version evidence.
- Node20 remains selectable as a legacy-grace target after its 2026-04-30 end of life, but it is not an active LTS support target.
- Node26 is selectable as a Current/non-LTS compatibility target. It becomes an LTS support target only after Node itself enters LTS and the same evidence gates pass.
What “supported” means
Section titled “What “supported” means”| Status | Meaning |
|---|---|
| Supported in process | Passes production in-process application canaries on the supported LTS versions and may back public support claims. |
| Supported for local development only | Useful for local tooling or development but excluded from production in-process support claims. |
| Service/microVM required | Supported only when explicitly routed to a service or microVM profile with host authority. |
| Import-compatible stub | Module import may succeed for package probing, but runtime use throws a clear Nimbus diagnostic. |
| Unsupported | Rejected with a documented diagnostic and no support claim. |
| Not applicable to functions | CLI, interactive, daemon, or process-wide behavior that does not map to function invocation. |
The contract
Section titled “The contract”- Convex-compatible
"use node"action modules can select Node20, Node22, Node24, or Node26 throughconvex.json— see configuration. - Selecting a Node version does not grant host access. Runtime permission mode and explicit grants are a separate axis from the compatibility target.
- Nimbus does not claim full Node built-in compatibility for any version.
- Runtime support is narrower than Node CLI parity:
node --test, the inspector, worker threads, child processes, native addons, and other host-heavy behavior are service/microVM-routed unless the Node API reference says otherwise.
Evidence summary
Section titled “Evidence summary”As of 2026-05-28, from the checked-in evidence snapshots. Fixtures are official upstream Node test files executed against the Nimbus runtime; canaries are real packages and application scenarios exercised end-to-end.
Official fixture results
Section titled “Official fixture results”| Target | Upstream | Fixtures | Passed | Expected failure / known gap | Skipped / excluded | Pass rate | Classified coverage |
|---|---|---|---|---|---|---|---|
| Node20 | v20.20.2 | 1308 | 902 | 401 | 5 | 69.0% | 100.0% |
| Node22 | v22.22.3 | 4748 | 1000 | 3728 | 20 | 21.1% | 100.0% |
| Node24 | v24.16.0 | 5198 | 1002 | 4149 | 47 | 19.3% | 100.0% |
| Node26 | v26.2.0 | 5578 | 0 | 5529 | 49 | 0.0% | 100.0% |
How to read these numbers:
- The fixture corpora are the vendored official upstream Node test suites. Much of each suite exercises CLI, daemon, and process-wide behavior that is intentionally out of scope for in-process function invocation, so the pass rate is not a percentage of the supported surface.
- Every non-passing fixture is explicitly classified as an expected failure, a known gap, or a skip — 100% classified coverage means no fixture result is unaccounted for. Classifications are recorded boundaries, not support claims.
- Node26 is an early Current-line target: its corpus is vendored and fully classified, and its support claims currently rest on canary evidence rather than fixture passes.
Canary results
Section titled “Canary results”- 37 package and framework canary claims across 101 checks, all passing on their required versions.
- 11 diagnostic canary claims proving host-heavy denials and service routes produce the intended errors.
- 0 required canary gaps.
The per-package breakdown is in the Node package reference, and the API-family breakdown is in the Node API reference.
Related pages
Section titled “Related pages”- Node.js runtime overview — using the Node runtime in your functions.
- How the Node runtime works — the model behind the contract.