Express 3 is EOL, Express 4 is Next: The 2026 Support Reference

Express.js is the load-bearing wall of the modern JavaScript ecosystem. It sits behind an estimated 1.2 million production websites, ships tens of millions of weekly downloads on npm, and powers backend services at Netflix, PayPal, Uber, LinkedIn, and NASA, along with the long tail of MEAN, MERN, and MEVN applications built over the past decade. It is not legacy. It is infrastructure.

But that infrastructure is aging. Express 3 has been unmaintained for years. Express 5 is now the Express Technical Committee's production-recommended release. While Express does not have formal end-of-life dates, it is clear that Express 4 support is on borrowed time. It is likely to become officially unsupported soon. When that happens, updates will stop. Bug fixes and security patches wil no longer be provided.

Since the release of Express 5 in 2024, Express 4 has received only five updates. These were limited to defect and CVE fixes.

This guide is the definitive reference for every Express major version, what happened to Express 3, what's coming for Express 4, and the options enterprise teams have to stay patched, compliant, and in production.

‍

How does Express handle end-of-life and support?

Express does not publish formal EOL dates the way Angular, Node.js, or .NET do. There is no 18-month LTS window. There is no official published sunset calendar. The Express Technical Committee, stewarded under the OpenJS Foundation, maintains the project and the community ships patches on a best-effort basis.

In practice, that produces three support tiers:

‍

1. Active. The Technical Committee's endorsed release line. Currently Express 5.2.x
2. Maintenance. Previous major versions that still receive occasional patches from maintainers when volunteers have bandwidth. Five minor releases since 2024, currently on Express 4.22.x
3. End of Life. Versions that no longer receive patches of any kind. Express 3 and earlier.

Maintenance status is better than no patching, but it is still not a contractual SLA cited in a SOC 2, FedRAMP, NIS 2 Directive, CRA, or DORA requirements. When a security questionnaire asks "who patches your production dependencies?". They want a named party on the hook with a documented SLA time. That distinction becomes the core compliance problem with Express 4.

‍

Express Version Timeline

‍

Express 3: End of Life (and Has Been for a Decade)

Express 3.0 shipped in October 2012 and was the dominant version of Express for roughly 18 months until Express 4.0 released in April 2014. When Express 4 shipped, Express 3 was effectively deprecated. Express 3’s final patch (3.21.2) shipped in July 2015. The version has been unmaintained for over a decade.

If you are still running Express 3 in production (and you would be surprised how often the answer in enterprise environments is "yes"), here is what end-of-life means in practice:

• No security patches. Disclosed CVEs remain unpatched indefinitely, no further fixes are coming from the project.

• Breaking API surface versus Express 4 and 5. Express 3 used a different middleware stack (connect-based rather than the unified router introduced in 4.0). Methods like app.configure(), the old res.redirect() signatures, and the legacy error handling middleware shape mean that upgrading from 3 to 4 (let alone 5) is a significant refactor, not a version bump.

• Toolchain rot. Express 3 applications often depend on Node.js runtimes that are themselves deep into EOL. Node 0.10, 0.12, 4.x, and 6.x are all end of life and no longer receive OpenSSL updates. Running Express 3 on a supported Node runtime requires dependency patching that the Express 3 codebase itself was never tested against.

Organizations running Express 3 should treat it as a compliance finding in the same category as an unsupported operating system. HeroDevs Never-Ending Support for Express 3 exists precisely for teams that need to keep Express 3 applications patched and audit-ready while they plan migration.

‍

When will Express 4 reach End-of-Life?

Express 4 has been the workhorse of the Node.js ecosystem for over a decade. 4.0 shipped in April 2014 and every major Node.js framework, tutorial, and bootcamp from 2015 through the early 2020s assumed Express 4 as the default. Most production Express fleets today are running 4.17.x, 4.18.x, 4.19.x, 4.21.x, or 4.22.x.

