Node.js development company: 5 dates that decide your 2026 backend

Summary. Node.js 20 stopped receiving security patches on 30 April 2026. Node.js 24 leaves Active LTS on 20 October 2026, Node.js 22 reaches end of life on 30 April 2027, and Node.js 26 runs until 30 April 2029. On 29 July 2026 the project shipped 11 CVEs across the 26.x, 24.x and 22.x lines, 3 of them rated High. Meanwhile the Internet Bug Bounty pool that paid Node.js researchers was withdrawn, so vulnerability reports now earn $0. Most buyers evaluating a Node.js development company ask about frameworks. The expensive questions are about version support, and they have dates attached.

The runtime itself is stable and well-run. What changes in 2026 is the support calendar underneath it, the way TypeScript runs, and where package installation executes code. A partner who cannot answer for all three will hand you a codebase that is fine on delivery day and unpatchable eighteen months later.

The five dates that set your 2026 Node.js scope

These come from the Node.js Release Working Group's published schedule, which is the authoritative record rather than any vendor blog.

Node.js 24 is the version most production systems should be on today, at 24.19.0 as of 3 August 2026. It has roughly two months left in Active LTS and then eighteen months of maintenance. Node.js 26 reached 26.7.0 on 5 August 2026 and becomes the long-lived target once it enters LTS in October.

The 22.x line matters more than its status suggests. It is in maintenance, receives critical fixes only, and expires in eight months. A partner proposing a greenfield build on Node.js 22 in August 2026 is proposing a migration you will pay for twice.

Node.js 27 changes the upgrade rhythm, permanently

From version 27 the project moves to one major release per year instead of two, and the odd/even distinction disappears. Every release becomes LTS. The Node.js Release Working Group published the new cadence in March 2026:

Node.js 27 alpha begins in October 2026, ships as Current in April 2027, enters LTS in October 2027 and expires in April 2030. Total support is 36 months from first Current release. The practical effect is that upgrade planning gets simpler and later versions get longer runway, which is worth writing into a maintenance agreement now rather than renegotiating in 2027. The project's own summary is blunt: if you already upgrade only to LTS versions, little changes beyond version numbering.

For the fuller argument on how this reshapes upgrade budgeting, see our analysis of the Node.js one release per year cadence.

The AWS deprecation dates most write-ups get wrong

Here is a concrete example of why primary sources matter when scoping this work. Multiple secondary write-ups state that AWS Lambda blocks updates to Node.js 20 functions from July 2026. The AWS Lambda Developer Guide says otherwise.

nodejs20.x was deprecated on 30 April 2026. AWS blocks new function creation on 1 February 2027 and blocks updates to existing functions on 3 March 2027. AWS extended both beyond its standard 30-day and 60-day intervals, and says so directly in the documentation: it has delayed the block dates "in response to customer feedback to give you more time to upgrade your functions."

Two things follow. First, if you are on nodejs20.x you have until March 2027 to change a single line of configuration, not until last month, and a partner who told you otherwise scoped an emergency you did not have. Second, the reprieve is only about deployment. AWS is explicit that deprecated runtimes are "provided 'as-is', without any warranties, and may contain bugs, errors, defects, or other vulnerabilities," and that responsibility for patching them transfers to you at the deprecation date. The function still runs. Nobody is fixing it.

Note also that the nodejs26.x Lambda runtime is in public preview and is not covered by the Lambda service level agreement or technical support. AWS lists general availability as a November 2026 target. Anyone proposing Node.js 26 on Lambda for a production workload this quarter is proposing an unsupported configuration.

TypeScript now runs without a build step, up to a point

Node.js strips TypeScript types natively, and this became stable in 24.12.0 and 25.2.0. Node replaces type annotations with whitespace and runs the result, so line numbers survive and no source maps are needed. For a service that previously carried tsc or a bundler purely to run in production, that is a real reduction in build surface.

The limits are sharp, and they are where migrations stall:

