Why 'It Works on My Machine' Keeps Happening: Hidden Configuration Drift Between Dev and Production

You've been there. Code works perfectly on your machine. Tests pass. Code review's clean. You deploy. Then... nothing. Or worse—everything breaks. Classic "it works on my machine" moment.

Here's the thing: it's probably not your code. Well, not usually anyway. It's configuration drift—those subtle differences between your local environment and production that break things silently. These differences are everywhere: environment variables, dependency versions, system libraries, database schemas, network configurations. They accumulate over time, invisible until suddenly they're not.

Most developers blame themselves. "I should have tested better." But honestly? The real problem is environments that drift apart without anyone noticing. This article digs into why configuration drift happens, how to spot it before deployment, and—maybe more importantly—how to prevent it from breaking production.

Table of Contents

• What Is Configuration Drift?
• 5 Quick Wins: Stop Drift Today
• Why Configuration Drift Happens
• Common Causes of Configuration Drift
• How Configuration Drift Breaks Production
• Detecting Configuration Drift
• Preventing Configuration Drift
• Troubleshooting Configuration Drift Issues
• Real-World Examples
• The Trade-Offs
• Best Practices
• Common Misconceptions
• Frequently Asked Questions

What Is Configuration Drift?

Configuration drift is when environments that should be identical gradually become... not identical. Your local dev environment, staging, and production start the same. Over time, they diverge. Someone updates a dependency locally but forgets to update production. Someone adds an environment variable in staging but not production. Someone changes a system library version. Small changes accumulate. Eventually, environments are different enough that code that works locally fails in production.

The tricky part? Drift is invisible. Your app might work fine with slightly different versions or missing variables—until it doesn't. Then you're debugging production failures that make zero sense because "it works on my machine."

5 Quick Wins: Stop Drift Today

💡 Pro Tip: Start with these quick wins. They provide immediate value with minimal effort. Implementing even three of these will significantly reduce configuration drift incidents.

Before we dive deep, here are five things you can do right now to prevent configuration drift:

1. Validate environment variables in CI/CD - Use schema-based validation to catch missing or incorrect variables before deployment. Tools like env-sentinel validate variables against schemas automatically. Learn more about catching environment variable errors early.

2. Commit lock files - Always commit package-lock.json, yarn.lock, or pnpm-lock.yaml to version control. Use npm ci instead of npm install in production. This ensures production gets the exact same dependencies as your local environment.

3. Document all environment variables - Create a schema file (like .env-sentinel) that documents all required variables. Tools can automatically generate documentation from schemas, keeping docs synchronized with configuration.

4. Use infrastructure as code - Define infrastructure in code (Terraform, AWS CloudFormation). Version control infrastructure definitions. Deploy infrastructure changes through CI/CD, not manually.

5. Pin runtime versions - Pin runtime versions in Dockerfiles. Use versioned base images. Never use latest tags in production. Test with the same runtime version you'll use in production. Follow Docker best practices for container configuration.

Implementing even three of these will significantly reduce configuration drift. Ready to dive deeper? Let's explore why drift happens and how to prevent it systematically.

Why Configuration Drift Happens

Drift happens because environments are managed separately. Each environment—local, staging, production—has its own configuration. When you update one, you have to remember to update the others. That's where things break down.

Manual Configuration Management

Most teams manage configuration manually. Someone updates a .env file locally. Someone else updates staging. Someone else updates production. Three people, three places, three chances to forget something. It's not malicious—it's human. But it causes drift.

Manual processes break down as teams grow. With two developers? Maybe you can coordinate. With ten? Forget it. Someone's always forgetting to update production. Someone's always copying the wrong config. Someone's always making a typo.

Environment-Specific Differences

Environments need different values. Your local database is localhost. Production is prod-db.example.com. That's fine—they should be different. But when environments need different variables—not just different values—drift creeps in.

Maybe staging needs DEBUG=true but production doesn't. Maybe production needs SENTRY_DSN but staging doesn't. Over time, these differences accumulate. Eventually, someone forgets that production needs a variable staging doesn't have. Deployment fails. Classic drift.

