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