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

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

vercel.com

Promoting Deployments

Learn how to promote deployments to production on Vercel.

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

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 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.

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 as final gating and that’s it.

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! 😊