How to Manage Secrets and Environment Variables in Production

Overview

Environment variables are a useful way to configure an application, but they are not automatically secure. A secret can still leak through a frontend bundle, crash report, build log, container image, or overly broad cloud permission. Think about who can read each value and where it travels.

Classify configuration into public settings, non-sensitive operational settings, and secrets. Public frontend variables may be visible to every user. Server credentials should be available only to the process that needs them, preferably through a managed secret store or workload identity where supported.

A safer configuration process

1. Fail fast when required configuration is missing.
2. Keep local development secrets out of version control and provide a safe example file with placeholders.
3. Grant runtime identities access only to the secrets they need.
4. Avoid printing configuration objects or request headers to logs.
5. Rotate credentials after suspected exposure and verify all consumers use the new value.
6. Maintain separate settings for local, preview, staging, and production environments.

Example: a concrete starting point

import os

def required_setting(name: str) -> str:
    value = os.environ.get(name)
    if not value:
        raise RuntimeError(f"Required configuration is missing: {name}")
    return value

DATABASE_URL = required_setting("DATABASE_URL")

The example illustrates the boundary and validation pattern; adapt names, persistence, error handling, and provider-specific details to your application. It is not a complete production system by itself.

Failure cases to test

Deleting a leaked secret from the latest commit does not remove it from Git history, logs, or deployed artifacts. Revoke or rotate it first. Avoid sharing one high-privilege credential across unrelated services.

Before release, test the happy path, invalid input, missing permissions, dependency failure, and a retry or duplicate request where relevant. Record expected behavior so the implementation can be reviewed against the real business requirement.

When to bring in a developer

I can review application configuration, move exposed secrets to server-side storage, and set up safer credential access and rotation.

Conclusion

The reliable version of this feature is not just the happy-path demo. It makes ownership, validation, authorization, failure handling, and operational behavior explicit. Start with the smallest useful workflow, measure it against real data, and expand only when the next requirement is clear.

Additional Resources

• 12factor.net
• cloud.google.com