The shortest path from pull request to green main.
Code gets written faster every year. What holds a team up now sits after the pull request: CI runs that take an hour, and tests that fail without anyone touching them. That is the part we build.

Our Story
Julien Danjou and Mehdi Abaakouk did not start from a business plan. They started from OpenStack, Debian, and Python: projects where hundreds of people push to the same branch and one bad merge costs everybody their afternoon. Those communities had already solved it. Zuul and Bors did the same job in different places: no change landed on the main branch until CI had tested it there. Both came as a bot you had to run and keep alive yourself.
Most engineering teams have better things to do than operate a merge bot. So in May 2018, a few weeks after the first commit, Mergify started rebasing and merging pull requests one at a time, so nothing landed on main without being tested against what was already there. By October it had ordering and priorities. The engine was open source back then, and those commits still carry their 2018 dates.
That is the whole origin story. No pivot, no rebrand. We wanted what those projects had, for everybody else, and we were the first to sell it.

The Origin Story of Merge Queues
Ben Elliston's cron jobs, Graydon Hoare's Bors, Zuul, Shopify's Shipit, and how a pile of side-project bots became something you can buy. Julien wrote the long version, with the people behind each one.
Nobody owns us but our customers
Every engineer we hired was paid for by somebody who bought the product. It shows up in the roadmap: the teams running the queue are the only people we have to keep happy, and our pricing never has to fund somebody's exit.
Venture money into merge queues and CI reliability since we opened the category. Flattering, and not our problem.
Used by the platform teams that ship fast and keep CI green
Where this goes next
The merge queue answered a human-speed problem: a few dozen engineers pushing to one branch, with a review bottleneck in front of them. That constraint is going away. Agents open pull requests faster than any team can read them, and the limit has moved to CI itself.
Know which jobs and tests are actually breaking your CI
Stop flaky tests from deciding what ships
Get changes onto main without ever breaking it
Keep big changes reviewable on the way in
So the product stopped being a merge queue a while ago. It covers the span between a pull request and a green main branch, and that whole span is where the next few years go: enough context travelling with a change that CI can work out what actually needs to run, instead of running everything and hoping the bill holds. The docs are the honest version of what exists today.
It is the same bet we made at the start, which is that the unglamorous machinery between writing code and shipping it deserves to be built properly. We wrote a formal specification of the queue in TLA+ and pointed a model checker at it. It walked 468,000 states in under a minute and found two bugs that our test suite and years of production traffic had both missed. We have not seen another merge queue vendor publish one.
The Team
A small team of engineers and one designer, spread across France and the Netherlands. We work remotely, ship constantly, and meet up quarterly to cook, debate, and occasionally agree on things. Here's what we care about:
Openness & Ownership
Everyone at Mergify has a voice and the autonomy to make things happen. We take responsibility for what we build, and we question how things are done.
Efficiency & Simplicity
We aim for boring solutions, avoid unnecessary complexity, and ship iteratively. We care more about what works than what's shiny.
Collaboration & Communication
We embrace asynchronous work and default to transparency. Good ideas can come from anywhere, and context is key to good decisions.
Inclusion & Well-being
Great work happens when people feel safe, trusted, and respected. We meet quarterly for retreats, cook together, debate ideas, and have fun along the way.

Julien Danjou
Founder & CEOJulien writes Python books, builds open-source projects that end up on Mars, smokes meat like a pitmaster, ranks in the top 1% of FPS players, and still finds time to run a startup. He became the youngest Debian developer in 2002 and has contributed to Emacs, Python, OpenStack, and more projects than he can count.


Alexandre Gaubert
Software EngineerAlex is a frontend engineer from Brittany who turns Figma mockups into pixel-perfect TypeScript like it's a warm-up set. When he's not bending CSS to his will, he's either walking his dogs or lifting something heavier than your average webpack config. Strong code, strong biceps.
Maybe you
Open rolesWe add people slowly and we hire senior. If the rest of this page sounds like somewhere you would want to work, the open roles are on the careers page.

Mehdi Abaakouk
Founder & CTOMehdi is a swing-dancing engineer from Toulouse who brings the same rhythm to system architecture. He's contributed to OpenStack, Python, Ceph, and most things that run on servers and matter. He went from bootstrapping startups to scaling Mergify's infrastructure, and he does both with an unsettling level of calm.


Frank Lagendijk
Product DesignerFrank has been tinkering with design since he was 14 and built the Mergify dashboard from scratch. A decade of product design across venture-backed SaaS companies taught him that the best interface is the one you don't notice. He works from Utrecht and has opinions about whitespace.


Julian Maurin
Software EngineerJulian is meticulous about code the way some people are meticulous about watch movements. He likes clean abstractions, well-tested edge cases, and systems that do exactly what they're supposed to. Quietly productive, consistently reliable.

Thomas Berdy
Software EngineerCo-founded a startup and shipped open source packages on PyPI while running his own consulting practice. Thomas has been writing Python backends for nearly a decade. When he's not deep in async systems and PostgreSQL, he's probably tinkering with CLI tools or data pipelines.
Distributed By Design
We've worked remotely since day one. Coming from open-source communities, async collaboration and written communication are how we've always operated. It's comfortable, and it works.
Our team is spread across Europe, and we organize around flexibility and trust. We take ownership, communicate openly, and show up when it matters. We also know remote work can get isolating, so we make space to connect: casual chats, quarterly retreats, and too many food photos in Slack.
Move faster. Break less.
2k+ organizations use Mergify to merge 75k+ pull requests a month without breaking main.
