Deploying safely on Vercel without merge queues

Why Merge Queues Slow Down CI

Keeping the main branch green is a common requirement, but it gets expensive as teams grow. When every branch must be synced to HEAD before merging, developers end up rebasing repeatedly and rerunning the same checks. A merge queue is often proposed as the fix, but it brings its own inefficiencies: every commit is tested at least twice, and commits are processed serially even when they touch unrelated parts of the codebase.

The result is repeated work and long merge times. A merge queue must re-run checks against the latest HEAD of main, so a single commit can be tested multiple times as other commits land ahead of it. While batching optimizations exist, they don't eliminate the fundamental issue: developers are blocked by changes they have nothing to do with. This becomes especially painful in monorepos where many contributors are merging frequently.

Moving Checks After the Build

Vercel's default behavior is to promote a production deployment to your aliased domains as soon as the build succeeds and Vercel Checks pass. That works for many teams, but it leaves no room for additional validation between build completion and end-user exposure.

You can now disable automatic promotion of production deployments. With this option enabled, Vercel still builds a production deployment for every commit on the main branch, but it doesn't assign that deployment to your production domains. The deployment stays in a staging state until you explicitly promote it—via the CLI, API, or the Vercel dashboard.

This creates a window for custom checks. For example, you can run integration tests or QA against the production build before users ever see it, then promote the deployment once those checks pass.

Promoting Manually After Checks

When a production deployment finishes building, Vercel dispatches a deployment_status webhook event. Your CI system can listen for that event and run any required validation against the deployment URL. Once checks are complete, a single vc promote command makes the deployment live.

// Ensure that all checks pass
const token = process.env.VERCEL_API_TOKEN;
const scope = process.env.VERCEL_TEAM_ID;
await execaCommand(
  `npx vercel --scope ${scope} --token ${token} promote ${deploymentId}`,
);

Vercel uses this pattern internally with GitHub Actions: listening for the deployment_status event, running an integration test suite against the production deployment, and then promoting via a GitHub Action that invokes vc promote. This adds a safety gate without requiring developers to sync branches or wait in a queue.

Removing the Merge Queue

With checks running after the production build instead of before merge, the merge queue becomes unnecessary. Commits can land on main immediately. Some commits may fail CI, but those failures are caught before the deployment reaches production and can be reverted without user impact.

The trade-off is accepting that the main branch may occasionally be red. But the cost of a bad commit is limited to the time it takes to detect the failure and revert—not a round-trip through the merge queue. Teams get faster merges and the same production safety, without the serial bottleneck that merge queues introduce.