• Node.js does not read tsconfig.json, so path aliases and downlevel compilation do not work.
• enum declarations, namespace blocks containing runtime code, parameter properties and import aliases all fail with ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX.
• Decorators are a TC39 Stage 3 proposal and are not transformed, so they produce a parser error.
• .tsx files are unsupported, and Node refuses to strip types inside node_modules.
• No type checking happens at runtime. You still need tsc --noEmit in CI.
• Node.js 26.0.0 removed the --experimental-transform-types flag entirely, which was the escape hatch teams used for enums and namespaces.

That last item is the one to raise in a technical evaluation. A codebase that leaned on --experimental-transform-types does not merely warn on Node.js 26. It stops. The project recommends TypeScript 5.8 or newer with erasableSyntaxOnly and verbatimModuleSyntax set, which catches the unsupported syntax at compile time instead of at three in the morning. We go through the migration mechanics in detail in our guide to Node.js native TypeScript type stripping.

Package installation stopped executing code by default

npm 12 blocks dependency install scripts by default. preinstall, install, postinstall and prepare are skipped for any dependency without a matching entry in an allowScripts field in your package.json, and the install ends with a list of what it skipped. npm approve-scripts manages that field, writing version-pinned entries such as pkg@1.2.3 by default.

# See what is still unreviewed
npm approve-scripts --allow-scripts-pending

# Approve specific packages, pinned to the reviewed version
npm approve-scripts canvas sharp

This matters because the lifecycle hook is how the 2026 npm compromises delivered payloads. Microsoft Threat Intelligence documented the Mastra framework compromise in June 2026 as a postinstall payload attributed to the actor it tracks as Sapphire Sleet. Blocking those hooks closes the install-time window.

It does not close the execution-time window, and any partner who says otherwise is selling comfort. Node.js has a permission model behind --permission, but the project is careful about what it claims: it is a "seat belt" that stops trusted code from touching what it should not, and it explicitly "does not provide security guarantees in the presence of malicious code." That is the project's own language, not a critic's. The 29 July 2026 release included three separate permission model bypasses, one rated High, where radix-tree prefix handling over-granted filesystem access across allowlist boundaries.

Two things belong in any 2026 Node.js delivery standard:

1. Trusted publishing for anything you publish. OIDC-based publishing from GitHub Actions, GitLab CI or CircleCI removes long-lived npm tokens entirely, and generates provenance attestations automatically on GitHub Actions and GitLab. It needs npm CLI 11.5.1 or later and Node.js 22.14.0 or higher. Self-hosted runners are not yet supported.
2. --permission-audit before enforcement. Audit mode, which landed in April 2026, emits permission checks through the diagnostics channel without blocking anything, so you can build a grant set from observed behaviour instead of guessing. permission.drop() followed in May 2026 and lets a process shed permissions after startup.

The wider governance picture is worth knowing when you assess risk. The OpenJS Foundation's CNA published 3 CVEs in the second half of 2025 and 49 in the first half of 2026, with roughly 10 more pending. That jump reflects AI-assisted scanning surfacing candidates faster than manual research, not a collapse in code quality: on Express and Lodash, 70 to 90% of incoming reports are rejected as invalid. Node.js security reports spiked 4.6 times in February 2026 after agent-assisted scanning tools arrived, and March 2026 brought 65 reports in a single month.

What to ask a Node.js development company

Ask these five, and listen for dates rather than adjectives.

1. Which Node.js line will this ship on, and when does it expire? The only defensible answers in August 2026 are Node.js 24 now, or Node.js 26 with a stated cutover after it enters LTS on 28 October 2026.
2. What happens at the LTS boundary? Node.js 24 leaves Active LTS on 20 October 2026. You want a named upgrade window in the contract, not goodwill.
3. Where does TypeScript get type-checked? If the answer is "Node runs it", the codebase has no type checking. tsc --noEmit belongs in CI.
4. How are install scripts governed? An allowScripts policy with pinned entries, reviewed at each dependency bump, is the current standard.
5. Who patches this in month 14? Node.js publishes security releases on a rolling schedule, and the end-of-life rule is unambiguous. As the Node.js Project put it in its 29 July 2026 advisory: "It's important to note that End-of-Life versions are always affected when a security release occurs."

