On this page
The core idea
Configuration changes how the application behaves; secrets grant access to something. Keep a clear inventory of both and identify where each value is used. Framework naming conventions can expose selected environment variables to client bundles, so do not assume an environment variable is automatically private. Use the platform’s supported secret storage for credentials.
A practical approach
Step 1
List each setting with its purpose, environment, owner and exposure level. Mark values that may safely appear in browser code.
Step 2
Validate required server settings at startup or at the relevant boundary. Fail clearly when a credential is missing instead of falling back to an unsafe default.
Step 3
Document rotation and revocation for secrets. Keep examples in source control free of real credentials.
Worked example
A site’s public origin can be included in generated metadata, while a service token used to submit a backend request must stay server-side. Putting both behind the same public-variable convention can accidentally ship the token to every visitor.
A mistake to avoid
A secret removed from the latest source file may still exist in history or an old build artifact. Exposure response requires rotation and an assessment of affected artifacts, not only deleting the visible line.
Try it yourself
Review the configuration keys in one project without printing their secret values. Classify each key and confirm where it becomes available at build time and runtime.
Your implementation checklist
- Public and private settings are distinguished.
- Credentials use supported secret storage.
- Missing values fail clearly.
- Rotation and ownership are documented.
Share or cite this guide
Innovate with Ajay Editorial (2026-10-04). Separate Configuration from Secrets in Your Deployment. https://innovatewithajay.com/blogs/separate-configuration-from-secrets