Secrets do not belong in the repository, or in a chat message
The fastest way to leak a credential is to paste it somewhere convenient. A central secrets manager removes the temptation by giving every environment a single place to read from, and every machine its own identity to read with.
Machine identity over shared keys
A shared API key in a deploy environment is a key that everyone has and nobody can rotate without a coordination meeting. A machine identity is scoped to one workload, can be revoked on its own, and leaves an audit trail of what read what and when. That distinction is exactly what a compliance reviewer is looking for.
// fetch secrets at boot with a scoped machine identity
import { InfisicalSDK } from "@infisical/sdk";
const client = new InfisicalSDK();
await client.auth().universalAuth.login({
clientId: process.env.INFISICAL_CLIENT_ID!,
clientSecret: process.env.INFISICAL_CLIENT_SECRET!,
});
const secrets = await client.secrets().listSecrets({
environment: "prod",
projectId: process.env.INFISICAL_PROJECT_ID!,
});
The only two values that live in the host environment are the client id and client secret of the machine identity. Everything else, the database URL, the payment keys, the model provider keys, is fetched at boot. Rotate a secret in one place and every workload picks up the new value on its next start.
Self hostable is a residency feature, not a footnote
Infisical is open source and can run inside your own infrastructure. For a healthcare or public sector build with data residency rules, that means the secrets never leave a boundary you control. The same code path works whether the manager is the hosted service or your own instance, so you do not rewrite anything to satisfy the requirement.
The habit that matters
Treat the secrets manager as the only legitimate source of a credential. The moment a key exists in two places, one of them is wrong and you do not know which. One source, scoped identities, rotation in a single screen.