Trunk vs Aviator

Both work with any CI provider that reports status checks to GitHub - Actions, CircleCI, Buildkite, Jenkins, and more. Both queues manage GitHub repositories; neither supports GitLab-hosted repos.

Both queues can use a downstream PR's passing result as proof that an earlier failure was a flake and merge both PRs. The differences are in the limits and the inputs. Aviator's optimistic validation is hard-capped at a depth of 3 and works from CI signals alone. Trunk's pending failure depth is configurable, and Trunk Flaky Tests quarantines known-flaky tests inside queue CI runs - any language, any test runner - so known flakes never fail a queue run in the first place. Aviator's flaky test product (TestDeck) is in beta, supports auto-rerun for pytest only, and is not integrated with queue decisions.

Both batch PRs into one CI run and bisect on failure. The difference is what a bisection costs. Aviator handles a failed batch by closing it and requeuing the PRs into two smaller batches, which re-test from scratch. Trunk bisects in place with test caching - combinations already known to fail are never re-run - and uses dedicated bisection concurrency, so failure isolation doesn't consume queue throughput or send PRs back to the end of the line.

Both products can split a monorepo into dynamic, independent queues based on the targets a PR affects - disjoint changes test and merge independently, overlapping changes stack. The differences are in getting there. Aviator's parallel mode alone is still a single logical queue with concurrent CI; independent queues require affected targets, where your team implements the target computation (bazel-diff, Nx CLI, or directory rules) and wires it to their API - available on their Scale plan. Trunk ships first-party Bazel and Nx actions that compute and upload impacted targets, and parallel mode is included in standard pricing.

When a PR is based on the tip of main, its lane is empty, and its checks are already green, Trunk merges in seconds without re-running CI - the speculative run would test the exact state the PR's own CI already validated, so nothing is skipped. It's on by default and requires no special permissions. Aviator's instant merge covers a different need: a manual, label-triggered break-glass that skips queue validation regardless of queue state - and skipping the PR's own CI as well requires a branch-protection bypass for the Aviator app.

Trunk supports granular priority levels (urgent, high, medium, low, or 0-255); anything below urgent reorders the queue without restarting in-flight tests. Aviator's skip_line label is binary, and in parallel mode their docs note it resets all parallel PRs behind it - a full cascade rebuild - unless affected targets is configured.

A merge queue depends on webhooks, status checks, and the merge API simultaneously - making it uniquely sensitive to GitHub instability. When a webhook goes missing, Trunk catches up on its own: stuck queue entries and externally merged PRs are reconciled automatically, with no human in the loop. Aviator handles the same situation with a manual, per-PR /aviator refresh command - someone has to notice the stuck PR and comment on it before the queue re-examines it.

Trunk's free tier includes the full merge queue - parallel mode included - for teams up to 5 committers. Aviator's free plan does not include MergeQueue; it starts on the Team plan at $20/dev/month, with monorepo affected targets on the Scale plan at $40/dev/month.

Both Trunk and Aviator are SOC 2 Type II certified.

Both support SAML-based SSO on Enterprise plans.

Trunk includes 24/7 PagerDuty on-call for system-critical issues on Enterprise. Aviator offers community support on Free, email support on Team and Scale, and Slack Connect on Enterprise, with no published response-time SLA at any tier.