Extended Support for End-of-Life Open Source Software

End-of-life (EOL) software is a product or version that its vendor or maintainers no longer support: no more bug fixes, no more security patches, and usually no more help on community channels. It does not stop working on that date. What stops is the flow of fixes, so any vulnerability discovered afterwards stays unpatched unless someone else backports a fix. End of support and end of life are often used interchangeably; some vendors use end of support for the date fixes stop and end of life for full retirement.

Commercial vendors publish a lifecycle with dates and often sell paid extended support for older versions. Open source projects publish a support window per release line and then simply stop: PostgreSQL patches each major version for five years, Apache Kafka maintains only its three most recent release lines, and Node.js retires each long-term support line about three years after it ships. There is no vendor to buy more time from, which is why independent extended support and backported patches exist.

It is not illegal. It is usually a compliance problem in audited environments. PCI DSS v4.0.1 requirement 6.3.3 requires patches for critical vulnerabilities to be installed within one month of release, which an unpatched EOL version cannot meet, and requirement 12.3.4 requires hardware and software technologies to be reviewed at least once every 12 months, including the vendor's end-of-life plans and a management-approved plan to remediate outdated technologies. SOC 2 audits test vulnerability management against the AICPA Trust Services Criteria, which expect newly discovered vulnerabilities to be detected and acted on, and a version with known, unpatched CVEs is hard to square with that. A documented patch source and upgrade plan is what usually closes the finding.

Yes. Upstream projects stop publishing fixes, but a patch for a newer release can often be backported to the old line. OSSeva, AceMQ's patching platform, does this for Redis and Valkey, PostgreSQL 11 to 13, Kafka 2.8 to 3.7, ActiveMQ, GemFire and Geode, Spring Boot, Spring Framework, Spring Security, Node.js and Apache Pulsar. For RabbitMQ 3.8.x to 3.13.x, AceMQ's Extended LTS support provides backported security patches, and AceMQ's Apache Tomcat support includes patched builds for Tomcat 8.5, 9.0 and 10.0.

Extended support is a paid continuation of security patches and technical support for a version after its standard support has ended. Commercial vendors sell it for their own products. For open source, it comes from independent providers who backport fixes and support the old version, as OSSeva and AceMQ do. It is meant to cover the time between end of life and a completed upgrade, not to replace the upgrade.

Third-party support is support from a company other than the original vendor or project. For commercial software it usually replaces the vendor's maintenance contract. For open source it is often the only commercial option, because the project itself sells nothing. A good third-party provider covers the version you run, responds under a written SLA and can produce patches, not only advice. AceMQ is a third-party support provider for open source infrastructure, and OSSeva is its patching arm.

A broker past end of life keeps delivering messages, but any CVE found afterwards stays open on the component every service depends on. Broker extended support closes that gap until the upgrade is done: AceMQ's Extended LTS support for RabbitMQ 3.8.x to 3.13.x, and OSSeva patches plus AceMQ support for ActiveMQ, Kafka and Pulsar. For ActiveMQ EOL, the Apache download page lists only 5.19.x and 6.3.x as active Classic series, so 5.18 and earlier are inactive; our ActiveMQ end of life guide covers each line and the move to 6.x or Artemis.

Not yet for the current lines. The Valkey releases page (checked 20 October 2026) lists maintenance for 7.2 to 16 April 2027 with security fixes to 16 April 2029, and maintenance for 8.0 to 15 September 2027. OSSeva supplies patches for 7.2 and 8.0, and AceMQ Valkey support covers the version you run while the upgrade is planned.

Technically, as long as it runs. Safely, as long as someone is patching it and you have a plan to leave. With backported patches and support in place, the right answer is the time the upgrade really needs, which is longer when it touches client libraries, drivers or a framework major version, and should be agreed as an end date up front. Without patches, every month on an EOL version adds known, unfixed vulnerabilities, and the upgrade gets harder as the gap to the current release widens.

Three. Upgrade to a maintained release, which is the right end state but often takes longer than the audit or the change calendar allows. Buy extended support with backported patches, which keeps the version secure while the upgrade is done properly. Or move to third-party support for the technology as a whole. Accepting the risk with no patches is a fourth option that many regulated organizations cannot choose. Many teams combine the first two.

Yes. AceMQ works on End-of-Life Software in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

End-of-life support is scoped separately from AceMQ's regular support: the price depends on the versions you run, how long you need cover, and the patching and response terms. Request a quote and AceMQ replies within 1 hour.