// For versions you cannot leave
When you cannot leave a version
Some versions cannot move: a vendor certifies only that release, a client needs that server, a quality team validated it, or it ships inside a product. Patch-only support keeps that exact version secure. OSSeva backports security fixes to it, with Critical CVEs patched within 48 hours and High within 7 days, until the upgrade date you set.
Last reviewed
Trusted globally by enterprises
Four reasons a version cannot move
Teams rarely stay on an old version by choice. In practice the version is pinned by one of four things, and each one sets what patch-only support has to keep intact.
A vendor certifies one version
The packaged application, ERP or appliance under your business is certified against one database or runtime release. Move the layer underneath and you leave the vendor's support terms.
What patch-only keeps: The certified major version stays as it is. Security fixes arrive as a patched build of that version.
A client is pinned to the server
Drivers, agents and framework code in many systems expect one server or framework line. Spring Boot 3.0, for example, needs Java 17 and the jakarta package names, so a 2.7 estate cannot step to it without touching every service.
What patch-only keeps: Clients keep talking to the line they were built for. You choose when each one is rebuilt.
A validated system cannot take a major change
Where a system was validated at a given version, a major upgrade can mean validating it again. Your quality team decides what a security patch inside the version triggers.
What patch-only keeps: The change is a security fix inside the version, with a CVE record and a build identifier to attach to the change request.
The component ships inside something else
The version is embedded in a product you sell or a box you do not control, so its owner sets the upgrade date, not you.
What patch-only keeps: The embedded line stays patched, with an SBOM and VEX statements you can pass to your own customers.
Patch-only support: what changes and what does not
The contract covers one thing: security fixes for the version you run. Everything your vendor, your clients or your validation file depends on stays where it is.
| Item | Detail |
|---|---|
| What changes | Security fixes backported to your version. Critical CVEs within 48 hours, High within 7 days. A signed build, an SBOM, VEX statements and a CVE record for each release, delivered through the repository manager you already use. |
| What stays the same | Your major version, its configuration and its client compatibility. Patches apply to upstream source with no fork, so the build is a drop-in. If you stop the subscription you keep running the last patched build, with no proprietary runtime dependency. |
| What it does not do | It adds no features, it does not move the upstream end-of-life date, and it does not patch the JDK or the operating system under the version. |
For PostgreSQL, the project's versioning policy says a minor upgrade means stopping the server, installing the new binaries and restarting, while a major upgrade needs pg_upgrade or a dump and reload. Patch-only support is the smaller change.
Lines that can stay where they are
End-of-life dates checked on 26 October 2026 against endoflife.date. The status column comes from the supported versions list. Your exact version may not be on it; check before you plan around it.
| Line | Upstream support ended or ends | OSSeva |
|---|---|---|
| PostgreSQL 11 | 9 Nov 2023 | Patched builds available |
| PostgreSQL 12 | 21 Nov 2024 | Patched builds available |
| PostgreSQL 13 | 13 Nov 2025 | Patched builds available |
| PostgreSQL 14 | 12 Nov 2026 | Patches continue after the final community release |
| Spring Boot 2.7 | 30 Jun 2023 | Patched builds available |
| Spring Framework 5.3 | 31 Aug 2024 | Patched builds available |
| Apache Tomcat 8.5 | 31 Mar 2024 | Patched builds available |
| Apache Tomcat 9.0 | 31 Mar 2027 | Backports continue after Apache support ends |
Java 8: the runtime is not the problem
Java 8 still gets security updates from its vendors. endoflife.date lists Eclipse Temurin 8 and Amazon Corretto 8 to 31 December 2030, and Oracle JDK 8 extended support to the same date. Red Hat's build of OpenJDK 8 is listed to 30 November 2026.
The exposure is in the frameworks on top. Spring Boot 2.7 ended on 30 June 2023 and Spring Framework 5.3 on 31 August 2024, and both run on Java 8. Spring Boot 3.0 needs Java 17 and the jakarta namespace, so a pinned Java 8 estate cannot take it in one step. That gap is what patch-only support covers. See Spring continuation for the Spring lines. OSSeva does not patch the JDK or the operating system.
Plan the exit date
A patch-only contract is a bridge. Treat it as one.
- 01
Write down the blocker. Vendor certification, client rebuilds, revalidation or an embedded product. Each has an owner, and the owner sets the date.
- 02
Read the upstream path. Spring says to reach the latest 2.7.x before 3.0. PostgreSQL can skip intervening major versions with pg_upgrade, after reading every release note on the way.
- 03
Set the date and review at each upstream deadline. The table above shows the next one for each line.
- 04
Keep the evidence. The CVE record and the signed build show what was fixed and when, which your auditor or your customer will ask for while you wait.
What a patch-only quote depends on
OSSeva does not publish a price here. The quote follows the technologies and lines you run, how many clusters or instances carry them, and the tier you choose. For PostgreSQL the quote is per cluster and does not follow vCPU count. Patch is the patch-only tier; Assure adds audit evidence, upgrade planning and 24/7 reactive support; Operate adds proactive monitoring and a 15-minute P1 response.
The patch window is the same on every tier: Critical CVEs within 48 hours and High within 7 days.
Not a fit for
- A version that is not on the supported versions list. Check first.
- A JDK, an operating system or firmware. OSSeva does not patch them.
- An upgrade you can do this quarter with no blocker. Upgrading to a supported release is the cleaner route.
- A promise that your application vendor will support a patched build. Get that in writing from the vendor.
Sources, checked 26 October 2026: endoflife.date API: PostgreSQL, Spring Boot, Spring Framework, Apache Tomcat, endoflife.date: Eclipse Temurin, Amazon Corretto, Oracle JDK, Red Hat build of OpenJDK, Spring blog: Preparing for Spring Boot 3.0 (24 May 2022), PostgreSQL: versioning policy, minor and major upgrades.
Can we stay on Java 8 safely?
The Java 8 runtime itself is still patched by its vendors: endoflife.date lists Eclipse Temurin 8 and Amazon Corretto 8 to 31 December 2030, and Oracle JDK 8 extended support to the same date. The exposure sits in what runs on it. Spring Boot 2.7 ended on 30 June 2023 and Spring Framework 5.3 on 31 August 2024, both of which run on Java 8, and Spring Boot 3.0 needs Java 17. OSSeva patches those frameworks and middleware. It does not patch the JDK or the operating system.
What if our ERP vendor only certifies an old PostgreSQL?
Stay on that major version and keep it patched. PostgreSQL's community ended support for 11 on 9 November 2023, 12 on 21 November 2024 and 13 on 13 November 2025, and ends it for 14 on 12 November 2026. OSSeva ships patched builds for these lines, so the version in your vendor's certification matrix does not change. Ask the application vendor for its position on a patched build in writing before you rely on it, and ask when it plans to certify a newer major version.
Does patch-only support change our version or our data?
No. OSSeva builds keep your major version and are binary-compatible drop-ins for upstream. For PostgreSQL, the project's versioning policy says minor upgrades need only stopping the server, installing the new binaries and restarting, while a major upgrade needs pg_upgrade or a dump and reload.
Is this a permanent answer?
No. A patch-only contract is a bridge to a date you set, not a destination. It covers security fixes for the version you run. It does not add features and it does not move the upstream end-of-life date. Write the exit date and the blocker down, and review both at each upstream deadline.
Get a quote
Keep the version.
Close the CVEs.
Tell us the technology and the version you cannot move. A senior engineer replies within 1 business day with what is covered.
Prefer to talk or read more first?