The Express Technical Committee (TC) has published a target EOL date for Express 4 of no sooner than October 1, 2026, with version 4 having entered formal Maintenance status on April 1, 2025. The TC explicitly frames these dates as "goals, not commitments" and notes that version 4 is a special case that may receive extended Maintenance support given its decade-long tenure as the only major version. In practical terms: organizations running Express 4 in production today have roughly six to eighteen months of community security patches remaining, with no contractual guarantee past that window.

‍

How hard is it to migrate from Express 4 to Express 5?

Express 5 is not a dependency bump. It is a breaking release with real refactor work per service:

• Removed methods. res.sendfile() (lowercase) is gone, replaced by res.sendFile(). app.del() is gone, replaced by app.delete(). These removals are syntactic but require codebase-wide search and replace, plus test coverage to catch the edge cases.
• path-to-regexp v6 syntax. Route patterns using regex fragments, optional parameters, and wildcards follow new syntax rules. Routes that worked in 4.x can silently match different paths in 5.x, which is a production-impacting behavioral change, not a compilation error.
• Async error handling. Express 5 properly propagates rejected promises from async middleware and handlers. Code that relied on unhandled rejections being swallowed (usually unintentionally) will now surface errors to the error-handling middleware. That is the correct behavior but it will expose bugs that Express 4 hid.
• req.query semantics. The default query parser behavior and the object shape returned by req.query have shifted. Downstream validation and serialization layers need review.
• Middleware compatibility. Some third-party middleware packages still have not released Express 5-compatible versions. Audit the dependency graph before planning the migration.
• Node 18+ requirement. Express 5 drops support for Node.js 16 and earlier. Organizations still on older Node.js runtimes inherit a second forced migration. Note that Node.js 18 itself reached end-of-life on April 30, 2025. Organizations standing up new Express 5 services today should target Node.js 22 (Active LTS) to avoid immediately shipping on an EOL runtime.

A realistic estimate for an enterprise Express 4 to 5 migration is 3 weeks to 3 months per service, fully loaded at $50,000 to $250,000 per service depending on test coverage, middleware complexity, and integration surface. Multiply across a fleet of 40 or 80 or 200 services and the program becomes a seven-figure line item with a multi-quarter calendar.

‍

Express 5.2.x: The Current Production-Recommended Release

Express 5.2 shipped December 1, 2025 and is the Technical Committee's endorsed production release. Organizations starting new Node.js backend projects today should use the latest Express 5.2. Organizations running Express 4 should plan migration to the latest Express 5.2.x version when their schedules and risk tolerance allow.

The Express 5 release announcement also publicly named HeroDevs as the Express Project's Never-Ending Support partner, making it the only commercial NES offering endorsed by Express itself.

‍

What happens when an Express version reaches end-of-life?

When an Express major version reaches end of life, three things follow:

1. Security patches stop. New CVEs disclosed against the EOL version do not receive upstream fixes. AI-assisted vulnerability research has been accelerating CVE discovery in historic code, which means the rate at which new vulnerabilities are found in old frameworks is increasing, not decreasing.

2. Dependency compatibility degrades. Express interoperates with a large ecosystem: body parsers, session stores, auth middleware, template engines, CSRF protection, rate limiters. As those packages publish new major versions targeting current Express, they stop testing against older Express. Compatibility erodes silently.

3. Compliance audits flag it. SOC 2 Type II, ISO 27001, FedRAMP, HIPAA, PCI DSS, the EU's NIS2 Directive, the EU Cyber Resilience Act, and DORA all treat unsupported production dependencies as open findings. "The community might patch it" is not a defensible control. Auditors want a named, contractual party on the hook for vulnerability remediation with a documented SLA.

‍

What are my options for running end-of-life Express?

1. Upgrade to the latest version of Express 

The best long-term strategy for most organizations. The Express community publishes a migration guide at expressjs.com that walks through the steps and breaking changes. Budget realistically: 3 weeks to 3 months per service, with the high end of that range driven by middleware complexity and test coverage gaps.

2. Migrate to a Different Framework

