The decision that matters
Classify configuration as public or private before wiring it into code. Public values may include a site URL or non-sensitive feature name; provider keys and database credentials are private. Use deployment-specific secret storage, restrict access and avoid printing values in build logs. Review framework conventions carefully because certain prefixes or imports can expose environment values to client code.
A practical scenario
An AI interface can send a request to its own authenticated server endpoint. That endpoint loads the provider credential and performs the model call. Putting the key in a client component would allow visitors to extract it regardless of whether the UI displays it. A hidden input or obfuscated string does not create a security boundary.
Before you ship
- Inspect the client dependency path for server-only modules.
- Use separate credentials for development and production.
- Rotate a credential if it has been exposed rather than merely deleting the visible copy.
A useful next step
Maintain an environment-variable inventory containing names, purpose and owner, but not secret values. During handover, demonstrate where authorized operators can update configuration and how a redeployment or runtime refresh applies the change.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.