· ReadyStack
Worked example
Real numbers from this tool, line by line.
Five lines in a US fintech team's repository will stop deploying before April 2027 — and an AI assistant wrote every one of them.
That is not a hypothetical. Here is the shape it takes in a real service:
FROM node:20-alpine # Node.js 20 went EOL 2026-04-30
runs-on: ubuntu-22.04 # deprecation begins 2026-09-17
runtime: nodejs20.x # Lambda blocks updates 2027-03-03
<TargetFramework>net8.0 # .NET 8 EOL 2026-11-10
FROM debian:11-slim # Debian 11 EOL 2026-08-31Every one of those was correct advice at some point. That is exactly the problem. A model trained while Node.js 20 was the safe LTS choice will keep suggesting node:20 long after 2026-04-30, and it will do it confidently, because nothing in the text of a Dockerfile marks a version as expired. The date lives somewhere else entirely — on a vendor page you have to know to go and read.
The sharpest edge is AWS Lambda, because it is the one that removes your ability to respond. Lambda's published table gives nodejs20.x, nodejs18.x, python3.9, python3.8, dotnet6, ruby3.2, go1.x and provided.al2 the same block-function-update date: 2027-03-03. After that date you cannot push code to those functions at all. Not a feature, not a hotfix, not a patch for whatever CVE lands that week. The function keeps running and you keep being responsible for it, which is the worst of both.
GitHub Actions does something similar with less finality but more surprise. The ubuntu-22.04 runner image begins deprecation on 2026-09-17, and GitHub schedules brownouts — 2027-03-23, 2027-03-30, 2027-04-06 and 2027-04-13 — where jobs on that label simply fail, before the image goes fully unsupported on 2027-04-17. A brownout arrives as a red build on a Tuesday in a repository nobody has touched in months.
None of this is secret. The dates are all published. The gap is that nobody looks, because looking means opening every Dockerfile, every workflow, every serverless.yml and every .csproj in the repository and cross-checking each pinned version against a different vendor's page.
That is a job for a regular expression and a table, so we made one. Runtime EOL Guard carries 54 rules covering Docker base images, GitHub Actions runner labels and setup-* pins, AWS Lambda runtime identifiers, and project manifests for .NET, Python, Django, Rails, Ruby, Spring Boot and Kubernetes. Every rule states the real date it is asserting and the version it wants instead, so you can check our homework.
The free version checks the open file — all 54 rules, no key, no cap, nothing hidden. Paste a file into the web version and you get the same answer from the same rule set. What the licence buys is a different job: one pass over the whole workspace, a dated report you can hand to a security review, CI output that fails a build on a crossed block date, and your own internal deadline rules.
A US platform engineer averages $63.95/hour (ZipRecruiter, September 2026). Runtime EOL Guard is $29 once.
15 seconds — what it actually does
Questions people ask
What does Runtime EOL Guard actually do?
It scans a Dockerfile, GitHub Actions workflow, serverless.yml, .csproj, Gemfile or requirements.txt and flags every runtime version that has passed end-of-life or is close to it. Each finding names the real EOL date, the AWS Lambda block-create and block-update dates where those apply, and the supported version to move to instead.
Who is this for?
Platform and DevOps engineers who own the deploy pipeline — the person paged when a Lambda function refuses to update or a CI job fails on a retired runner label. It also suits anyone reviewing infrastructure code an AI assistant generated, because those suggestions reflect the versions that were current while the model was trained.
Why not just use endoflife.date or Dependabot?
endoflife.date publishes the dates but cannot read your repository. Dependabot and Renovate update packages inside a manifest, not the platform underneath it: base images, CI runner labels and Lambda runtime identifiers. Runtime EOL Guard joins the two halves, finding the pinned version in your file and attaching the date it stops working.
What is free and what needs a licence?
The free tier checks the open file, or only the lines you select, against all 54 rules. No key, no watermark, no usage cap, and no finding is ever hidden. The licence covers a different job: scanning every file in the workspace at once, exporting a dated audit report, CI output, re-checking on save, and your own rules.
What would this cost me otherwise?
A US platform engineer averages $63.95 an hour (ZipRecruiter, September 2026). Auditing a mid-sized repository by hand means opening every Dockerfile and workflow and checking each version against a vendor page. Runtime EOL Guard is $29 once, one licence key per person or team seat,.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Runtime EOL and Deploy-Block Audit for Docker, CI and AWS La checks the file you open against 54 rules from a rule set dated 2026-09-20, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.