Secrets management before you buy a vault

Ask how a team manages secrets and the answer is often a product name. Ask where the database password actually is and the answer is usually longer, less certain, and involves at least one place nobody is happy about.

Dedicated secret managers are good tools that solve real problems. They are also frequently adopted before the problems they solve are the ones the team has.

The problems teams actually have first

Copies. The same credential is in a deployment manifest, a CI variable, a laptop's environment file, and a message someone sent during an incident. Rotating it means finding all of them, so it is never rotated.

No boundary between environments. Staging and production read from the same place, which means a mistake in staging is a production incident.

No record. Nobody can say who read the production credential, or when, because nothing recorded it.

Plaintext at rest. The value is sitting readable in a datastore, so a dump of that datastore is a list of credentials.

None of these are solved by buying a vault and continuing to copy values out of it by hand. All of them are made worse by having more places a secret can live.

The order that works

1. One home per secret. Pick where a given credential lives and delete the other copies. This is the step that makes the rest possible and the one most often skipped.
2. Scope it to an environment. Production secrets belong to production and are not readable from anywhere else. Isolation is worth more than encryption at this stage, because it limits blast radius rather than just storage risk.
3. Inject, do not copy. The value should arrive in the process as an environment variable or a mounted file at deploy time. Nobody should paste it anywhere to make a deploy work.
4. Encrypt at rest. Now worth doing, and worth understanding precisely: it protects a stolen copy of the datastore, not a compromised running system.
5. Record access. Reading a production credential should leave a trace, so "who has seen this" is answerable.
6. Then consider a vault, when you need dynamic credentials, short-lived leases, or a policy engine. Those are real needs. They are step six.

What Anyport gives you without a decision

Secrets belong to a project, which is also the isolation boundary for apps and configuration, so staging and production do not share them by construction. They are synced to the right cluster and mounted into the apps that need them, so the deploy path never requires a human to copy a value.

Values are encrypted with AES-256-GCM before they are written, under a named key so rotation does not require re-encrypting everything at once. The console lists names rather than values; revealing an actual value is a separate permission and is recorded, and every change lands in the audit log.

That covers steps one through five for most teams, which is usually the gap that mattered. We wrote about what step four does and does not protect in encryption at rest is a storage guarantee.