Environments & Config Promotion

Environment parity catches Rust-specific failures before prod: Tokio worker counts, sqlx pool sizes, RUST_LOG levels, and feature flags. Config promotion moves tested values through dev, staging, and prod with secrets injected at runtime, not copied between laptops.

Recipe

Quick-reference recipe card - copy-paste ready.

dev:     local docker-compose, .env.example only (no real secrets)
staging: 50% prod RPS load test, pool max = prod, anonymized prod snapshot
prod:    vault-injected secrets, immutable image SHA, change window
 
Promotion: PR updates config/values.staging.yaml -> soak 48h -> PR values.prod.yaml

When to reach for this:

• New service bootstrap
• Repeated "works in staging, fails in prod" incidents
• Audit of secret handling
• Multi-region expansion

Working Example

use serde::Deserialize;
 
#[derive(Debug, Deserialize)]
pub struct AppConfig {
    pub database_url: String,
    pub database_max_connections: u32,
    pub tokio_worker_threads: usize,
    pub git_sha: String,
}
 
impl AppConfig {
    pub fn from_env() -> Result<Self, config::ConfigError> {
        config::Config::builder()
            .add_source(config::Environment::default().separator("__"))
            .build()?
            .try_deserialize()
    }
 
    pub fn validate(&self) -> Result<(), String> {
        if self.database_max_connections < 5 {
            return Err("DATABASE_MAX_CONNECTIONS must be >= 5".into());
        }
        if self.tokio_worker_threads == 0 {
            return Err("TOKIO_WORKER_THREADS must be set".into());
        }
        Ok(())
    }
}

# CI: validate staging fixture against schema
cargo test -p orders-api -- config_validate_staging_fixture
 
# Promote (GitOps example)
cp deploy/staging/values.yaml deploy/prod/values.yaml
# diff review: only intended deltas (replicas, URLs)

What this demonstrates:

• Typed config with validation catches typos before deploy
• Nested env keys via __ separator map to struct fields
• Promotion is reviewed PR, not manual kubectl edit

Deep Dive

Parity Dimensions

Secrets Flow

• Developers: fake credentials or local vault dev role.
• CI: short-lived tokens from OIDC.
• Staging/prod: Vault/K8s secrets operator; mount as env at pod start.
• Never commit .env with prod secrets; cargo deny + secret scanners in CI.

Config vs Code

• Feature flags and pool sizes: config layer.
• Business logic: code + normal release.
• Document which changes need only config promotion vs image rebuild.

Gotchas

• Staging at 1/100 traffic - Pool bugs hide. Fix: Load test at 50% peak quarterly.
• Prod-only env var typo - Classic incident. Fix: Schema validate all env fixtures in CI.
• Different Tokio workers staging vs prod - Race hides. Fix: Explicit TOKIO_WORKER_THREADS in both.
• Copy prod DB to laptop - Compliance violation. Fix: Anonymized snapshot pipeline.
• Manual prod config edit - Drift from GitOps. Fix: Revert + PR within 24h policy.

Alternatives

FAQs

Related

• Release Management - promotion timing
• Feature Flags & Progressive Delivery - flag per env
• Secrets Management - secret patterns
• Configuration and Feature Design - design
• Production Debugging - env repro

Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.