Dependency Version Mismatches

Dependencies drift too. You update package.json locally, test everything, deploy. But production's still running old dependencies. Or vice versa—production gets updated but your local environment doesn't. Either way, drift.

This gets worse with system dependencies. Your local machine has Python 3.11. Production has Python 3.9. Your code works fine locally, fails in production. Why? Because you used a feature that doesn't exist in 3.9. Drift.

Hidden System Configuration

System-level configuration drifts too. File permissions, network settings, firewall rules, DNS configurations—all of these can differ between environments. Your local machine might allow connections that production blocks. Your local filesystem might have different permissions than production. These differences cause failures that are hard to debug because they're invisible.

Common Causes of Configuration Drift

Let's look at the most common causes of configuration drift—the things that break production deployments.

Environment Variables

Environment variables are the biggest culprit. They're easy to forget, hard to track, and critical for application behavior. Missing variables cause failures. Wrong variables cause failures. Extra variables... sometimes cause failures too.

The Problem:

Copy
# Local .env
DATABASE_URL=postgresql://localhost:5432/myapp
REDIS_URL=redis://localhost:6379
DEBUG=true
SENTRY_DSN=

# Production .env (missing REDIS_URL)
DATABASE_URL=postgresql://prod-db:5432/myapp
DEBUG=false
SENTRY_DSN=https://...

Your app works locally because REDIS_URL exists. Production fails because it's missing. Classic drift.

Why It Happens:

• Someone adds a variable locally, forgets to add it to production
• Someone removes a variable from production, forgets to remove it from code
• Someone updates a variable value, forgets to update documentation
• Someone copies config from staging to production, misses environment-specific variables

The Fix:

Use schema-based validation. Tools like env-sentinel validate environment variables against schemas, catching missing or incorrect variables before deployment. Catch environment variable errors early in your CI/CD pipeline, not when users hit production. This is one of the most common mistakes teams make with environment files—missing variables that work locally but break production.

Dependency Versions

Dependency versions drift when package managers don't lock versions properly, or when lock files aren't committed, or when someone updates dependencies locally but forgets to update production.

The Problem:

Copy
// Local package.json
{
  "dependencies": {
    "express": "^4.18.2",
    "redis": "^4.6.0"
  }
}

// Production (deployed last month)
{
  "dependencies": {
    "express": "^4.17.0",
    "redis": "^4.5.0"
  }
}

Your code uses a feature from redis@4.6.0. Production has redis@4.5.0. It works locally, fails in production. Drift.

Why It Happens:

• Lock files aren't committed to version control
• Someone updates dependencies locally, doesn't commit lock file
• Production deployments use npm install without lock files
• Different environments use different package managers

The Fix:

Commit lock files (package-lock.json, yarn.lock, pnpm-lock.yaml). Always deploy using lock files. Use npm ci instead of npm install in production. This ensures production gets the exact same dependencies as your local environment.

Database Schema Differences

Database schemas drift when migrations run in some environments but not others, or when someone manually changes a database without running migrations, or when migrations are environment-specific.

The Problem:

Your local database has a users table with a last_login column. Production doesn't. Your code queries last_login. It works locally, fails in production. Drift.

Why It Happens:

• Migrations run locally but not in production
• Someone manually changes production database
• Migrations are environment-specific
• Rollback scripts don't match forward migrations

The Fix:

Use migration tools that track applied migrations. Never manually change production databases. Run migrations in CI/CD before deployment. Test migrations in staging first.

System Libraries and Runtime Versions

System libraries and runtime versions drift when different environments use different base images, or when someone updates system packages locally but production doesn't, or when Docker images aren't versioned properly.

The Problem:

Your local machine has Node.js 20. Production has Node.js 18. Your code uses a feature from Node.js 20. It works locally, fails in production. Drift.

Why It Happens:

• Different environments use different base images
• Someone updates runtime locally, forgets to update production
• Docker images aren't versioned or pinned
• System packages are updated manually

