Production Configuration and Secrets

Configuration is everything that changes between deploys while the code stays the same. A local API URL, production database URL, OAuth callback, session secret, email provider key, and payment webhook secret are all configuration. Secrets are sensitive configuration values that must not be exposed publicly.

Many first launches fail because the code is fine but production configuration is wrong. Treat configuration as part of the launch, not as an afterthought.

Environment variables vs hardcoded config

Environment variables are a common way to provide deploy-specific values without changing source code. They work across languages and platforms, and they make it easier to run the same code in development, staging, and production with different settings.

Hardcoded config is risky when the value differs by environment, contains credentials, points to infrastructure, or may need emergency rotation. A value like the product name can live in code. A database password cannot.

Good environment variable candidates include:

• database connection strings
• API base URLs
• auth provider credentials
• session and token secrets
• object storage buckets
• email provider keys
• payment provider keys
• allowed origins
• canonical public hostname

Public config vs server-only secrets

Not every variable is secret. A public website URL or analytics public key may be safe to expose. A private API key, database password, signing secret, or admin token is not.

The important distinction is where the value is used. Browser code can be inspected by users. If a value is bundled into client JavaScript, treat it as public. Server code can hold secrets as long as the server does not leak them through responses, logs, build artifacts, or client bundles.

Use naming conventions carefully. Some frameworks expose variables with specific prefixes to the browser. That can be useful, but it also means a bad prefix can turn a secret into public data.

Separate dev, staging, and production

Development is where you build. Staging is where you test production-like behavior. Production is where real users and real data live. Small teams may skip staging at first, but they should still separate local and production values.

Do not let local development write to production databases by accident. Do not let production use test OAuth apps unless that is intentional. Do not let production send real emails from a development-only sender without checking deliverability and domain setup.

The minimum separation is:

• local values for development
• production values stored in the deploy platform or secret manager
• explicit production domain and callback URLs
• no committed secret files

Common broken settings

When a production app behaves differently from local development, check configuration before rewriting code.

Store secrets safely

Secrets should be stored in the deployment platform, a managed secret store, or another access-controlled system. They should not be committed to Git, copied into screenshots, printed in logs, pasted into issue trackers, or shared in chat without a secure process.

Use least privilege where possible. A key used only for sending email should not also have account-admin rights. A deploy token should not have human owner privileges. A database user for one application should not have access to unrelated databases.

Rotation basics

Secret rotation means replacing an old credential with a new one. You rotate when a key is exposed, an employee or contractor loses access, a provider requires it, or normal policy says it is time.

A safe rotation usually follows this shape:

1. Create the new secret.
2. Add it to production without removing the old one if the system supports overlap.
3. Deploy or reload the service.
4. Confirm production works with the new secret.
5. Revoke the old secret.
6. Record what changed.

Some secrets cannot overlap. In those cases, schedule a maintenance window or choose a low-traffic moment.

Pre-launch configuration checklist

• Production app URL is final.
• API URL points to production.
• Database URL points to production data.
• Auth callback URLs match the production domain.
• CORS allows only expected origins.
• Cookie settings match HTTPS production behavior.
• Secrets are stored outside the repository.
• Logs do not print secret values.
• A rotation path exists for critical credentials.

Flash Launch note

Flash Launch should make production configuration visible without making secrets visible. The user needs to know which values are set, which environment they belong to, and which integration depends on them. They should not need to copy raw credentials through unsafe places.

Related reading

• Full-Stack Web App Launch Checklist
• Identity, Security, and Trust Basics
• Debugging First Launch Failures
• Launch Glossary