Choosing between environment variables, mounted configuration files, and managed secret stores affects how a cloud application is deployed, operated, and audited. This guide provides a practical decision framework, a naming template, deployment workflow, and recurring review checklist for managing application configuration without turning credentials into source code or deployment surprises.
Overview
Cloud applications usually need two broad types of configuration. Non-sensitive configuration includes values such as log levels, feature flags, service URLs, region identifiers, and connection timeouts. Sensitive configuration includes database passwords, signing keys, private certificates, API tokens, and credentials used to access other systems.
Environment variables are often a useful delivery mechanism for both categories, especially when an application is designed to read configuration at startup. They are simple to inject through a local process, container, virtual machine, or deployment platform. However, they are not automatically a complete secret-management strategy. Their safety depends on how values are created, stored, passed to workloads, exposed in diagnostics, and removed during rotation.
A mounted file can be preferable when a library expects a file path, when a value is multi-line, or when configuration needs file permissions and a clear lifecycle. A managed secret store is generally the stronger choice when credentials require controlled access, auditability, centralized rotation, versioning, or separate permissions for different workloads. The right design can use all three: a managed secret store as the source of truth, a deployment mechanism that delivers selected values, and environment variables or files as the application’s runtime interface.
Do not treat configuration design as an isolated security task. It is part of cloud-native application architecture and production readiness. For a broader operational review, see the Production Readiness Checklist for Cloud-Native Web Applications.
What to track
Classify every value before choosing a delivery method
Start with an inventory rather than a platform feature. For each configuration item, record its purpose, sensitivity, owner, environments, consuming service, and rotation requirement. A practical classification looks like this:
- Public or non-sensitive: frontend feature settings, supported locales, public API base URLs, and observability labels. These can usually be stored in version-controlled configuration or supplied as ordinary environment variables.
- Operationally sensitive: internal endpoints, tenant identifiers, or settings that reveal infrastructure details. Restrict access even if the value is not a credential, and avoid exposing it to client-side code without a clear reason.
- Secret: passwords, private keys, access tokens, webhook signing secrets, encryption keys, and credentials for third-party services. Keep these in an approved secret-management system or an equivalent controlled mechanism.
- Highly sensitive or cryptographic: key-encryption material, certificate private keys, and credentials with broad administrative scope. These deserve narrower permissions, stronger review, and a documented rotation or replacement procedure.
Use a consistent configuration naming template
Names should describe ownership and purpose without putting secret values into logs or documentation. One workable template is:
<APP>_<ENVIRONMENT>_<SYSTEM>_<PURPOSE>
For example, ORDERS_PROD_DATABASE_URL identifies an application, environment, system, and purpose. In a real implementation, teams may omit the environment when the deployment boundary already supplies it, or use a service-specific prefix such as PAYMENTS_. The important requirements are consistency, unambiguous ownership, and a naming convention that does not encourage developers to copy values into source files.
Track metadata separately from the secret itself:
- Configuration name and description
- Owning team and operational contact
- Consumer service and environment
- Delivery method: environment variable, mounted file, or runtime retrieval
- Required scope and read permissions
- Last review, last rotation, and next planned review
- Whether rotation requires a restart, reload, or application-level refresh
Decision matrix
| Situation | Suitable default | Reason to reconsider |
|---|---|---|
| Non-sensitive startup setting | Environment variable or version-controlled config | It is exposed to a browser bundle, varies frequently, or needs centralized approval |
| Credential or access token | Managed secret store delivered at runtime | The application cannot use the platform integration or requires a legacy file format |
| Multi-line certificate or key | Mounted secret file with restrictive access | The library supports safer runtime retrieval or the file can leak through backups and diagnostics |
| Frequently changing feature setting | Configuration service or controlled deployment configuration | Each change requires a restart or creates an inconsistent state across instances |
| Local developer credential | Local secret store, ignored file, or approved developer tooling | The value is shared broadly, committed accidentally, or reused across environments |
These are starting points, not universal rules. Review the application’s runtime behavior, platform integration, and threat model before standardizing a pattern.
Cadence and checkpoints
Configuration work becomes more reliable when it is built into normal cloud app development and DevOps workflows. Use the following checkpoints.
During local development
Provide a safe configuration example such as .env.example containing names but not real values. Add the actual local file to the appropriate ignore list, and document which values can be generated locally and which require an approved development account. A startup validation step should report missing variable names without printing their contents.
Use separate credentials for local, test, staging, and production environments. Avoid copying production values into a laptop or using a shared credential simply because it makes an integration test easier.
During CI/CD
Keep the pipeline responsible for obtaining or referencing secrets, not for displaying them. Scope access by job, environment, repository, and deployment target where the platform supports those boundaries. Prevent secrets from being passed as command-line arguments when a process, shell, or build log could expose them. Review build artifacts, test reports, cache contents, and diagnostic output as possible leakage paths.
Separate configuration validation from secret retrieval when possible. A pull request can check that required names are present, naming rules are followed, and no obvious credentials are committed. A deployment job can then resolve the actual values only in the target environment.
During deployment and runtime
Record which configuration version was deployed without recording secret values. Confirm that each workload has only the permissions it needs. Decide whether changes are consumed at process startup, on a scheduled refresh, or through an explicit reload. If a value is injected into an environment variable or file, understand whether a running instance sees updates automatically; many applications require a restart or replacement deployment.
Pair the configuration review with authentication and API design. The guide to API authentication methods can help teams distinguish between API keys, OAuth credentials, and mutual TLS material before selecting storage and rotation procedures.
Monthly or quarterly review
On a monthly or quarterly cadence, compare the inventory with the deployed application. Check for unused values, duplicated credentials, unclear owners, excessive permissions, failed rotation attempts, and configuration that exists in one environment but not another. The appropriate interval depends on sensitivity, change rate, and organizational controls; the key is to make the review recurring and recorded.
How to interpret changes
A change in configuration is not automatically a problem. Interpret it by asking what changed, who approved it, which environments are affected, and whether the application’s behavior changed as intended.
- A new service was added: create a new inventory entry, define the minimum required permission, and decide whether the service needs a secret at all. Prefer short-lived or narrowly scoped credentials where the platform and integration support them.
- A credential was rotated: verify the new value in a non-production environment, confirm the application’s reload or restart behavior, then remove the old value according to the provider and team procedure. Test both successful authentication and expected failure of the retired credential.
- A value appears in logs or an artifact: treat it as exposed. Preserve relevant evidence without redistributing the value, revoke or rotate it, identify the source of the disclosure, and add a regression check.
- Deployments fail after a configuration change: distinguish a missing value, an invalid format, a permission failure, and a downstream authentication failure. Log variable names, status, and safe error categories, but never log the secret itself.
- Several applications share one secret: consider whether the shared scope is necessary. Separate credentials can improve ownership, auditing, and rotation even when the applications use the same external system.
For debugging related request failures, use a structured workflow such as the API debugging guide. JSON formatting and token inspection can help with payloads and claims, but never paste live secrets or bearer tokens into an unapproved third-party utility. A decoder can reveal token contents; it does not validate a token or make an exposed token safe.
When to revisit
Revisit this configuration guide at least monthly or quarterly, and immediately after a material change to the application or delivery platform. A six-month review can be a useful broader checkpoint for provider capabilities, SDK integrations, deployment templates, and team standards, but it should not replace reviews triggered by risk or change.
Use this action list at each review:
- Export or update the configuration inventory without copying secret values into the review document.
- Confirm every sensitive value has an owner, a defined scope, and a documented delivery method.
- Check that local examples, CI/CD definitions, infrastructure code, logs, and artifacts contain names or references rather than credentials.
- Review access history and audit records where the chosen secret-management system provides them.
- Test one representative rotation path in a safe environment, including restart, reload, rollback, and failure handling.
- Remove unused variables, stale files, abandoned pipeline references, and credentials no longer required by the application.
- Update onboarding documentation and deployment templates when the standard changes.
Reassess the design when a service moves environments, a team adopts a new container or orchestration platform, an authentication method changes, a credential is exposed, or an application begins serving a new tenant or business capability. The goal is not to eliminate environment variables; it is to ensure that each value is delivered through the simplest mechanism that provides the required control, visibility, and operational reliability.