On that last point, commercial extended support for end-of-life Node.js lines exists through the OpenJS Ecosystem Sustainability Program, with HeroDevs and TuxCare listed as partners. Neither publishes a price. Treat unpublished pricing as a planning risk, because you cannot budget an option you cannot quote, and build the upgrade into the roadmap instead of holding extended support as a fallback.

What we build, and how we scope it

eCorpIT builds Node.js API and real-time backends: HTTP and WebSocket services, event-driven workers, integration layers between existing systems, and the deployment pipeline around them. Founded in 2021 and based in Gurugram, we work as senior-led engineering teams rather than staffing pools, and we are CMMI Level 5, MSME certified and ISO 27001:2022 certified. We are an AWS, Microsoft and Google partner, which matters here mainly because runtime deprecation on managed platforms is where Node.js schedules turn into deployment deadlines.

Our delivery sequence on a Node.js engagement runs in five steps:

1. Runtime and dependency audit. Current Node.js line, its expiry date, managed-runtime block dates on AWS, Azure or GCP, the install-script surface, and whether TypeScript is checked anywhere. This produces a dated risk list, not a score.
2. Architecture and contract design. Service boundaries, API contracts, data access and the concurrency model. Node.js handles high connection counts well and CPU-bound work badly, and that split decides the shape.
3. Build in reviewed increments. Working software each sprint, with tsc --noEmit, dependency review and an allowScripts policy enforced in CI from the first commit.
4. Hardening and deployment. Trusted publishing for any packages you own, --permission-audit before enforcement, structured logging and the runtime upgrade path documented with its dates.
5. Maintenance with named dates. An upgrade window tied to the published LTS calendar rather than to whoever notices first.

Engagement runs one of two ways: a scoped project with a fixed delivery plan and milestone billing, or a monthly retained team sized to the roadmap. We quote after the audit in step 1 rather than before it, because the runtime and dependency position is what determines whether a piece of work is three weeks or three months. The audit is small, fixed-scope and stands on its own, so you can take its output elsewhere if you want. Talk to us through /contact-us/ and we will scope that first.

We also handle the adjacent work, when an existing estate is the actual problem rather than the new service: see API integration and modernization. For runtime selection on a genuinely new backend, our Bun vs Node.js backend runtime decision analysis covers when Node.js is not the answer, and the broader platform context sits in our Interop 2026 web platform developer guide.

India-specific considerations

Two points change the calculus for Indian teams and for anyone processing Indian users' data.

Under the Digital Personal Data Protection Act 2023, a data fiduciary carries an obligation to protect personal data with reasonable security safeguards. Running an end-of-life runtime is hard to defend as reasonable when the maintainer publishes the expiry date years in advance and states plainly that end-of-life versions are affected by every security release. Version currency carries a compliance weight here, on top of the engineering case.

Second, region availability affects the deprecation runway. AWS states that in new regions, Lambda will not support runtimes scheduled to be deprecated within the next six months. Teams deploying into newer Indian or regional availability zones may find a runtime they use elsewhere is simply not offered, which converts a planned upgrade into a prerequisite. Check runtime availability per region before committing to an architecture, not after.

We design applications aligned with DPDP requirements, and we design aligned with SOC 2 and PCI DSS requirements where a client's obligations call for it.

FAQ

Which Node.js version should a new project use in August 2026?

Node.js 24, currently at 24.19.0, is the Active LTS line and the safe default. It leaves Active LTS on 20 October 2026 and reaches end of life on 30 April 2028. Node.js 26 becomes the longer-lived target once it enters LTS on 28 October 2026, running until 30 April 2029.

