The ReleaseBytes GitHub App: Your Repos, Watching the Releases For You

Breaking releases have a timing problem: they ship on the vendor's schedule, not yours. Your Terraform provider pin was fine when you wrote it - the breaking change arrived three weeks later, while the repo was quiet. Nobody re-reads provider changelogs for repos that aren't changing. That's exactly where surprises live.

Last month's analysis found roughly 1 in 11 platform releases is action-forcing - a breaking change, a deprecation or a security advisory. The feed and alerts tell you what shipped. The new ReleaseBytes GitHub App answers the harder question: does it affect this repo?

What it does

Install it on a repo (read-only) and every scan checks two things:

1. Breaking provider releases past your pin. It reads every .terraform.lock.hcl in the repo - nested roots included, the way real infra monorepos are laid out - and takes the oldest pin per provider, because that's your most exposed one. When releases newer than that pin contain breaking changes, it opens one Issue per provider listing exactly what shipped since: each release with its breaking changes summarised, linked to the release notes and the ReleaseBytes analysis. Bump the pin and the Issue updates; catch up fully and it closes itself.

2. Versions approaching end of life. It reads Dockerfile FROM lines and Terraform database_version declarations and resolves them against the EOL Tracker we launched Monday. Anything you run that's within 90 days of end of life - or past it - gets an Issue: "Cloud SQL for PostgreSQL 13 is past end of life - detected in infra/main.tf." Runtime pins cascade: a repo on Databricks Runtime 13.3 gets told about the Python 3.10 deadline inside it.

Findings arrive as GitHub Issues deliberately: that's where infrastructure work gets triaged, assigned and scheduled - not another dashboard to remember to check.

Built to not be noisy

Advisory bots die by spam. The behaviours that keep this one livable:

• One Issue per finding, updated in place. A hidden marker makes every scan idempotent - repeat scans update the existing Issue, never duplicate it.
• Issues close themselves. When your pin catches up or the version moves on, the next scan closes the Issue with a comment. No stale advisories rotting in the tracker - and if a scan partially fails, it never closes anything it isn't sure about.
• Breaking-release and EOL findings are separate Issues. A provider upgrade is a quick pin bump; an EOL migration is scheduled work over months. Different lifecycles, individually closeable.
• It scans on your schedule and ours. Pushes touching Terraform or Dockerfiles trigger an immediate rescan; a daily sweep catches releases that ship while your repo is quiet - which is when most of them ship.

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 PRs or touch branches, by construction rather than by promise. It reads your lock files, Dockerfiles and Terraform; it writes Issues; nothing else.

And when a scan meets a dependency we don't have lifecycle data for, that miss is logged and drives what we cover next - the tracker grows toward what installed repos actually contain, not what we guess.

What's next

The current scans match pins against releases. The next phase goes deeper: inventorying which Terraform resources a repo actually uses, so a breaking change in a resource you don't touch never becomes an Issue at all - and line-level impact analysis on the ones you do.

Install it

releasebytes.com/github-app → pick your repos → done. First scan runs on install; if a repo is clean, you hear nothing - which is the point.