The Fix:

Pin runtime versions in Dockerfiles. Use versioned base images. Never use latest tags in production. Test with the same runtime version you'll use in production.

Network and Infrastructure Configuration

Network and infrastructure configuration drifts when environments have different firewall rules, DNS settings, load balancer configurations, or service mesh settings.

The Problem:

Your local environment allows connections to external APIs. Production blocks them. Your code makes external API calls. It works locally, fails in production. Drift.

Why It Happens:

• Different environments have different firewall rules
• DNS configurations differ between environments
• Load balancer settings aren't synchronized
• Service mesh configurations drift

The Fix:

Infrastructure as code. Use Terraform, AWS CloudFormation, or similar tools to define infrastructure. Version control infrastructure definitions. Deploy infrastructure changes through CI/CD, not manually.

How Configuration Drift Breaks Production

Configuration drift breaks production in predictable ways. Understanding these patterns helps you debug faster.

Silent Failures

Some drift causes silent failures. Your app starts, but features don't work. Maybe an environment variable is missing, so a feature defaults to disabled. Maybe a dependency version is wrong, so a feature fails silently. These are the worst kind of failures because they're invisible until users complain.

Partial Failures

Some drift causes partial failures. Your app works, but some features don't. Maybe production is missing a variable that staging has, so a feature works in staging but not production. Maybe a dependency version is slightly different, so some API calls work but others don't.

Intermittent Failures

Some drift causes intermittent failures. Maybe production has a variable that's sometimes set, sometimes not. Maybe a dependency version works most of the time but fails under certain conditions. These failures are hard to debug because they're inconsistent.

Performance Degradation

Some drift causes performance degradation. Maybe production has different timeout settings than staging. Maybe a dependency version is slower. Maybe network configuration causes latency. These failures are subtle—your app works, just slower than expected.

Detecting Configuration Drift

You can't fix drift you can't see. Here's how to detect it before it breaks production.

Automated Validation

Automated validation catches drift early. Validate environment variables against schemas. Validate dependency versions against lock files. Validate database schemas against migrations. Run validation in CI/CD, not just locally.

Example:

Copy
# Validate environment variables
npx env-sentinel validate --file .env.production --schema .env-sentinel

# Validate dependencies
npm ci --dry-run

# Validate database schema
npm run migrate:status

This is exactly why catching environment variable errors early is crucial. Automated validation catches drift before it reaches production, saving hours of debugging.

Configuration Comparison Tools

Configuration comparison tools show differences between environments. Compare environment variables. Compare dependency versions. Compare infrastructure configurations. These tools highlight drift before it causes failures.

Monitoring and Alerting

Monitoring and alerting detect drift in production. Monitor application behavior. Alert on unexpected failures. Alert on performance degradation. These alerts catch drift that validation misses.

Regular Audits

Regular audits catch drift that automated tools miss. Periodically compare environments manually. Review configuration changes. Check for undocumented changes. These audits catch drift that accumulates slowly.

Audit Checklist:

• Compare environment variables between environments
• Compare dependency versions
• Compare infrastructure configurations
• Review recent configuration changes
• Check for undocumented manual changes
• Verify all environments use the same base images
• Confirm all environments use the same runtime versions

Schedule audits monthly for small teams, weekly for large teams. Better yet? Automate drift detection so it happens on every deployment.

Configuration Comparison Scripts

You can write simple scripts to compare configurations between environments:

Copy
#!/bin/bash
# compare-envs.sh

echo "Comparing local vs production environment variables..."

# Extract variable names from schemas
local_vars=$(grep -E "^[A-Z_]+=" .env.local | cut -d'=' -f1 | sort)
prod_vars=$(grep -E "^[A-Z_]+=" .env.production | cut -d'=' -f1 | sort)

# Find differences
echo "Variables in local but not production:"
comm -23 <(echo "$local_vars") <(echo "$prod_vars")

echo "Variables in production but not local:"
comm -13 <(echo "$local_vars") <(echo "$prod_vars")

