Environments

Redenv supports multiple environments within a single project, allowing you to maintain separate configurations for development, staging, production, and more.

What is an Environment?#

An environment is a isolated namespace for secrets within a project. Think of it as a separate .env file, but centralized and encrypted.

Examples:

• development: Local development secrets
• staging: Pre-production testing
• production: Live application secrets
• test: CI/CD test environment

Each environment has its own complete set of secrets with independent version histories.

Creating Environments#

When you register a project, a development environment is created by default:

redenv register my-app
# Creates project "my-app" with "development" environment

To add more environments, simply switch to them (they're created automatically):

# Switch to production (creates it if it doesn't exist)
redenv switch env production

Switching Environments#

The switch env command changes your active environment:

# Switch to development
redenv switch env development

# Switch to production
redenv switch env production

# Switch to custom environment
redenv switch env qa-testing

Your current environment is stored in the redenv.config.ts file:

import { defineConfig } from "@redenv/core";

export default defineConfig({
  name: "my-app",
  environment: "production", // Current active environment
});

Managing Secrets Per Environment#

Once you've switched environments, all secret commands operate on that environment:

# Switch to development
redenv switch env development
redenv add API_KEY "sk_test_123"
redenv add DATABASE_URL "postgresql://localhost/dev_db"

# Switch to production
redenv switch env production
redenv add API_KEY "sk_live_xyz"
redenv add DATABASE_URL "postgresql://prod-host/prod_db"

Now you have different values for the same key across environments:

• development.API_KEY = "sk_test_123"
• production.API_KEY = "sk_live_xyz"

Using Environments in Applications#

Your application specifies which environment to load via the SDK configuration:

import { Redenv } from "@redenv/client";

const redenv = new Redenv({
  project: "my-app",
  environment: process.env.NODE_ENV || "development", // Dynamic!
  tokenId: process.env.REDENV_TOKEN_ID!,
  token: process.env.REDENV_TOKEN_KEY!,
  upstash: { ... }
});

import os
from redenv import Redenv

client = Redenv({
    "project": "my-app",
    "environment": os.getenv("ENV", "development"),  # Dynamic!
    "token_id": os.getenv("REDENV_TOKEN_ID"),
    "token": os.getenv("REDENV_TOKEN_KEY"),
    "upstash": { ... }
})

Environment Isolation#

Environments are completely isolated:

• Secrets don't overlap: Changing API_KEY in development won't affect production
• Independent versioning: Each environment has its own version history
• Separate tokens: You can create environment-specific Service Tokens

Cloning Environments#

To copy all secrets from one environment to another:

# Clone production -> staging
redenv clone --from production --to staging

This is useful for:

• Setting up new environments
• Refreshing staging with production data
• Creating test environments

Comparing Environments#

See what's different between environments:

redenv diff

Output:

🔍 Comparing "selected 1" ↔ "selected 2" for project "redenv"

🔹 Only in development
  • TEST_MODE="test"

🟡 Changed
  • API_KEY
      selected 1: "sk_test_..."
      selected 2: "sk_live_..."
  • DATABASE_URL
      selected 1: "postgresql://localhost/..."
      selected 2: "postgresql://prod-host/..."

🟢 Same
  • DEBUG

✨ Diff complete.

Syncing Secrets Across Environments#

Add the same secret to multiple environments at once:

redenv sync

Environment Naming Conventions#

Recommended:

• Use lowercase: development, not Development
• Use hyphens for spaces: qa-testing, not qa_testing
• Be descriptive: production-eu, not prod-eu (clarity over brevity)

Avoid:

• Special characters (except hyphens and underscores)
• Spaces
• Very long names

Deleting Environments#

To permanently remove an environment and all its secrets, use the drop command:

# Delete a specific environment
redenv drop env staging

# Delete multiple environments
redenv drop env staging qa-testing

Best Practices#

1. Separate tokens per environment: Don't use the same service token for dev and prod
2. Use meaningful names: Be explicit (production, not prod)
3. Backup before major changes: redenv backup before cloning or bulk operations