Monitor your repos with the ReleaseBytes GitHub App
Keep track of breaking changes and end-of-life dates for the providers, images and runtimes pinned in your repos. The app installs read-only and opens a GitHub Issue when something needs attention, with nothing to configure.
What it detects
Breaking provider releases past your pin
Reads every .terraform.lock.hcl in the repo, nested roots included, and takes the oldest pin per provider. When newer releases contain breaking changes, it opens one Issue per provider listing exactly what shipped since your pin, linked to the release notes and the ReleaseBytes analysis.
Versions approaching end of life
Reads Dockerfile FROM lines and Terraform database_version declarations and resolves them against the EOL Tracker. Anything you run inside 90 days of end of life, or already past it, gets an Issue naming the file it was found in. Runtime pins cascade: a repo on Databricks Runtime 13.3 is told about the Python 3.10 deadline inside it.
There is nothing to configure and no account to link: the repo is the config. Findings come only from what each repository actually pins, so a repo without Databricks never hears about Databricks. EOL findings come from the same data as the EOL Tracker: one page of end-of-life dates for the cloud, data and AI stack, updated nightly.
What it covers today
| It reads | It detects |
|---|---|
| .terraform.lock.hcl | Breaking releases in pinned Terraform providers: AWS, Google Cloud, AzureRM, Kubernetes, Helm, Cloudflare |
| Dockerfile | End-of-life base images: PostgreSQL, MySQL, MariaDB, Redis, Valkey, Python and other official images of products on the EOL Tracker |
| *.tf | End-of-life managed versions: Cloud SQL (database_version, PostgreSQL and MySQL) and Databricks Runtime (spark_version on clusters and jobs) |
| databricks.yml | Databricks Runtime pins in asset bundles, including what the runtime carries: DBR 13.3 also surfaces its pinned Python 3.10 deadline |
Coverage grows toward what installed repos actually contain: anything the scanner meets but can't resolve is logged and prioritised. Running something we should detect? Tell us.
Built to not be noisy
- One Issue per finding, updated in place
Repeat scans update the existing Issue, never a duplicate.
- Issues close themselves
When your pin catches up or the version moves on, the next scan closes the Issue with a comment.
- Scans on your schedule and ours
Pushes touching Terraform or Dockerfiles trigger a rescan; a daily sweep catches releases that ship while your repo is quiet.
- Quiet by default
A clean repo hears nothing. No weekly summaries, no digests. An Issue means something needs action.
Read-only by construction
The app requests two permissions: Contents: read-only and Issues: read & write. That's the entire surface, enforced server-side by GitHub. It cannot push code, open pull requests or touch branches. It reads your lock files, Dockerfiles and Terraform; it writes Issues; nothing else.
Install it
Pick the repositories you want scanned; the first scan runs on install. If a repo is clean, you hear nothing. Which is the point.
Install the GitHub App