These scripts help identify drift quickly. But automated validation is better—it catches drift before deployment, not after.

Preventing Configuration Drift

Preventing drift is better than detecting it. Here's how to keep environments synchronized.

Infrastructure as Code

Infrastructure as code keeps infrastructure synchronized. Define infrastructure in code. Version control infrastructure definitions. Deploy infrastructure changes through CI/CD. This prevents infrastructure drift.

Popular Tools:

• Terraform - Infrastructure as code for cloud providers
• AWS CloudFormation - AWS-specific infrastructure definition
• Pulumi - Infrastructure as code using familiar languages
• Ansible - Configuration management and infrastructure automation

Example:

Copy
# terraform/main.tf
resource "aws_security_group" "app" {
  name        = "app-sg"
  description = "Security group for application"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

This ensures infrastructure is defined in code, version controlled, and deployed consistently across environments. No more manual infrastructure changes that cause drift.

Configuration Management Tools

Configuration management tools keep configuration synchronized. Use tools like Ansible, Puppet, or Chef to manage configuration. Or use simpler tools like env-sentinel to manage environment variables. These tools prevent configuration drift.

For Environment Variables:

• env-sentinel - Schema-based validation and documentation for environment variables
• dotenv-validator - Runtime validation for Node.js apps
• envalid - TypeScript-friendly environment variable validation

For Infrastructure Configuration:

• Ansible - Agentless configuration management
• Puppet - Declarative configuration management
• Chef - Infrastructure automation platform

For Application Configuration:

• Consul - Service discovery and configuration
• etcd - Distributed key-value store for configuration
• Vault - Secrets management and configuration

The key? Choose tools that fit your needs. For most teams, schema-based validation for environment variables (like env-sentinel) provides the biggest impact with minimal complexity. This aligns with the 12-Factor App methodology, which recommends storing configuration in environment variables and keeping environments identical except for configuration values.

Environment Parity

Environment parity keeps environments identical. Use the same base images. Use the same dependency versions. Use the same runtime versions. The only differences should be environment-specific values (like database URLs), not environment-specific variables or versions.

Documentation and Schemas

Documentation and schemas keep configuration visible. Document all environment variables. Document all dependencies. Document all infrastructure. Use schemas to validate configuration. This makes drift visible.

Example:

Copy
# .env-sentinel schema documents all required variables
# @section Application
# @description Core application settings

# @var Database connection URL
DATABASE_URL=required

# @var Redis connection URL
REDIS_URL=required

# @var Application environment
APP_ENV=required|enum:development,staging,production

Tools like env-sentinel can automatically generate documentation from schemas, keeping documentation synchronized with configuration. This prevents the common documentation mistakes that cause drift—outdated docs that don't match actual configuration.

CI/CD Integration

CI/CD integration catches drift automatically. Validate configuration in CI/CD. Deploy configuration changes through CI/CD. Never manually change production configuration. This prevents manual drift.

Example:

Copy
# GitHub Actions
- name: Validate environment variables
  run: |
    npx env-sentinel validate --file .env.production --schema .env-sentinel

- name: Validate dependencies
  run: |
    npm ci --dry-run

- name: Deploy
  run: |
    npm run deploy

Learn more about GitHub Actions and GitLab CI/CD for CI/CD best practices.

Troubleshooting Configuration Drift Issues

Even with best practices, you'll encounter configuration drift. Here's how to troubleshoot common drift issues systematically.

Issue 1: App Works Locally But Fails in Production

Symptoms: Code works perfectly locally, fails immediately in production.

Debugging Steps:

1. Compare environment variables:

   Copy
   # Check what's different
   diff <(sort .env.local) <(sort .env.production)
   

2. Validate against schema:

   Copy
   npx env-sentinel validate --file .env.production --schema .env-sentinel
   

3. Check dependency versions:

   Copy
   # Compare lock files
   diff package-lock.json production-package-lock.json
   

4. Verify runtime versions:

   Copy
   # Local
   node --version
   
   # Production (check logs or deployment config)
   

Common Causes:

• Missing environment variables
• Different dependency versions
• Different runtime versions
• Missing database migrations

Solution: Use schema-based validation and commit lock files. This prevents these issues before deployment.

Issue 2: Intermittent Failures

Symptoms: App works sometimes, fails other times. Inconsistent behavior.

Debugging Steps:

1. Check for conditional configuration:

   • Variables that are sometimes set, sometimes not
   • Environment-specific conditionals in code
   • Default values that mask missing variables

2. Review recent changes:

   • What changed recently?
   • Was configuration updated?
   • Were dependencies updated?

3. Check monitoring:

   • When do failures occur?
   • Correlate with deployments
   • Check for patterns

Common Causes:

• Variables set conditionally
• Race conditions in configuration loading
• Cached configuration values
• Environment-specific defaults

Solution: Always validate required variables. Never rely on defaults for critical configuration. Use schema validation to catch missing variables.

Issue 3: Performance Degradation

Symptoms: App works, but slower than expected. Performance issues.

Debugging Steps:

1. Compare timeout settings:

   • Database connection timeouts
   • API request timeouts
   • Cache TTL settings

2. Check dependency versions:

   • Older versions might be slower
   • Check changelogs for performance changes

3. Review network configuration:

   • DNS resolution times
   • Network latency
   • Firewall rules affecting performance

Common Causes:

• Different timeout settings
• Older dependency versions
• Network configuration differences
• Resource limits

Solution: Document all performance-related configuration. Use the same settings across environments (except for resource limits, which should be higher in production).

Issue 4: Features Work in Staging But Not Production

Symptoms: Feature works perfectly in staging, fails in production.

Debugging Steps:

1. Compare staging and production configs:

   Copy
   diff .env.staging .env.production
   

2. Check for staging-specific variables:

   • Variables that exist in staging but not production
   • Variables with different values

3. Review feature flags:

   • Feature flags enabled in staging but not production
   • Different feature flag configurations

Common Causes:

• Missing environment variables in production
• Different feature flag settings
• Staging-specific configuration not replicated

Solution: Use environment parity. Keep staging and production as similar as possible. Only differences should be environment-specific values (like database URLs), not environment-specific variables.

Issue 5: Database Errors After Deployment

Symptoms: Database queries fail after deployment. Schema errors.

Debugging Steps:

1. Check migration status:

   Copy
   npm run migrate:status
   

2. Compare database schemas:

   • Local vs production schema
   • Staging vs production schema

3. Review recent migrations:

   • Were migrations run in production?
   • Were migrations tested in staging?

Common Causes:

• Migrations not run in production
• Manual database changes
• Environment-specific migrations

Solution: Always run migrations in CI/CD before deployment. Never manually change production databases. Test migrations in staging first.

Real-World Examples

Let's look at real-world examples of configuration drift breaking production.

Example 1: Missing Environment Variable

A team deployed a new feature that required a STRIPE_WEBHOOK_SECRET environment variable. The variable was added to staging and local environments, but someone forgot to add it to production. The feature worked in staging, failed silently in production. Users couldn't complete payments. The team didn't notice until revenue dropped.

This is a classic example of the common mistakes teams make with .env files—missing variables that work in one environment but break in another.

The Fix:

The team added schema-based validation to their CI/CD pipeline. Now, missing environment variables cause deployments to fail before they reach production. They also implemented early validation strategies to catch these issues during development, not deployment.

Example 2: Dependency Version Mismatch

A team updated a dependency locally, tested everything, deployed. But production was still using the old dependency version because the lock file wasn't committed. The new code used a feature from the new dependency version. It worked locally, failed in production.

The Fix:

The team started committing lock files and using npm ci in production. Now, production always gets the exact same dependencies as local environments.

Example 3: Database Schema Drift

A team ran a migration locally and in staging, but forgot to run it in production. The new code queried a column that didn't exist in production. It worked locally and in staging, failed in production.

The Fix:

The team added migration checks to their CI/CD pipeline. Now, migrations must run in production before code deployment.

Example 4: Runtime Version Mismatch

A team developed a feature using Node.js 20 features locally. Production was still running Node.js 18. The feature used syntax that doesn't exist in Node.js 18. It worked locally, failed in production with syntax errors.

The Fix:

The team pinned Node.js version in Dockerfile (FROM node:20-alpine). They also added runtime version validation to CI/CD to catch mismatches before deployment.

Example 5: Infrastructure Configuration Drift

A team's local environment allowed outbound connections to external APIs. Production had firewall rules blocking these connections. The feature worked locally, failed in production with connection timeouts.

The Fix:

The team documented all network requirements in infrastructure as code. They also added network connectivity tests to CI/CD to catch firewall issues before deployment.

The Trade-Offs

Preventing configuration drift has trade-offs. Understanding these trade-offs helps you make informed decisions.

Speed vs. Safety

Automated validation slows down deployments. But it prevents production failures. The trade-off? Slower deployments vs. fewer failures. Most teams choose slower deployments.

Flexibility vs. Consistency

Environment parity reduces flexibility. You can't easily test with different dependency versions. But it prevents drift. The trade-off? Less flexibility vs. more consistency. Most teams choose consistency.

Complexity vs. Simplicity

Configuration management tools add complexity. But they prevent drift. The trade-off? More complexity vs. less drift. Most teams choose less drift.

Best Practices

Here are best practices for preventing configuration drift.

1. Use Schema-Based Validation

Use schema-based validation for environment variables. Tools like env-sentinel validate variables against schemas, catching drift before deployment. This is a core environment variable management best practice that prevents the most common configuration drift issues. Learn more about catching environment variable errors early in your workflow.

2. Commit Lock Files

Commit lock files to version control. Always deploy using lock files. Use npm ci instead of npm install in production. This ensures dependency versions stay synchronized.

3. Use Infrastructure as Code

Use infrastructure as code for all infrastructure. Define infrastructure in code. Version control infrastructure definitions. Deploy infrastructure changes through CI/CD. Tools like Terraform and AWS CloudFormation make this straightforward.

4. Document Everything

Document all configuration. Use schemas to validate configuration. Use tools to generate documentation automatically. This makes drift visible.

What to Document:

• All environment variables (required vs optional, types, defaults)
• All dependencies (versions, why they're needed)
• All infrastructure (servers, networks, load balancers)
• All runtime requirements (Node.js version, Python version, etc.)
• All database schemas (migrations, required columns)

How to Document:

• Use schema files (.env-sentinel for environment variables)
• Use README files with clear sections
• Use automatic documentation generation tools
• Keep documentation in version control

Why It Matters: Documentation makes drift visible. When configuration is documented, you can compare environments. When schemas validate configuration, drift is caught automatically. Documentation that stays synchronized with configuration prevents drift.

5. Validate in CI/CD

Validate configuration in CI/CD. Never manually change production configuration. Deploy configuration changes through CI/CD. This prevents manual drift.

6. Regular Audits

Regularly audit environments. Compare environments manually. Review configuration changes. Check for undocumented changes. This catches drift that automated tools miss.

7. Environment Parity

Keep environments as similar as possible. Use the same base images. Use the same dependency versions. Use the same runtime versions. The only differences should be environment-specific values.

Common Misconceptions

Let's clear up common misconceptions about configuration drift.

"It's Not That Big a Deal"

Configuration drift is a big deal. It causes production failures. It causes debugging nightmares. It causes user frustration. Preventing drift saves time and prevents failures.

"We Can Fix It Later"

You can't fix drift later. By the time you notice drift, it's already broken production. Preventing drift is easier than fixing it.

"Automated Tools Are Too Complex"

Automated tools aren't that complex. Tools like env-sentinel are simple. They validate configuration automatically. They catch drift before it breaks production.

"Manual Processes Work Fine"

Manual processes don't work fine. They cause drift. They cause failures. They cause frustration. Automated processes prevent drift.

Conclusion

Configuration drift is the hidden cause of "it works on my machine" failures. Environments drift apart over time, causing production failures that are hard to debug. But drift is preventable. Use schema-based validation. Commit lock files. Use infrastructure as code. Document everything. Validate in CI/CD. Keep environments similar.

The key? Make drift visible. Use tools to detect drift. Use schemas to validate configuration. Use documentation to track changes. When drift is visible, you can prevent it.

Most teams blame themselves when production fails. But the real problem? Environments that drift apart without anyone noticing. Fix the drift, fix the failures.

Start by validating environment variables. Tools like env-sentinel catch missing or incorrect variables before deployment. Learn more about environment variable management best practices to prevent drift. Then commit lock files. Then use infrastructure as code. Then document everything. Small steps, big impact.

Your code works on your machine. Make sure it works in production too.

Related Guides:

• Catch Environment Variable Errors Early - Learn when and where to validate
• Common .env File Mistakes - Avoid these configuration pitfalls
• Environment Variable Management Best Practices - Comprehensive guide to managing env vars
• Automatic Documentation Generation - Keep docs synchronized with schemas

Frequently Asked Questions

What is configuration drift?

Configuration drift is when environments that should be identical gradually become different. Your local dev environment, staging, and production start the same, but over time they diverge due to manual changes, forgotten updates, or environment-specific differences.

Why does "it works on my machine" happen?

"It works on my machine" happens because of configuration drift. Your local environment has different configuration than production—different environment variables, dependency versions, system libraries, or infrastructure settings. Code that works with your local configuration fails with production's configuration.

How do I detect configuration drift?

Detect configuration drift by validating configuration automatically. Use schema-based validation for environment variables. Compare dependency versions. Compare infrastructure configurations. Run validation in CI/CD, not just locally. Regular audits catch drift that automated tools miss.

How do I prevent configuration drift?

Prevent configuration drift by using infrastructure as code, committing lock files, using schema-based validation, documenting everything, validating in CI/CD, and keeping environments as similar as possible. The only differences should be environment-specific values, not environment-specific variables or versions.

What tools help prevent configuration drift?

Tools like env-sentinel validate environment variables against schemas, catching drift before deployment. Infrastructure as code tools (Terraform, AWS CloudFormation) prevent infrastructure drift. Package managers with lock files prevent dependency drift. Configuration management tools (Ansible, Puppet, Chef) prevent infrastructure configuration drift. CI/CD platforms like GitHub Actions and GitLab CI/CD automate validation. The key is automating validation, not doing it manually.

What's the difference between configuration drift and infrastructure drift?

Configuration drift refers to differences in application configuration (environment variables, dependencies, runtime versions). Infrastructure drift refers to differences in infrastructure configuration (servers, networks, load balancers). Both cause "it works on my machine" failures, but they're managed differently. Configuration drift is managed with schema validation and environment parity. Infrastructure drift is managed with infrastructure as code tools like Terraform or AWS CloudFormation.

How often should I audit for configuration drift?

Audit for configuration drift regularly, but frequency depends on your team size and deployment frequency. Small teams with infrequent deployments might audit monthly. Large teams with frequent deployments should audit weekly or integrate automated drift detection into CI/CD. The best approach? Automate drift detection so it happens on every deployment, not just during audits.

Can configuration drift cause security issues?

Yes. Configuration drift can cause security issues. Missing security variables (like SENTRY_DSN or ENCRYPTION_KEY) can disable security features. Wrong security configurations can expose sensitive data. Outdated dependencies can include security vulnerabilities. Always validate security-related configuration before deployment.

How do I fix configuration drift in production?

Fixing configuration drift in production requires careful planning. First, identify what's different. Compare production configuration with your schema or staging environment. Then, update production configuration through your normal deployment process—never manually. Test changes in staging first. Use infrastructure as code for infrastructure changes. Use schema validation for application configuration. The key? Fix drift systematically, not reactively.