Company
Zama builds open-source cryptographic tools for fully homomorphic encryption (FHE), enabling computation on encrypted data. Their FHEVM monorepo contains multiple interdependent services powering their blockchain protocol, with end-to-end tests that must validate across all components before any code reaches main.
Challenges
- • End-to-end tests across multiple services in a monorepo were run manually or per-PR, leading to missed breaking changes on main.
- • Rebasing before merge created friction: a small docs commit could force a full rebase of a large feature branch, wasting CI time.
- • Running full e2e tests for every PR was too expensive, but skipping them meant broken main.
Solutions
Zama's FHEVM monorepo contains multiple interdependent services that power their fully homomorphic encryption protocol. Before Mergify, merging was a constant source of uncertainty. End-to-end tests needed to validate across all services with their latest versions, but doing that for every PR was expensive and slow (some CI runs took over two hours). The team tried running e2e tests manually before merging, but that was unreliable: tests got skipped, PRs slipped through, and breaking changes made it to main without anyone noticing until later.
As Amina Waddiz put it: "We used to run the end-to-end tests for each PR, which was really expensive. As the protocol grew, it just wasn't possible anymore."
Rebasing added more friction. If a small documentation commit merged right before a large feature branch, the entire branch had to be rebased just to satisfy the merge requirements. Engineers spent time on mechanical git work that added no value.
The big win is that it stabilizes main. That's all we wanted. We have multiple projects in the same repo, and the end-to-end tests now guarantee that everything works before anything gets merged.
Clément Danjou
VP Blockchain
With Mergify's Merge Queue, the team no longer rebases manually. PRs go into the queue, and Mergify handles the rebase, runs the end-to-end tests with the latest versions of all services, and only merges if everything passes. The queue uses batches of 3 with a one-hour timeout, which matches their CI cycle well.
The end-to-end tests now run in about 30 to 50 minutes depending on Docker image builds. Two-step CI ensures lightweight checks run first, and the full e2e suite only runs in the queue when a PR is actually ready to merge. Nothing reaches main without passing the complete test suite.
We no longer need to rebase manually. The merge queue handles it, runs the e2e tests with the latest versions of all services, and only merges if everything passes.
AWAmina Waddiz
QA Director
Since adopting Mergify, Zama has had zero undetected breaking changes on main. The merge queue absorbs the complexity of coordinating multiple services in a monorepo, and the team has shifted their focus from merge logistics to actual development. Their release cadence (roughly every six weeks) doesn't demand continuous deployment speed, which means they can prioritize reliability over latency.
The team also highlighted Mergify's support as a differentiator: responsive and transparent, with issues resolved quickly on Slack. When issues come up, they get resolved quickly with clear communication. As Clément put it: "We have other partners on other topics where problems feel less transparent. With Mergify, it's fluid."
Other customer stories
Engineering teams we helped merge faster, safer, and cheaper
Move faster. Break less.
Purpose-built for teams who take delivery speed and reliability seriously.