Your Stack Has Expiry Dates. Now They Come to You.

Every version you run has an expiry date. PostgreSQL majors, Kubernetes minors, Databricks runtimes, language versions - and now AI models, which retire faster than any of them. The dates are all public. They're just scattered across a few dozen vendor lifecycle pages that nobody re-reads until something stops working.

The ReleaseBytes EOL Tracker went live this week to fix that.

One page, the whole stack

releasebytes.com/eol has end-of-life and end-of-support dates for the stack ReleaseBytes covers: AWS, GCP and Azure managed services, Kubernetes distributions, Databricks runtimes, database engines, language runtimes - and the Claude, OpenAI and Gemini model retirement schedules. Refreshed nightly.

A few entries on it right now:

• OpenAI's o1, o1-pro, gpt-5-codex and gpt-5-chat-latest all shut down on July 23 - ten days from this post.
• Google Kubernetes Engine 1.33 reaches end of life in three weeks; Azure AKS 1.33 in under three.
• Databricks Runtime 13.3 LTS ends support August 22 - and it pins Python 3.10, which has its own EOL on October 31. The tracker shows what runtimes pin, so the real deadline is visible before the vendor's date says so.
• Cloud SQL for PostgreSQL 13 passed end of regular support in February; extended support (the paid kind) runs to 2029.

More than a lookup table

It alerts. Every date on the tracker feeds the same alert pipeline as the rest of ReleaseBytes. Set up an alert with the eol tag and you get email or Slack at 90, 30 and 7 days out - scoped to a category ("all GCP EOL") or a single product ("just Postgres"). When a vendor moves a date, that's an alert too - something the lifecycle pages themselves will never tell you.

It covers AI models as first-class citizens. Model retirements are the fastest-moving EOL surface in most stacks today, and they don't appear in any traditional lifecycle tracker. If your product calls a pinned model ID, its shutdown date belongs next to your Postgres version, not in a docs page you check quarterly.

It knows what runtimes contain. Managed runtimes bundle their own dependencies - a Databricks runtime carries a specific Python, and that Python has its own end of life. The tracker models the pin, so the earliest real deadline surfaces, whichever layer it comes from.

Under the hood: we ingest the full endoflife.date dataset nightly (460 products - credit to that community project), keep our own durable copy, and fill the gaps it doesn't cover - GCP managed services, Databricks runtimes, AI models - from vendor lifecycle pages directly. We deliberately surface only what ReleaseBytes tracks: a focused page for the cloud and data stack, not an everything-tracker.

And if you'd rather not check a page at all

The tracker also powers the ReleaseBytes GitHub App: installed read-only on a repo, it resolves your Dockerfiles and Terraform against these dates and opens a GitHub Issue when something you actually run is approaching end of life. That deserves its own write-up - coming later this week.

Try it

• Browse the dates: releasebytes.com/eol
• Get alerted at 90/30/7 days: set up an EOL alert

Something in your stack we don't track yet? Tell us - coverage is driven by what people actually run.