Environment Configuration

Problem

Configuration values are hardcoded or scattered throughout the codebase: API URLs, feature flags, and API keys mixed into application code. Deploying to different environments requires code changes, and accidentally using production credentials in development or vice versa causes dangerous mistakes and security risks.

Solution

Store environment-specific settings like API endpoints and feature flags in configuration files separate from code. This lets you deploy the same build to multiple environments by swapping config rather than rebuilding.

Example

This example demonstrates using environment-specific configuration files to manage different API URLs for development and production.

// .env.production - configuration for production environment
VITE_API_URL=https://api.production.com

// .env.development - configuration for development environment
VITE_API_URL=http://localhost:3000

// Usage in code - automatically uses correct URL based on environment
const apiUrl = import.meta.env.VITE_API_URL;

Benefits

• Separates configuration from code enabling same build across environments.
• Prevents accidentally using production credentials in development.
• Makes environment-specific values easy to find and update.
• Enables feature flags and gradual rollouts per environment.
• Simplifies deployment by not requiring code changes for config.

Tradeoffs

• Environment files can be accidentally committed with secrets.
• Requires build tool support and configuration injection.
• Can be confusing which environment variables are available where.
• May expose configuration structure if not properly secured.
• Adds deployment complexity with environment-specific config management.