Overview
Environments let you run multiple isolated copies of your solution. Create as many as you need — for features, experiments, testing, production, whatever makes sense for your workflow.| Setup | Environments | When to use |
|---|---|---|
| Per feature | feature-auth, bugfix-123 | Working on specific tasks, delete after merge |
| Classic pipeline | dev → staging → prod | Traditional promotion flow |
| 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 dev, QA tests in staging, users see production. No conflicts.
Different configurations
Each environment can have its own resources, variables, and secrets.
Feature branches
Spin up temporary environments to test feature branches before merging.
How Environments Work
Each environment belongs to a solution and is completely independent: What’s independent per environment:- Services and their code
- Internal URLs (each service gets a unique URL per environment)
- Public URLs
- Environment variables and secrets
- Resource allocation (CPU, RAM, storage)
- Deployment history
Changes in one environment never affect another. You can delete your entire development environment and production keeps running.
Creating Environments
Just ask Cerebrum to create an environment for you:
“Create a new environment called feature-auth”
“Set up a production environment”Cerebrum will create the environment and set up any services you need. Once created, you can switch between environments using the dropdown in the UI.
Environment Isolation
Environments are fully isolated:| What | Isolated? | Notes |
|---|---|---|
| Services | ✅ Yes | Each env has its own instances |
| Internal URLs | ✅ Yes | Different UUID per environment |
| Public URLs | ✅ Yes | Different UUID per environment |
| Variables & Secrets | ✅ Yes | Configure independently |
| Code | ⚠️ Git-based | Isolated by branches — use different branches per environment |
| Data | ✅ Yes | Databases are separate |
| Logs | ✅ Yes | Each env has its own logs |
Managing Services Across Environments
Each environment has its own set of services. When you create a new environment, you start fresh — no services are copied automatically. Typical workflow:- Build your solution in
development - When ready, recreate services in
stagingwith the same configuration - Test in staging
- Recreate in
productionfor launch
Coming soon: Service inheritance between environments — create a service once and deploy it to multiple environments with different configs. Tell us if you need this now!
Variables Per Environment
Each environment has its own variables and secrets. This is how you configure environment-specific settings:| Variable | Development | 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 |
Coming soon: Variable presets — define a set of variables once and apply them to multiple environments. Let us know if you need this!
Deployment Strategies
Promote Through Environments
A common pattern is to promote code through environments:- Develop and test in
development - Deploy to
stagingfor final validation - Deploy to
productionfor users
Feature Branch Environments
Create temporary environments for feature branches:- Create environment
feature-auth - Develop and test the feature
- Merge to main, deploy to production
- Delete the feature environment
Resources Per Environment
Each environment can have different resource allocations:| Environment | Typical Resources | Why |
|---|---|---|
| Development | Minimal (0.1 CPU, 256MB) | Cost savings, quick iteration |
| Staging | Production-like | Realistic testing |
| Production | Based on load | Performance for users |
Best Practices
Never test in production
Never test in production
Always have at least a development environment. Production is for stable, tested code only.
Keep environments similar
Keep environments similar
Staging should mirror production as closely as possible — same services, similar resources. This catches issues before they hit users.
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. A missing 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.
What’s Coming
We’re working on features to make environments even more powerful:- Service inheritance — Create a service once, deploy to multiple environments
- Variable presets — Define variable sets and apply them across environments
- Environment renaming — Rename environments without breaking things
- Environment cloning — Duplicate an entire environment with one click
Request Features
Need any of these features now? Let us know in the community — we prioritize based on feedback!