~/products/secrets

// foundation/secrets

Secrets out of your repo.

Encrypted secrets, available by reference

The Secrets Vault stores credentials encrypted and versions every change. Link a secret to a project, then read it by name from server code using the application’s managed identity.

setcloud secrets
$ setcloud secrets create DATABASE_URL "postgres://…"
✓ Secret "DATABASE_URL" created.

$ setcloud secrets delete DATABASE_URL
✓ Secret "DATABASE_URL" scheduled for deletion.
# recoverable for 7 days: setcloud secrets restore

// 01 — injection

Injected at deploy. Never committed.

Point a service at the values it needs and they're delivered to your app as environment variables when it goes live. The secret lives in exactly one place — encrypted — instead of in config files scattered across your team's laptops.

  • + Vault values delivered to your app at deploy
  • + Encrypted where stored, and served over a secure (HTTPS) connection
  • + Create and read from the dashboard or CLI

// 02 — versioning

Every change, kept.

Each update saves a new version instead of overwriting the old one. Use version labels to manage secret history, inspect earlier versions, and restore a deleted secret within its recovery window. Deleting a project removes its managed credentials and access, while customer-created Vault secrets remain until separately deleted. Project links read the current version at startup; moving a label does not refresh an already running app.

  • + Full version history per secret
  • + Version labels and current-version promotion
  • + Deleted secrets recoverable for 7 days

// 03 — runtime access

Refresh credentials while your app runs.

Update a credential in the vault and read its current version through the Secrets SDK. Runtime reads use temporary application identity and are limited to linked secrets. Startup environment values refresh when instances restart. Additional replica regions are not currently available; scheduled rotation integrations are not currently available.

  • + Read linked secrets by friendly name from server code
  • + Fresh reads by default, with optional bounded caching
  • + Runtime access recorded in the audit log after event processing

// 04 — control

Project access, tags, and bulk reads.

Link a secret to a project to grant its temporary application identity access. Custom policies and external identity grants are not currently available. Tag secrets to keep them organized, read a whole group of them in a single request, and generate strong random passwords without rolling your own.

  • + Runtime access limited to linked project secrets
  • + Tags, bulk reads, and password generation built in
  • + Active secret storage plus metered API operations; current rates below

Current pricing

USD rates from the current billing catalog. Regional references vary with attributed usage.

Loading current rates…

Get keys out of git.

Active secret storage plus metered API operations; current rates below.