


Ship as fast as safely possible.
Every team wants speed and a green main. When you move money, a red main or a bug that slips through costs more. You can't buy speed by skipping checks.
One controlled path to green main
For the way fintechs ship
Throughput that holds at scale
Parallel, Bazel/Nx-aware queues test non-overlapping PRs at once, so one bad PR can't stall the rest. Batching up to 100 cuts CI cost 60–80%. Hotfixes take a priority lane.
Detect, quarantine, and root-cause flakiness
Flakes are quarantined without a code change, so they stop blocking merges but keep running, and a broken test is never auto-quarantined. Fingerprinting and full history point at the few root causes behind most flakes.
Governed exceptions, gated by role
Force-merge is admin-only, tested before it lands, and badged. Deliberate and attributable, never a silent push to main. You decide who can force-merge and who can quarantine.
“We would have never known how many flaky tests we had exactly, or to what level each of them was flaky. Now we say it meets this level, and that's it. It's quarantined.”
Release Infrastructure
Your merge gate is your audit evidence.
SOX ITGC, SOC 2 CC8.1, PCI DSS, DORA. They all ask the same thing of every production change, and the merge queue is where you prove it. Every change is tested, reviewed by a second person, and recorded. That's the evidence auditors sample, produced as a byproduct of shipping. Flaky-test detection keeps those checks trustworthy.
The security review, pre-answered
What Trunk can access
Merge Queue needs write access to operate: the GitHub App requests Contents, Checks, Actions, Issues, Pull Requests, and Workflows (read/write), plus Administration read-only for branch-protection rules, which it cannot change. Force-merge is a separate opt-in app, and repo-subset installs limit which repos Trunk touches. Flaky Tests needs only your test results in JUnit XML format.
What data leaves, and for how long
Data is encrypted in transit and at rest, in US-based AWS. The full subprocessor list includes the AI providers we use for failure analysis. Trunk keeps it 45 days. For longer retention, stream it to your own store, or run everything in your own account with Bring your own cloud.
Certifications and paperwork
Frequently asked questions
Does quarantining skip flaky tests?
No. A quarantined test keeps running and reporting — it just stops blocking merges. Every quarantine is logged with a reason and an owner, protected suites can be excluded, and consistently failing tests are never auto-quarantined.
We're on GitHub's merge queue today. What's the migration story?
It's our most common path in. Where GitHub runs a single serial queue, Trunk runs parallel, batched, flake-aware queues that use your build graph, so unrelated PRs stop blocking each other (full comparison). Migrating is easy: turn off GitHub's merge queue in your branch settings, enable Trunk Merge Queue on the repo, and cut over. You can run both at once first, with Trunk's PR comments muted, to evaluate quietly before the switch.
Will Trunk have access to our source code?
Flaky Tests: no — it consumes only test results in JUnit XML format. Merge Queue: yes, it needs Contents read/write to build and merge queued branches, which is inherent to operating a queue. But we do not retain repository content on our servers, every scope is documented, and repo-subset installs limit which repos the app touches.
What happens to merges if Trunk is down?
The queue fails safe and visibly: pause/unpause, polling mode for GitHub degradation, and role-restricted break-glass merge so an incident fix never waits on us. Uptime history is public.
We're rolling out coding agents. How does Trunk help?
In two ways. Agents fork from main, so keeping main green means their tokens go to the task instead of debugging someone else's flake, which matters as more and more code becomes AI generated. Secondly, Trunk's MCP server hands an agent the full history of a flaky test, its past failures, stack traces, and git context, so it works from the pattern instead of guessing off the last CI run.
