[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live) [Help](/c/help/9) # How do you use Vercel with trunk-based development? 181 views · 1 like · 5 posts k (@accounts-5388) · 2025-11-12 <!-- Questions that get answered the fastest are the ones with relevant info included in the original post. Be sure to include all detail needed to let others see and understand the problem! --> <!-- Current versus Expected behavior --> <!-- Code, configuration, and steps that reproduce this issue --> <!-- Project information (URL, framework, environment, project settings) --> I want to implement true trunk-based development where every push to `main` automatically progresses through multiple environments: dev → beta → staging → production. Vercel's native model seems designed around branch-per-environment (e.g., `main` = prod, `staging` branch = staging), which doesn't fit this workflow. **What I'm looking for:** * Single `main` branch as the source of truth * Automated progressive deployment through multiple environments * Each environment gets the same build artifact **Potential approach:** Create separate Vercel projects (`myapp-dev`, `myapp-beta`, `myapp-staging`, `myapp-prod`) and orchestrate deployments via CI/CD (GitHub Actions, etc.) to deploy the same build to each project sequentially. **Questions:** * Is this the standard workaround, or is there a better way? * Has anyone gotten Vercel's promotion/alias features to work for this use case? * Should I be using a different platform entirely for trunk-based CD? Would love to hear how others have solved this! Jacob Paris (@jacobparis) · 2025-11-12 If you go to /settings/environments in your project, you can create each environment and set it to track the appropriate branch Then you can set the production environment to track a `production` branch instead of `main`  Amy Egan (@amyegan) · 2025-11-12 I've seen teams use a few different approaches. Instead of sending all commits to `main` straight to production, you can stage and promote to production when you're ready to publicly release the change. https://vercel.com/docs/deployments/promoting-a-deployment#staging-and-promoting-a-production-deployment A lot of teams just use branches for feature development a previews before merging to `main` when the feature is safe to include and deploy to production. https://vercel.com/blog/how-chatbase-scaled-rapidly-with-vercels-developer-experience-and-ai-sdk#current-architecture-and-benefits Some people use Vercel CLI with GitHub Actions to build a custom release workflow. https://rdrn.me/vercel-trunk Dom wrote a quick-reference guide about the pros and cons of trunk-based development and gitflow. I'm not sure this is exactly relevant to you, but I'm including it in case it helps anyone else joining this conversation. https://community.vercel.com/t/trunk-based-development-vs-gitflow-cheatsheet/16818 Dom Sipowicz (@dom-vercel) · 2025-11-12 · ♥ 1 > Each environment gets the same build artifact This is not recommended and not possible on next.js build. You cannot change ENV variables at runtime. If you want to change something on runtime on same build then use feature flags, Edge Config for that. You don’t want to change environment variables. You probably will end up with different environment so you want to build it first (and then run CI stages like unit tests, linters, checks etc… you don’t want to do that on runtime). What you probably want is gated releases. That can be automatic or human in the loop gates. You can achieve that with GitHub Actions or [Vercel Checks](https://vercel.com/docs/checks) or simple setup with Rolling Releases. > **Potential approach:** Create separate Vercel projects (`myapp-dev`, `myapp-beta`, `myapp-staging`, `myapp-prod`) and orchestrate deployments via CI/CD (GitHub Actions, etc.) to deploy the same build to each project sequentially. This can work and some enterprises do that. Alternatively you can use what was mentioned above with [Vercel Custom Environments](https://vercel.com/docs/deployments/environments#custom-environments). However I have the feeling that what is most important for you is this “gating” to kick of next environemnt deployment where you run some CI steps or “checks”. In this case you want custom GitHub Actions or Vercel Checks. I personally would reduce the number of environemnts and simply use [manual rolling release](https://vercel.com/docs/rolling-releases) as final gating and that’s it. Amy Egan (@amyegan) · 2026-01-23 Hey @accounts-5388! 🌟 Just checking in to see if you still need help with implementing trunk-based development using Vercel. Have you found any solutions, or would you like to dive deeper into the topic together? Thanks for sharing your question! 😊
