Parent Environments
Parent environments are a powerful feature in Nidra that allows you to create hierarchies of environments with inheritance, dramatically reducing duplication and making configuration management easier.
What are Parent Environments?
A parent environment is an environment that other environments can inherit from. Child environments get all variables from their parent but can override specific values.
Parent: Common
├── Child: Development (inherits from Common)
├── Child: Staging (inherits from Common)
└── Child: Production (inherits from Common)
Why Use Parent Environments?
Parent environments solve common problems:
- Reduce duplication: Define shared variables once
- Easier maintenance: Update common values in one place
- Consistency: Ensure all environments share base configuration
- Organization: Clear hierarchy of configurations
- Flexibility: Override only what's different
Basic Example
Without Parent Environments (Repetitive)
Development Environment:
apiKey: dev_abc123
timeout: 5000
retryCount: 3
debugMode: true
baseUrl: https://dev-api.example.com
Staging Environment:
apiKey: staging_xyz789
timeout: 5000 ← duplicated
retryCount: 3 ← duplicated
debugMode: true ← duplicated
baseUrl: https://staging-api.example.com
Production Environment:
apiKey: prod_pqr456
timeout: 5000 ← duplicated
retryCount: 3 ← duplicated
debugMode: false
baseUrl: https://api.example.com
With Parent Environments (Clean)
Common (Parent):
timeout: 5000
retryCount: 3
debugMode: true
Development (Child of Common):
apiKey: dev_abc123
baseUrl: https://dev-api.example.com
Staging (Child of Common):
apiKey: staging_xyz789
baseUrl: https://staging-api.example.com
Production (Child of Common):
apiKey: prod_pqr456
debugMode: false ← overrides parent
baseUrl: https://api.example.com
All children inherit timeout and retryCount from Common!
Creating Parent Environments
Create the Parent
- Click "Environments"
- Click "New Environment"
- Name it descriptively (e.g., "Common", "Shared", "Base")
- Add shared variables
- Save
Create Children
- Create a new environment
- In the settings, select "Parent Environment"
- Choose the parent from the dropdown
- Add only environment-specific variables
- Save
Viewing Inherited Variables
In a child environment:
- Inherited variables are shown in a different color or style
- Overridden variables are highlighted
- Environment-specific variables are shown normally
You can see the complete resolved set of variables for the environment.
Advanced Patterns
Multi-Level Hierarchy
You can create multi-level hierarchies:
Common (parent: none)
├── API-Common (parent: Common)
│ ├── API-Development (parent: API-Common)
│ ├── API-Staging (parent: API-Common)
│ └── API-Production (parent: API-Common)
└── Auth-Common (parent: Common)
├── Auth-Development (parent: Auth-Common)
└── Auth-Production (parent: Auth-Common)
Regional Variations
Manage multi-region deployments:
Production (parent: none)
├── Production-US (parent: Production)
├── Production-EU (parent: Production)
└── Production-APAC (parent: Production)
Production:
timeout: 10000
apiVersion: v2
enableAnalytics: true
Production-US:
baseUrl: https://api-us.example.com
region: us-east-1
Production-EU:
baseUrl: https://api-eu.example.com
region: eu-west-1
dataResidency: true ← EU-specific
Service-Specific Environments
Organize by microservice:
Common
├── Users-Service
│ ├── Users-Dev
│ └── Users-Prod
├── Orders-Service
│ ├── Orders-Dev
│ └── Orders-Prod
└── Payments-Service
├── Payments-Dev
└── Payments-Prod
Overriding Parent Variables
To override a parent variable:
- In the child environment, add a variable with the same name
- Set a different value
- Save
The child's value takes precedence over the parent's.
Example:
Parent (Common):
timeout: 5000
Child (Development):
timeout: 30000 ← overrides parent for local debugging
Best Practices
What to Put in Parents
- Configuration that's truly common across environments
- Default values that most environments share
- Organizational standards (timeouts, retry policies)
- Non-sensitive shared data
What to Put in Children
- Environment-specific URLs
- Environment-specific credentials
- Overrides for special cases
- Resource identifiers (tenant IDs, account numbers)
Naming Conventions
- Use clear parent names: "Common", "Shared", "Base"
- Name children descriptively: "Development", "Staging-EU", "Prod-US"
- Use prefixes or suffixes to show relationships: "API-Common" → "API-Dev"
Organization Tips
- Keep hierarchies shallow (2-3 levels max)
- Don't over-abstract (some duplication is okay)
- Document the hierarchy in your team wiki
- Review periodically and refactor as needed
Real-World Example
Scenario: Multi-Region SaaS Platform
Global (Parent):
timeout: 10000
retryCount: 3
apiVersion: v2
supportEmail: support@example.com
Production (Child of Global):
enableDebug: false
logLevel: warn
analyticsEnabled: true
Production-US (Child of Production):
baseUrl: https://api.us.example.com
region: us-east-1
dataCenter: virginia
Production-EU (Child of Production):
baseUrl: https://api.eu.example.com
region: eu-west-1
dataCenter: ireland
gdprCompliant: true
Production-APAC (Child of Production):
baseUrl: https://api.apac.example.com
region: ap-southeast-1
dataCenter: singapore
When using "Production-EU":
- Inherits
timeout,retryCount,apiVersion,supportEmailfrom Global - Inherits
enableDebug,logLevel,analyticsEnabledfrom Production - Uses its own
baseUrl,region,dataCenter,gdprCompliant
Troubleshooting
Variable Not Resolving
Check:
- Is the parent environment selected correctly?
- Is the variable spelled correctly in the parent?
- Has the variable been overridden in the child?
Unexpected Value
- Check if a child environment is overriding the parent
- Verify you're using the correct environment
- Check variable precedence (collection vs environment)
Circular Dependencies
You cannot create circular parent relationships:
A → parent of B
B → parent of C
C → parent of A ← Not allowed!
Next Steps
- Learn about using variables →
- Build conduits → that work across environments
- Explore multi-version management →