Staying Evergreen: How we automated secure access and repo hygiene in a shared org

GitHub has introduced Evergreen, a GitHub App designed to automate organization hygiene by managing outside collaborator access and archiving stale repositories. Built entirely with native GitHub features, the tool addresses the manual burden of tracking permissions and deadlines in shared organizations where employees collaborate with external partners.

Automated Workflows and Design Principles

Evergreen operates on two primary workflows: quarterly access reviews for outside collaborators and stale repository detection. The system follows two core principles: fail secure, meaning access is revoked if no response is received by the deadline, and never destroy anything, ensuring repositories are only archived (and thus recoverable) rather than deleted.

The automation is driven by a small Go webhook server and a dedicated controller repository that acts as the system's clock and memory. Four scheduled GitHub Actions workflows trigger specific tasks on a quarterly cadence:

• Day 1: Flag repos with no recent human activity and open a warning issue.
• Day 8: Snapshot outside collaborators and open a checklist issue for access review.
• Day 16: Archive repos that remain stale after the grace period.
• Day 23: Auto-revoke access for any review left unanswered.

State Management and Interaction Model

State is tracked as JSON files committed to the controller repository, creating an audit trail visible via git log. This eliminates the need for a separate database or bespoke audit pipeline. The interaction model relies on IssueOps: users receive a checklist issue in their repository, check boxes for collaborators to keep, and close the issue. Evergreen listens for the issues.closed webhook, retains checked collaborators, and revokes the rest.

To ensure security, only authorized users (Hubbers) can close access review issues; unauthorized attempts trigger a reopen and a notification. The system identifies the correct owners to notify using a fallback chain, checking for an evergreen_repo_owner custom property or recent issue/commit authors.

Implementation Challenges and Lessons

Rolling out Evergreen in an organization with over 1,400 Hubbers required careful handling of GitHub's API rate limits, specifically the secondary limits for content creation (80 requests/minute and 500/hour). Evergreen mitigates this by processing repositories in batches with deliberate pauses between calls. The team also utilized a DRY_RUN mode to log intended actions without executing them before going live.

Key lessons from the implementation include making the safe path the default, using existing platform primitives like issues and webhooks instead of building custom UIs, and respecting platform speed limits as a primary design constraint at scale.