Secrets
How secrets are stored, scoped and exposed — and how to keep them out of harm's way.
Purpose — Secrets (database passwords, API tokens, private keys) are the most sensitive configuration in Notploy. This page covers their lifecycle and the ways they leak.
How secrets are stored
Notploy stores environment variables and secrets in its PostgreSQL database, encrypted. Values can be defined at three scopes — project, environment and service — and resolved from broad to specific. See Environment variables.
For secrets managed outside Notploy, an external secrets provider (HashiCorp Vault, AWS Secrets Manager, Doppler, Infisical, Azure Key Vault, Scaleway) can be connected so services read values at deploy time without storing them in Notploy.
Choosing a scope
| Scope | Use for |
|---|---|
| Project | Values shared by every service (for example a shared database URL). |
| Environment | Values that differ per environment (staging vs. production credentials). |
| Service | Values specific to one service, or overrides of broader values. |
Narrower scopes reduce blast radius. Do not put production credentials at project scope if only one service needs them.
Common exposure risks
- Committing secrets to a repository. Use Notploy variables or a secrets provider instead.
- Logging them — some apps print configuration at startup. Be careful with verbose logs, which Notploy captures.
- Broad scope — a project-level secret is visible to every service in the project.
- Sharing screenshots — the environment editor displays values; mask or avoid capturing them.
- Build vs. runtime — a variable available at build time is baked into the image; prefer runtime injection where possible.
Never put real credentials in examples
Documentation, issues and support requests must not contain real secrets, private hostnames or production identifiers. Use placeholders.
Rotation
Rotating a secret means updating it in Notploy (or the provider), then redeploying or restarting the affected services so they pick up the new value. Plan for the brief interruption and update any external systems that use the same credential.
Verification
After changing a secret, confirm the service still starts and connects (check runtime logs). A crash on boot immediately after a secret change usually means the new value is malformed or a reference to another variable broke.