Start free
← All posts

End-of-life dates for developers: the 2026 and 2027 calendar

StackClock team ·

Most outages from old software are not surprises. The end-of-life date was published years ago. Nobody wrote it down where the team would see it.

Here is the end-of-life calendar for the runtimes and databases most teams run, covering what has just passed and what is coming through 2027. The dates come from endoflife.date, the same data behind our public end-of-life pages.

Already past: act first

If you run any of these, you are already running software with no security fixes.

  • Node.js 20: ended 30 April 2026.
  • Python 3.10: ended 1 October 2026.
  • Kubernetes 1.34: ended 27 October 2026.

Coming up in the next two months

First half of 2027

  • Kubernetes 1.35: 28 February 2027.
  • Node.js 22: 30 April 2027. This is the current long-term support line many teams moved to, so plan its successor early.
  • Ubuntu 22.04 LTS: 1 June 2027. Paid extended security maintenance continues after this, but it is not the community date. See end of life vs extended support.
  • Kubernetes 1.36: 28 June 2027.

Second half of 2027

  • Kubernetes 1.37: 28 October 2027.
  • Python 3.11: 31 October 2027.
  • PostgreSQL 15: 11 November 2027.
  • PHP 8.3: 31 December 2027.

What to do first

Not all of these need the same urgency. Work in this order:

  1. Anything already past its date. It gets no more fixes. Public-facing services first.
  2. Databases. They are the hardest to move and the most painful to leave behind. Start the upgrade rehearsal months ahead.
  3. Runtimes and frameworks. Check that your dependencies support the new version before you move.
  4. Operating systems and containers. Often the quickest win is a newer base image.

A good rule: start the upgrade when the date is six months away, not six weeks.

Which date counts: community or extended?

Many of these have a second, later date from a vendor or cloud provider who sells extra cover. That is useful as a safety net, but it is paid, optional and often covers only part of the stack. We plan around the community date and treat extended support as time you can buy if the upgrade slips.

Watch your own versions, not just the list

A calendar like this tells you what is coming. It does not tell you which of these you actually run. Three ways to find out:

  • Paste your package.json, requirements.txt, go.mod or Dockerfile into the free stack check. It reads the versions and flags those past end of life.
  • Open a product's page on our end-of-life list and subscribe to its calendar.ics, which works with Google Calendar and Outlook.
  • Start free, import your stack, and every end-of-life date becomes a deadline on your timeline with reminders 60, 30, 14, 7 and 1 days before.

Dates change as projects extend or shorten support, so check the product's page before you plan around a date. We refresh our data daily.