API keys, database passwords, webhook signing keys, and deployment tokens should not be scattered through source code or shared documents. This guide explains practical cloud secrets management for small web apps, including when to use environment variables, a dedicated secret manager, encrypted configuration, or local development files. It also provides a recurring checklist for access control, logging, rotation, revocation, and recovery.
Overview
Secret management is the process of storing, delivering, using, rotating, and revoking sensitive values without exposing them unnecessarily. A secret might be a database password, payment provider key, private API token, JSON service credential, session-signing key, or certificate private key. Treating all of these values as ordinary configuration creates avoidable risk: they can appear in Git history, build logs, screenshots, error messages, backups, or developer machines.
The right storage method depends on the application’s size, deployment model, and operational maturity. Environment variables are often a reasonable starting point for a small deployment because the application can read configuration at runtime without embedding it in the codebase. They are not automatically secure, however. A value can still be exposed through an insecure deployment dashboard, diagnostic output, process inspection, or an overly broad user account.
A dedicated cloud secrets manager is usually more appropriate when several services, environments, or team members need controlled access. It can separate secret administration from application code, support audit records, and make rotation easier. Encrypted configuration files can work for specific deployment workflows when encryption keys are stored separately and access is tightly controlled. Local development files are useful for individual machines, but they should remain untracked and should never be treated as the production source of truth.
| Storage method | Best fit | Main control to verify |
|---|---|---|
| Environment variables | Small apps and straightforward deployments | Limit dashboard, host, and process access; prevent secret logging |
| Dedicated secret manager | Multiple environments, services, or team members | Use least-privilege identities, audit access, and version values |
| Encrypted configuration | Automated builds or deployments requiring a file format | Keep decryption keys outside the repository and deployment artifact |
| Local development files | Developer-specific settings and test credentials | Add files to ignore rules and use non-production credentials |
Use separate secrets for development, staging, and production. Environment separation limits the impact of a leaked test credential and prevents a local experiment from reaching production data. For a broader deployment workflow, see the cloud deployment checklist for small SaaS projects and developer websites.
What to track
Inventory and ownership
Maintain a simple inventory of every sensitive value the application uses. Record its purpose, environment, owning service or team, storage location, last rotation date, next review date, and recovery dependency. Do not record the secret itself in the inventory. Useful categories include database credentials, third-party API keys, cloud access tokens, encryption keys, webhook secrets, SMTP credentials, OAuth client secrets, and TLS private keys.
Assign an owner for each secret, even if the owner is a team rather than an individual. The owner is responsible for confirming that the value is still needed, identifying who can access it, and coordinating replacement or revocation.
Access and delivery
Track which application identity reads each secret and whether access is needed at build time, deployment time, or runtime. Prefer runtime access when practical so a secret does not become part of a build artifact. Give the application only the permissions it needs; a web process that only reads one database should not receive broad administrative credentials.
Review human access separately from machine access. Developers may need permission to configure a deployment without being able to read production values. Use named accounts where possible, remove former team members promptly, and avoid shared administrator credentials.
Logging, exposure, and recovery
Confirm that secrets are redacted from application logs, CI output, error reports, shell history, and support tickets. Check whether debugging tools display process environment variables or request headers. Logging access events can help identify unusual use, but never log the secret value to make an audit trail.
Document how to revoke a compromised credential, issue a replacement, update the application, and verify that the old value no longer works. Recovery should include the dependencies around the secret. For example, restoring a database backup may require a current database credential, while restoring a certificate may require access to its private key and renewal process. Pair this review with a tested website backup and recovery strategy.
Cadence and checkpoints
A recurring review is more reliable than waiting for a security incident. Use a monthly or quarterly checkpoint that matches the size and change rate of the application. A small, low-change site may need a quarterly review; an app with frequent deployments, contractors, or many integrations may benefit from a monthly review.
Monthly checkpoint
- Review newly added secrets and remove values no longer used.
- Check recent access logs for unexpected identities, environments, or times.
- Confirm that production values are not present in repositories, build artifacts, tickets, or logs.
- Verify that alerts and deployment failures do not reveal secret contents.
- Check whether any team member, service account, or integration has changed.
Quarterly checkpoint
- Rotate high-impact credentials according to the provider and application’s safe procedure.
- Test revocation by replacing a non-critical credential or using a controlled test environment.
- Review permissions and remove access that is no longer required.
- Test the documented recovery procedure from a clean administrative account.
- Confirm that backups, staging systems, and monitoring integrations follow the same separation rules.
Rotation should be planned rather than improvised. For credentials that cannot be changed without downtime, support an overlap period: create the replacement, deploy the application so it accepts the new value, verify healthy operation, then revoke the old value. Do not delete the old credential before confirming that every dependent service has been updated.
How to interpret changes
A new secret, service, or deployment target should trigger an inventory update. A change in application architecture may also change the appropriate storage method. For example, moving from one server to several services can make manually copied environment variables difficult to audit, while a secret manager with service identities may provide clearer control.
Unexpected access is a signal to investigate, not proof of compromise by itself. Compare the event with deployment history, scheduled jobs, staff activity, and provider logs. If access cannot be explained, treat the credential as exposed: preserve relevant logs, revoke or rotate it, inspect the application and repository, and check for unauthorized changes.
Frequent emergency rotations usually indicate a process problem. Look for secrets copied into tickets, long-lived tokens used by automation, excessive administrator access, or deployments that require manual editing. The goal is not merely to rotate faster; it is to reduce the number of places where secrets can appear and to make replacement routine.
When to revisit
Revisit this guide and your application’s inventory monthly or quarterly, and immediately after a deployment or operational change. Create an extra review when you add a third-party integration, move to new cloud hosting, introduce a staging environment, change database providers, alter CI/CD permissions, or bring a new administrator into the project. Also review secrets after suspected exposure, unusual access, a team-member offboarding event, or a failed disaster-recovery exercise.
Use this short action list at the next checkpoint:
- List every secret by purpose and environment, without recording its value.
- Identify the application identity and human roles that can access each one.
- Remove unused credentials and reduce permissions where possible.
- Check repositories, logs, build artifacts, backups, and local files for accidental exposure.
- Rotate one high-impact credential using a documented replacement and revocation plan.
- Record the result, owner, and next review date.
For websites and developer projects hosted in the cloud, secrets management should sit alongside deployment, uptime, backup, and certificate practices—not as a separate afterthought. Review the website uptime monitoring checklist after a credential change, and verify that SSL and deployment automation still operate normally.
