GitHub's Evergreen app automates quarterly access reviews and stale repo archiving

GitHub automates its own org hygiene

GitHub's platform engineering team has detailed Evergreen, a GitHub App that automates two chores that tend to slip in busy organizations: confirming which outside collaborators still need access, and archiving repositories that have gone quiet. According to the GitHub Blog, the tool was built for a shared organization where GitHub employees — internally known as 'Hubbers' — work alongside customers and partners on product trials and services projects.

Two automated workflows

Evergreen runs on a quarterly cadence. The access review snapshots each repository's outside collaborators and opens a checklist issue asking owners to confirm who should stay; anyone left unchecked loses access. The staleness workflow watches for repositories with no human activity beyond a set threshold, which are first flagged, then warned, and finally archived if nothing changes.

Two design rules shaped the build, per the post. If a review goes unanswered, access is revoked rather than left in place, so the safe outcome is the default. And nothing is ever deleted: archived repositories can be restored, and every access change is written into a tracking issue, so reversing a mistake means re-adding the accounts listed there.

The quarterly schedule

A dedicated controller repository drives the schedule and holds the system's state. Four scheduled GitHub Actions workflows fire repository_dispatch events through the quarter:

• Day 1: flag stale repositories and open warning issues
• Day 8: snapshot outside collaborators and open a review issue for each repository
• Day 16: archive repositories still inactive after the grace period
• Day 23: revoke access for any review that went unanswered

Reviews open two weeks before their corresponding cleanup, and a fixed grace period prevents a manual run from acting early. Each workflow also supports workflow_dispatch for on-demand triggering.

Under the hood Evergreen is a small Go webhook server in a container, but the post stresses that every other component is something GitHub already ships: the App itself, scheduled Actions, webhooks, issues, custom properties, and plain files in a repository.

Git as the audit log

Each repository's status is stored as a JSON file committed to the controller repo (under state/repos/<repo_id>.json), capturing the access snapshot, deadlines, who decided, and the outcome. Because the state is just files, the commit history doubles as the audit trail — the post points to checking a file's commit history to see why someone lost access — with no separate database or custom audit tooling.

Decisions, safeguards and notifications

The interaction model is issue-based: check the boxes for collaborators who should keep access, then close the issue. Evergreen listens for the closed-issue webhook, keeps the checked accounts, removes the others, and posts a summary comment listing exactly what stayed and what went. Closing a review is treated as a privileged action; if someone outside the authorized employee group closes one, the app reopens it and explains why.

Because the team did not always know which employee owned a given repository, Evergreen resolves whom to notify through a fallback chain: a custom property (evergreen_repo_owner) if set, otherwise recent issue and commit authors who belong to the access review team.

Failure handling is strict. If some removals succeed while others hit a transient API error, the review stays pending and the issue stays open, with the next run retrying whatever is left; a review is only recorded as revoked once every removal has succeeded. A reminder comment lands before each deadline, and repositories can opt out of either workflow using the evergreen_exempt_from_access_review or evergreen_exempt_from_archive custom properties.

A careful rollout

The organization counts more than 1,400 GitHub employees plus many customers and partners, so the team eased the automation in. Evergreen ships with a dry-run mode that records every change it intends to make while leaving collaborators and repositories untouched, and the team ran it against the live organization while validating the decisions it proposed. They also broadcast what was coming, and when, before switching it on.

Why it matters

Dormant repositories and stale external access are common findings in security audits, and manual review programs decay as an organization grows. What makes this write-up practical is that it describes a replicable pattern rather than a product: scheduled Actions provide the clock, issues provide the human interface, git provides the audit trail, and revocation-on-silence provides the safety default, all on native platform features with no new infrastructure. Maintainers of shared organizations, trial tenants or partner collaborations can lift the choreography directly, and the design choices — reversible actions, retry-until-consistent cleanup, per-repository opt-outs — are a sound template for any automation that touches permissions.