Is Node.js 20 still safe to run in production?

No. Node.js 20 reached end of life on 30 April 2026 and receives no further security patches. The Node.js project states that end-of-life versions are always affected when a security release occurs. The 29 July 2026 release fixed 11 CVEs across supported lines, three rated High, and none of those fixes reach version 20.

When does AWS Lambda stop letting me update Node.js 20 functions?

AWS blocks updates to existing nodejs20.x functions on 3 March 2027, and blocks creating new ones on 1 February 2027. AWS extended both beyond its usual 30 and 60 day intervals after customer feedback. Invocations are never blocked, but the runtime receives no patches after 30 April 2026.

Do I still need a TypeScript build step with Node.js 24 or 26?

Not for running code, since type stripping became stable in 24.12.0 and 25.2.0. You still need type checking, because Node performs none at runtime. Run tsc --noEmit in CI. Enums, namespaces with runtime code, parameter properties and decorators are unsupported and will fail outright.

What changes for Node.js users from version 27?

Node.js moves to one major release per year in April, every release becomes LTS, and the odd and even distinction ends. Version 27 enters alpha in October 2026, ships in April 2027 and expires in April 2030. LTS lasts 30 months and total support runs 36 months from first Current release.

How does npm 12 change dependency security?

npm 12 blocks dependency install scripts by default. Lifecycle hooks are skipped unless the package appears in an allowScripts entry in your package.json, managed with npm approve-scripts. This closes the install-time attack path used in the June 2026 Mastra compromise, though execution-time risk remains open.

Does the Node.js permission model make my application safe?

No, and the project says so. The documentation describes it as a seat belt that prevents trusted code from unintentionally exceeding its access, and states it provides no security guarantees against malicious code. The 29 July 2026 release fixed three permission model bypasses, one rated High.

What should a Node.js maintenance agreement actually specify?

Named upgrade windows tied to the published LTS calendar, the managed-runtime block dates for your cloud provider, an allowScripts review at every dependency bump, and type checking enforced in CI. Dates beat intentions, because the Node.js release schedule is published years ahead and does not move for anyone.

How eCorpIT can help

We scope Node.js work from a dated runtime audit rather than a feature list, because the support calendar is what decides whether a backend stays maintainable past its first year. Our senior-led teams build and harden Node.js API and real-time services, and we hold CMMI Level 5, MSME and ISO 27001:2022 certifications. If you are choosing between Node.js 24 now and Node.js 26 after October, or you are carrying a version 20 estate with a March 2027 deadline on it, we can map the path and its dates. Start at /contact-us/.

References

1. Node.js Release Working Group release schedule - authoritative release, LTS and end-of-life dates for all lines.
2. Evolving the Node.js Release Schedule - Node.js project announcement of the one-release-per-year model from version 27.
3. Wednesday, July 29, 2026 Security Releases - the 11 CVEs and the end-of-life statement quoted above.
4. Modules: TypeScript, Node.js v26.7.0 documentation - type stripping stability history and unsupported syntax.
5. Permissions, Node.js v26.7.0 documentation - the permission model's stated scope and limits.
6. Security Bug Bounty Program Paused Due to Loss of Funding - Internet Bug Bounty withdrawal, April 2026.
7. Lambda runtimes, AWS Lambda Developer Guide - runtime deprecation and block dates, shared responsibility model.
8. OpenJS Foundation Security Update: Q2 2026 - CNA CVE counts, audit mode, report volume figures.
9. npm approve-scripts, npm CLI v12 documentation - default install-script blocking and the allowScripts field.
10. Trusted publishing for npm packages - OIDC publishing requirements and provenance behaviour.
11. Inside the Mastra npm supply chain compromise - Microsoft Threat Intelligence, June 2026.
12. Node.js release and support timeline - consolidated support windows and commercial support availability.

Last updated 16 August 2026.