Some organizations use an Express EOL event as the catalyst to move to Fastify, Hono, NestJS, or to adopt a serverless runtime. This is the most expensive option and rarely justified by the Express-specific risk alone. It makes sense when Express's architectural assumptions no longer match the application's needs, not as an EOL mitigation.

3. Adopt Commercial Extended Support

HeroDevs Never-Ending Support (NES) for Express provides a drop-in, contractually maintained replacement for Express 3.x (and Express 4.x coming soon) with SLA-backed security patches that continue indefinitely past community end-of-life. Same APIs, no code changes, no forced migration.

HeroDevs is the only commercial NES vendor in the Express ecosystem and the named NES partner of the Express Project itself. The NES engineering bench includes Node.js Technical Steering Committee members, and HeroDevs partners with the OpenJS Foundation under its Ecosystem Sustainability Program.

NES is typically the right choice when:

• The migration calendar is longer than the audit deadline.
• The institutional knowledge to safely refactor Express 4 services has left the company (original architects have moved on, test coverage is patchy).
• The organization already holds HeroDevs NES for other JavaScript ecosystem packages (AngularJS, Angular, Vue, Next.js, Node.js), in which case Express NES bundles under a single contract and SLA.

‍

Quick Reference: Is My Express Version Supported?

‍

What Should Organizations with Express 4 Do in 2026?

Express's community support model has served the ecosystem well for over a decade, but "informal" and "production-critical" are becoming harder to reconcile. Express 3 is already EOL. Express 4's sunset is coming. Express 5 migration is real work with a real calendar and a real budget.

The choices are straightforward: migrate to Express 5 on a schedule the business can absorb, replace it with a different framework if the architectural fit no longer works, or adopt commercial Never-Ending Support to keep Express 3 (and Express 4) applications patched and audit-ready while migration happens at the right pace.

The EU Cyber Resilience Act's reporting obligations begin September 2026. DORA is already live. SOC 2 and other standards and regulations are mandatory. If Express 3 or Express 4 is in your production stack and your next audit window opens inside that timeline, the migration-or-NES decision needs to be made now, not when Express 6 ships. Schedule a call with HeroDevs to learn about Express NES.

‍

Frequently Asked Questions

When is Express 4's end-of-life date?

As of April 2026, the Express Technical Committee has not published a formal EOL date for Express 4. Community signals and the Technical Committee's public pivot to Express 5 as the production-recommended release indicate a sunset when Express 6 is released.

Organizations with multi-quarter migration calendars or active audit obligations should plan now rather than waiting for a formal announcement.

Is Express 3 still supported?

No, Express 3 has been unmaintained for more than a decade. It does not receive security patches. Running Express 3 in production without commercial extended support is an open compliance failing. HeroDevs NES for Express provides that extended support post-EOL.

Can I skip Express 4 and go straight from Express 3 to Express 5?

Technically yes, practically rarely. The API changes between Express 3 and Express 5 span two major version boundaries and includes breaking changes. Most teams that attempt this end up running Express 3 and Express 5 side by side behind a proxy and migrating or rewriting over time service by service.

What does HeroDevs NES cover for Express?

HeroDevs NES for Express provides drop-in replacement packages matching your current Express 3.x (4.x soon) version with contractually SLA-backed security patches. No application code changes are required. Pricing is a single-tier SKU with bundle discounts available when purchased alongside other HeroDevs JavaScript NES products (Node.js, AngularJS, Angular, Vue, Next.js and more). Contact HeroDevs for specifics.

Does HeroDevs support Express 4?

Once Express 4 reaches its official EOL with no further community updates, HeroDevs  will extend its Never-Ending Support (NES) program to cover it. Express NES acts as a drop-in replacement, providing security patches and ongoing maintenance for open-source versions after they reach end-of-life.

How do I check which Express version I’m running?

Run npm list express from your project root, or check the dependencies block in package.json. If you're on HeroDevs Express NES, the package will appear as @herodevs/express-nes in package.json rather than express.

‍

This post is maintained by HeroDevs and will be updated as Express publishes formal EOL dates or new major versions. Last updated: April 2026.