Skip to main content

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​

  1. Click "Environments"
  2. Click "New Environment"
  3. Name it descriptively (e.g., "Common", "Shared", "Base")
  4. Add shared variables
  5. Save

Create Children​

  1. Create a new environment
  2. In the settings, select "Parent Environment"
  3. Choose the parent from the dropdown
  4. Add only environment-specific variables
  5. 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:

  1. In the child environment, add a variable with the same name
  2. Set a different value
  3. 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, supportEmail from Global
  • Inherits enableDebug, logLevel, analyticsEnabled from 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​