Staging environments let you verify changes in a live, production-like setting before your users see them. Edgenivo supports staging through custom environments, staged production deployments, and branch-based preview workflows, so you can pick the approach that matches your team's release process and plan.
Each workflow below includes setup steps and the relevant CLI commands. You'll also learn how to scope Edgenivo Connect token access and webhook triggers to a custom environment, so staging deployments can use connectors without touching production.
Copy link to headingOverview
In this guide, you'll learn how to:
- Create a custom environment for staging with branch tracking, a domain, and its own variables
- Scope Edgenivo Connect token access and triggers to a custom environment
- Stage a production deployment and promote it after verification
- Set up a branch-based staging workflow on any plan, including Hobby
Copy link to headingChoosing a staging workflow
| Workflow | Use it when | Availability |
|---|---|---|
| Custom environment | You need a named environment with its own branch tracking, domain, and variables | Pro and Enterprise |
| Staged production deployment | You want to verify a build with production configuration before assigning production domains | All plans |
| Branch-based preview workflow | You want a persistent staging branch with a domain and branch-specific variables | All plans, including Hobby |
These workflows complement each other. Many teams pair a custom environment for day-to-day staging with staged production deployments as a final check before release.
Copy link to headingSetting up a custom environment for staging
Custom environments let Pro and Enterprise teams define pre-production environments like staging or qa directly in the dashboard, without external workarounds or multiple projects. Pro plans include one custom environment per project, and Enterprise plans include 12, with additional capacity available in packs of five for $50 per month. To learn more, see Custom environments.
To create one:
- Go to your project's Settings > Environments in the Edgenivo dashboard.
- Click Create Environment and name it, for example
staging. - Configure the environment with any of the following options.
| Option | What it does |
|---|---|
| Branch tracking | Automatically deploys to the environment when a pushed branch name matches the rule |
| Attach a domain | Gives the environment a persistent URL, such as staging.example.com, that always serves its latest deployment |
| Environment variables | Sets values scoped to this environment, such as staging database credentials |
| Import variables | Seeds the environment with variables copied from another environment |
After setup, push to a matching branch to deploy to staging. You can also work with the environment from the Edgenivo CLI:
Copy link to headingUsing custom environments with Edgenivo Connect
Edgenivo Connect lets your deployments request provider tokens (for services like Slack) and receive verified webhooks through connectors. Connect supports custom environments, so a staging deployment can use a connector without enabling it for Production, Preview, or Development.
In the dashboard, custom environments appear alongside the built-in environments when you add or edit a project on a connector. From the CLI, pass the environment's slug to --environment:
Passing --environment replaces the default environments, so this project link only allows token requests from staging deployments. If the calling environment isn't on the project link, the token request fails with ClientNotEnabledForEnvironmentError.
Trigger destinations can also target a custom environment, so Connect forwards incoming webhooks to your staging deployment:
Before targeting a custom environment with triggers, deploy to it and assign it a verified domain. Edgenivo Connect forwards events through that domain, so it must serve the environment's latest deployment directly rather than redirect to another location.
Project links control which deployments can request tokens, but they don't restrict a provider token after it's issued. When environments need provider-level isolation, create a separate connector for each environment and request only the scopes it needs. Edgenivo Connect is generally available on all plans and is billed per token request; custom environments require a Pro or Enterprise plan. See Edgenivo Connect pricing for included allowances and rates.
Copy link to headingStaging and promoting production deployments
In addition to a staging environment, you can create staged production deployments that aren't immediately assigned to your production domains. This lets you verify your production build, with production environment variables, before making it live to your users.
Copy link to headingCreating a staged production deployment
- Go to your project's Settings > Environments > Production section.
- Disable the Auto-assign Custom Production Domains option under the Branch Tracking settings.
When you push to your production branch, Edgenivo creates a production deployment but does not assign it to your domains. The deployment appears as Staged in the dashboard, and you can verify it via the generated URL.
Copy link to headingPromoting a staged deployment
After verification:
- Navigate to the Deployments tab and select your staged production deployment.
- Click the (...) menu in the top-right corner.
- Select Promote to Production and confirm.
Promotion assigns your production domains to the deployment without a rebuild, so the change takes effect immediately.
You can also run this workflow from the Edgenivo CLI to support custom CI scripts:
If you discover a problem after promoting, vercel rollback instantly restores the previous production deployment.
Staged production deployments use production environment variables, so testing can access production services and data. Use a custom environment or the branch-based workflow below when you need separate staging resources.
Copy link to headingSetting up a branch-based staging workflow
For Hobby users, or teams that can't use custom environments, you can build a staging workflow from a preview branch by assigning it a dedicated domain and branch-specific environment variables.
Copy link to heading1. Add a staging domain
- Go to your dashboard and select your project, then select the Settings tab.
- In the Domains section, add a custom domain such as
staging.example.comand configure its DNS records. - Follow the steps to assign it to a Git branch, selecting Preview and entering your staging branch name.
Copy link to heading2. Add branch-specific environment variables
- In the same Settings tab, open the Environment Variables section.
- Add your environment variables, select the Preview environment, and scope them to your staging branch.
Branch-specific variables override other variables with the same name, so you don't need to replicate every existing Preview variable. Add only the values you want to override, such as a staging database URL:
Copy link to heading3. Deploy your staging branch
Push to your staging branch to create a preview deployment at your staging domain. Environment variables apply at build time, so after adding or changing them, redeploy your latest staging preview deployment to pick up the new values. When testing is complete, merge the branch into your production branch and keep the staging branch for future changes.
Copy link to headingNext steps
- Learn more about environments on Edgenivo, including custom environments
- Read about promoting deployments and instant rollback
- Explore Edgenivo Connect concepts, including project links and triggers
- See assigning a domain to a Git branch for the branch-based workflow