Overview
Environments let you run multiple isolated copies of your solution. Every solution starts with two environments:| Environment | Purpose |
|---|---|
dev | Your editable development workspace |
production | Your protected live environment |
production is isolated from direct changes. Make changes in dev or another non-production environment, test them there, then apply them to another environment with a merge request.
| Setup | Environments | When to use |
|---|---|---|
| Default | dev, production | Every solution starts here |
| Per feature | feature-auth, bugfix-123 | Work on isolated changes, then merge them |
| Classic pipeline | dev → staging → production | Promote changes through validation stages |
| Per developer | alice-dev, bob-dev | Each dev has their own sandbox |
Why Use Environments
Safe experimentation
Test new features, try risky changes, debug issues — without affecting production.
Team workflows
Developers work in editable environments, QA tests in staging, users see production. No conflicts.
Different configurations
Each environment can have its own resources, variables, and secrets.
Merge requests
Review isolated code and variable changes before applying them to another environment.
How Environments Work
Each environment belongs to a solution. It starts as a copy of another environment, then becomes independent: When you create an environment, Ardor copies the source environment’s services and settings. After that, changes in one environment do not automatically affect any other environment. What’s independent per environment:- Services code
- Internal URLs
- Public URLs
- Environment variables and secrets
- Deployment history
Changes in code and variables stay inside the environment where you made them until you apply them to another environment with a merge request.
Creating Environments
New environments are created from an existing environment. Ardor copies the source environment’s services and settings so the new environment starts from the same shape. Just ask Cerebrum to create an environment for you:“Create a new environment calledfeature-authfromdev”
“CreateOnce created, you can switch between environments using the dropdown in the UI.stagingfromproduction”
Environment Isolation
Environments are isolated after creation:| What | Isolated? | Notes |
|---|---|---|
| Services | ✅ Yes | Copied when the environment is created, then managed independently |
| Internal URLs | ✅ Yes | Different per environment |
| Public URLs | ✅ Yes | Different per environment |
| Variables & Secrets | ✅ Yes | Configure independently per environment |
| Code | ✅ Yes | Each environment has its own service code state in an environment branch |
| Data | ✅ Yes | Databases are separate |
| Logs | ✅ Yes | Each env has its own logs |
Protected Production
production is protected from direct changes. This keeps the live version stable and makes production updates reviewable.
Typical workflow:
- Make code or variable changes in
dev,staging, or a feature environment - Test the changed environment
- Open a merge request to apply the changes to
production - Review and merge when ready
Other environments are editable directly. Use merge requests when you want to move changes from one environment to another.
Code and Variables Per Environment
Each environment has its own code state, variables, and secrets. Changes stay local to that environment until merged:| Variable | dev | staging | production |
|---|---|---|---|
DEBUG | true | true | false |
LOG_LEVEL | debug | info | warn |
DATABASE_HOST | service-abc...:5432 | service-def...:5432 | service-ghi...:5432 |
API_KEY | test_key_xxx | test_key_yyy | live_key_zzz |
Best Practices
Use dev for everyday work
Use dev for everyday work
Every solution includes
dev. Make direct changes there or in feature environments, then promote reviewed changes with merge requests.Do not change production directly
Do not change production directly
Production is protected for stable, live workloads. Apply production updates through merge requests.
Keep environments similar
Keep environments similar
Create staging or feature environments from the environment they should resemble. This keeps services, settings, and variables aligned from the start.
Use consistent variable names
Use consistent variable names
Same variable names across all environments. Only values differ. This keeps your code clean.
Clean up unused environments
Clean up unused environments
Delete feature branch environments after merging. They cost resources and add clutter.
Document your environments
Document your environments
Make it clear what each environment is for. Who uses it? What’s deployed there?
Troubleshooting
Wrong environment deployed to
Wrong environment deployed to
Double-check which environment is selected before deploying. The environment name is shown in the UI.
Service works in dev but not staging
Service works in dev but not staging
Check environment-specific variables and whether the latest changes were merged into staging. A missing, outdated, or wrong variable is the most common cause.
Can't connect to service in another environment
Can't connect to service in another environment
Environments are isolated — you can’t use dev’s internal URL from staging. Each environment has its own URLs.
Production does not show my changes
Production does not show my changes
Production is protected from direct changes. Open and merge a merge request from the environment that contains the tested changes.
What’s Next
Merge Requests
Apply code and variable changes between environments
Variables & Secrets
Configure environment-specific settings
Deployments
Deploy services to different environments
Networking
Understand how services connect within environments
Services Overview
Learn about services and their configuration