We’re trying to configure a staging branch in Vercel that has the same “build first, promote later” pattern that’s available for production branches in Vercel. Meaning, we want to use the pattern of building the site first (without auto-assigning the URL) and then promoting it later to the active version of the site on that branch. This is necessary because we don’t want to promote the newest build of our custom (staging) branch until after our migrations run (outside of Vercel) for it.
Is this possible in Vercel? It’s essentially like having two production branches. Our production application is on the main branch and our staging version is on staging branch.
Promotion is certainly supported in the default “production” branch and well-documented. And while the docs mention you can promote your staging branch to production (see: https://vercel.com/guides/set-up-a-staging-environment-on-vercel) I don’t think this is what we want. We want to have two completely different deploy life-cycles.
The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points.
You can also use v0 to narrow down the possibilities.
If I understood correctly: You can do this by assigning a custom domain to your staging branch and using Vercel’s promotion workflow with that domain.
First, set up a staging domain like staging.yourdomain.com and attach it to your staging branch in your project settings.
Once that’s done, turn off auto-assignment so new deployments on that branch don’t immediately take over the domain. That way nothing gets promoted until you choose to.
After your migrations finish, you can manually promote the exact deployment you want to serve on the staging domain either from the Vercel dashboard or by using the CLI.
The idea is to treat your staging branch the same way you treat production: give it its own domain, then promote deployments to that domain only when they’re ready. Once that custom domain is tied to the branch, you get the same “build first, promote later” workflow that production uses.
If you prefer the CLI, you can promote a deployment with: