--- title: "Runtime End-of-Life Checker (Docker, CI, Lambda) | Since.dev" description: "Paste a Dockerfile, workflow, go.mod, package.json or .csproj and see when each Node.js, Python, .NET or runner version reaches end of life. Free." canonical_url: https://since.dev/guides/runtime-end-of-life-checker last_updated: 2026-11-04 --- # Runtime end-of-life checker for Docker, CI and Lambda Paste a Dockerfile, a GitHub Actions workflow, .tool-versions, go.mod, package.json, a .csproj or a Lambda template, and see when each runtime version it pins reaches end of life. It's free, and what you paste stays in your browser. Updated November 4, 2026 ## Check your runtime versions Paste one file or several at once, then click Check runtimes. To see a result first, click Use an example: it checks two Docker images, a macOS runner, a .NET setup step and a Lambda runtime. On the page, this checker runs in the browser against the retirement calendar. Agents can read the same dates as JSON from , free and without a key (filter with `kind=model` or `provider=nodejs`), or check code with `check_code` over MCP. ## Which files it reads It reads these lines wherever they appear in your paste, and lists each runtime version once, at the first line it's on: What the checker reads, file by file | File | What it reads | Example | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | | Dockerfile | The tag on each FROM line, when it starts with a version. Official images such as node, python, golang and the .NET images map to their runtime, and others are looked up by name. | FROM python:3.9-slim | | GitHub Actions workflow | Runner labels such as ubuntu-22.04, macos-14 or windows-2022, in runs-on or a matrix | runs-on: macos-14 | | GitHub Actions workflow | The node, python, go, java, dotnet, ruby and php version inputs of actions/setup-\* steps, lists included | dotnet-version: 8.0.x | | .tool-versions | A runtime name, then a version, at the start of a line | nodejs 20.11.0 | | go.mod | The go and toolchain lines | toolchain go1.24.2 | | package.json | The node version in engines | "node": ">=20" | | global.json | The SDK version | "version": "8.0.404" | | .csproj | Each framework in TargetFramework or TargetFrameworks | net8.0;net48 | | Lambda template | The Runtime in a SAM, CloudFormation or Serverless template | Runtime: nodejs20.x | Some lines it skips on purpose. A tag with no version, such as `node:lts`, has nothing to look up. `ubuntu-latest` and `macos-latest` aren't pins, because they move to newer images on GitHub's schedule. A bare version from `.nvmrc` or `.python-version` needs its runtime in front, such as `node 20`. Terraform's `runtime = "nodejs20.x"` isn't read, so paste it as `Runtime: nodejs20.x`. ## How a version maps to a release line End-of-life dates belong to release lines, such as Python 3.12 or Node.js 22, not to exact versions. The checker takes the version you pinned and finds its line on the calendar: an exact match first, then the longest listed line your version starts with, followed by a dot or a hyphen. How pinned versions map to release lines | You pinned | Release line | Why | | ------------------------- | ------------------ | ----------------------------------------------------------------------------- | | FROM python:3.12.7-slim | Python 3.12 | The tag's version starts with 3.12 and a dot. | | dotnet-version: 8.0.x | .NET 8 | 8.0 starts with 8 and a dot. The .x is ignored. | | net8.0 | .NET 8 | A target framework names its .NET version. | | runs-on: macos-14-large | macos-14 | A larger runner's label starts with the image's label. | | runs-on: ubuntu-24.04-arm | ubuntu-24.04-arm64 | GitHub's Arm labels end in arm, and the calendar lists those images as arm64. | | Runtime: nodejs20.x | nodejs20.x | Lambda runtimes match by their exact identifier. | A version that stops at the major, such as `3` from `python-version: 3.x`, doesn't pick one line, so it gets no date. The result lists the lines the calendar has instead. ## What each result means Every version gets one of four answers: The four results and what to do | Result | What it means | What to do | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | A date | The line has an end-of-life date on the calendar. The row says when it ends or ended, with the days left. | Plan the upgrade before the date. A past date means the line no longer gets fixes from its publisher. | | Older than every line on the calendar | Your version is lower than every line the calendar lists for that runtime. | Treat it as past end of life and upgrade. See below. | | No end date on record for this line | The runtime is on the calendar, but this line has no end date there: often a current line with no end set yet, sometimes a line that ended before the calendar's window, or a version like 3. | Check the publisher's page. The result lists the lines the calendar has. | | Not on the calendar | The calendar has no dates for this runtime at all, such as an image we don't track. | Check its publisher's lifecycle page. | ### What older than every line on the calendar means The calendar lists end dates from about 90 days ago onward, and the result names the first day it covers. A line that ended before then isn't listed, so the checker can't show its date, only that your version is lower than every line still listed. Python 3.9, for example, reached end of life on October 31, 2025 ([Python devguide](https://devguide.python.org/versions/)), so `FROM python:3.9-slim` gets this result. In practice the line is already past end of life. For its exact date, ask `check_code` as shown below. ## Runner images and Lambda runtimes These two follow their platform's schedule, not the language's, so they have dates of their own. ### GitHub Actions runner images A label like `macos-14` or `ubuntu-22.04` names an image GitHub maintains. GitHub supports at most two GA images of each OS at a time and starts retiring the oldest label once a newer one is GA. All macOS 14 images retired from GitHub Actions on November 2, 2026 ([runner images README](https://github.com/actions/runner-images)). Ubuntu 22.04 is next. `ubuntu-22.04` and `ubuntu-22.04-arm` began deprecation on September 17, 2026 and retire on April 17, 2027. Jobs on them fail during four scheduled brownouts in the weeks before, and after it, workflows using those labels end with an error ([GitHub's announcement](https://github.com/actions/runner-images/issues/14254)). The fix is one line in `runs-on`. GitHub's README suggests pinning a version, such as `ubuntu-24.04`, to avoid surprise changes. `ubuntu-latest` moves on GitHub's schedule, and its move to Ubuntu 26.04 is planned to finish by November 19, 2026 ([GitHub's announcement](https://github.com/actions/runner-images/issues/14748)). ### Lambda runtimes Lambda dates belong to the runtime identifier, such as `nodejs20.x`, and AWS publishes three for each: deprecation, block function create and block function update ([AWS Lambda runtimes](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)). After deprecation, AWS may stop applying security patches. Once updates are blocked, you can't change a function's code or configuration on that runtime, though it keeps running and you can still move it to a supported one. The checker shows the last of the three. For `nodejs20.x` that's August 31, 2027, but AWS deprecated it on April 30, 2026 ([AWS](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)), the day Node.js 20 itself reached end of life ([Node.js release schedule](https://github.com/nodejs/Release#release-schedule)). A Lambda date far off doesn't mean the runtime still gets patches, so check its deprecation date too. A function deployed as a container image has no `Runtime` line, and AWS sends no deprecation notice for it ([AWS](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)). Its pin is the `FROM` line, which the checker reads as the language's own line, such as Node.js 20 for `public.ecr.aws/lambda/nodejs:20`. ## Use it from an agent or CI The dates come from our public calendar API, which is free and needs no key ([API docs](https://since.dev/docs.md#public-api)). This lists every Node.js line with a date: ``` curl -s https://api.since.dev/v1/calendar \ -G -d provider=nodejs ``` Use `kind=runtime` for every runtime, and `within=180d` for only the lines that end in the next 180 days. `/v1/calendar.ics` and `/v1/calendar.rss` take the same filters, for a calendar app or a feed reader. A coding agent can ask our [MCP server](https://since.dev/docs.md#mcp) about one line: call `check_code` with a surface such as `runtime:nodejs@20` and only that line's end of life comes back ([docs](https://since.dev/docs.md#check)). It reads the runtime's full history, so it answers for lines older than the calendar's window too. It needs a free account and uses [credits](https://since.dev/docs.md#api-credits). ## Where Since.dev fits Since.dev tracks end-of-life dates for runtimes, runner images and Lambda runtimes from each publisher's schedule. This checker reads what you paste. For a repository you scan or connect, Since.dev finds every file and line that pins a runtime, packages included, with the days left and the version to move to. - [Scan any public GitHub repository](https://since.dev/scan.md), no sign-in needed. - See every date on the [calendar](https://since.dev/calendar.md), including [Lambda runtimes](https://since.dev/calendar/aws-lambda.md) and [GitHub runner images](https://since.dev/calendar/github-actions-runner-images.md). - On Team and up, it opens a fix pull request for supported cases, ready for your review. Nothing merges or deploys. ## Questions ### Is the runtime end-of-life checker free? Yes. It needs no account, and the dates come from our public calendar API, which is free and needs no key. ### Does my file leave my browser? No. The page asks the calendar only for the runtimes it found, by name, such as nodejs, and matches the versions in your browser. The file itself isn't sent anywhere. ### Why does my version say it's older than every line on the calendar? Its line ended before the calendar's window, which starts about 90 days back. Python 3.9, for example, ended on October 31, 2025 ([Python devguide](https://devguide.python.org/versions/)). Upgrade to a supported line. ### Why is my Lambda date later than the language's end of life? The checker shows the day AWS blocks function updates, the last of its three dates. AWS deprecates a runtime earlier, most often when the language loses support, and may stop patching it then. `nodejs20.x` was deprecated on April 30, 2026, and updates are blocked from August 31, 2027 ([AWS](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)). ## Related guides ### Migration guides - [.NET 8 and .NET 9 end of support: how to move to .NET 10](https://since.dev/guides/dotnet-8-end-of-support.md).NET 8 and .NET 9 lose support on November 10, 2026. Where the version hides in your repo, how to move to .NET 10, and what to do if you can't in time. - [PostgreSQL 14 end of life: how to upgrade before November 12, 2026](https://since.dev/guides/postgresql-14-end-of-life.md)PostgreSQL 14 gets its final release on November 12, 2026. Where the version hides in your repo, three ways to upgrade, and what to test first. ### Free tools - [AI model retirement checker: paste code, get dates](https://since.dev/guides/model-retirement-checker.md)Paste code or model IDs and see when each model shuts down on the OpenAI, Claude and Gemini APIs, Azure, Bedrock and Vertex. Free, runs in your browser. ### How-to - [How to track breaking changes and deprecations in your dependencies](https://since.dev/guides/dependency-breaking-changes.md)Dependabot flags vulnerable and outdated versions, not announced breaking changes. Where deprecation and end-of-life notices appear, and how to catch them. ## Put your code on continuous management. Scan a public repository now, or give your agent one line. ### See how out of date your code is. [Scan a repository](https://since.dev/scan.md). Any public GitHub repository. No sign-in. ### Tell your agent what changed since it was trained. `claude mcp add --transport http since https://api.since.dev/mcp` --- Every page on this site as Markdown: https://since.dev/sitemap.md. For agents: https://since.dev/llms.txt.