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?
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.
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.
Some people use Vercel CLI with GitHub Actions to build a custom release workflow.
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.
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.
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!
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! 