Configuration Management with .env Files

It is common during local testing to temporarily hardcode a database password or API key directly in a script. However, committing code that contains hardcoded credentials introduces a significant security risk. Exposed credentials can be misused, revoked, or permanently exposed if the repository becomes public.

Hardcoding configuration values reduces flexibility. If a database host changes or an API key is rotated, updating source code for each environment is inefficient and error-prone. A more reliable approach separates configuration from application logic using environment variables or external configuration files. This allows credentials and runtime settings to change without modifying the codebase.

The risks of hardcoded secrets

Professional Python applications enforce a clear separation between application logic and configuration. Credentials, hostnames, feature flags, and other environment-specific settings are kept outside the source code. This design allows the same codebase to run unchanged across local development machines, staging servers, and production environments.

If we define a value such as API_KEY = "secret-123" directly in a .py file, that secret becomes embedded in the repository’s version history. Anyone with access to the repository can retrieve it, and rotating the key requires modifying and recommitting the code. This approach is both insecure and operationally ...