Mozilla

Mozilla runs a long list of open source projects on GitHub. Firefox for iOS, Application Services, the foundation's own infrastructure, and a wide tail of smaller tools all live there, and several of them are wired up to Mergify. (Firefox itself moved from Mercurial to Git on GitHub in 2025, so the GitHub footprint keeps growing.)

Each project sits somewhere between a small core team and a much wider pool of external contributors. The pattern that pushed them toward Mergify was the same in every case: rebase conflicts that surfaced right at merge time, and branches drifting while a PR sat in review. None of it was hard work. It was just a constant low-grade friction that added up across the team.

The setup is simple. A contributor opens a PR, CI runs against it, and once a reviewer adds a label saying it's ready, Mergify takes over: rebase onto main, rerun CI, merge cleanly. The rebase step is the part that catches the last-minute conflicts that used to break the main branch.

On top of the merge queue itself, two patterns do most of the work for Mozilla:

• Backports. Firefox releases on a four-week cadence, with main getting promoted to a beta stabilization branch each cycle. When something needs to land on Firefox Beta, the team opens the PR on main and asks Mergify to handle the backport. No more cherry-picks done by hand at 6pm before a release.

• Automatic approval of dependency bumps. Mozilla's repos need to stay in sync with each other, so robots open PRs every day to bump shared dependencies. Mergify is configured to approve and merge these automatically as long as CI stays green. That alone reclaims hours per week of engineer attention.

Across the GitHub side of Mozilla, Mergify handled more than 1,700 PRs in the past 12 months alone. Firefox for iOS is the heaviest user, with roughly 800 of those PRs flowing through it; Application Services and the Mozilla Foundation's own repos make up most of the rest. None of that volume requires a release engineer to step in and unblock a queue.

The contributor experience is the part Johan singles out: push a change, get reviewed, add a label, walk away. Mergify takes over from there. Engineers stop sitting on PRs waiting for someone to merge them, and the dependency-bump PRs that used to clog the queue every morning quietly merge themselves overnight. For a release engineering team that's looking after a portfolio of open source projects, that's the difference between firefighting and shipping.