Secrets · Premium Plus
Credentials your backend
can read and nothing else can.
Store API tokens, database passwords and private JSON credentials per environment, encrypted with a fresh key per version. Your servers fetch them over TLS with an explicit call. Browsers never see them.
Included in Premium Plus and Enterprise. Separate from Remote Config — your existing configs are untouched.
stripe-secret-key
String · v4 · updated 2 days ago
gcp-service-account
JSON · v2 · awaiting approval
postgres-password
String · v9 · updated 6 hours ago
A remote config is not a safe place for a password.
Remote Config is built to be read by browsers, cached at the edge, exported, and streamed over SSE. Every one of those properties is exactly wrong for a credential. Secrets is a separate resource with separate storage, separate scopes and a separate read path.
Remote Config
Dynamic settings and behaviour. JSON, String, Number, Boolean.
- Served to browser and mobile SDKs
- Cached, streamed over SSE, exportable
- Unchanged by Secrets — same types, same API
Secrets
Backend credentials. String and JSON, encrypted at rest.
- Server tier only — no client SDK can ask for one
- Never cached, never exported, never in an SSE frame
-
Its own
secrets:read/secrets:writescopes
The two namespaces are independent: a project may hold a config and a secret with the same key, and neither ever shadows or falls back to the other.
const { value } = await flagdash.getSecret(
"stripe-secret-key"
)
const stripe = new Stripe(value)
// Nothing is written to disk or cached.
// A failure throws — it never returns a default.One call from your backend. Nothing else changes.
Every shipped backend SDK gets a dedicated secret method. It returns the value and its version, and it caches nothing by default — a rotated credential takes effect on the next call, not on the next cache expiry.
Encrypted per version, bound to where it lives.
Each version is sealed with AES-256-GCM under a fresh data key, wrapped by AWS KMS. The account, project, environment, secret and version ids are authenticated in both the cipher and the KMS encryption context — so ciphertext lifted into another environment simply will not open.
Fresh key per version
No shared key across secrets, environments or replacements.
Versioned history
The current version plus 50 historical ones for 30 days. Restore creates a new version rather than rewinding.
Seven-day recovery
Deletion is soft for a week, then the ciphertext is purged for good.
Optional approvals
Require a second person on every change. The approved value stays readable while one waits.
Agents can see the names. Never the values.
The MCP server can discover which secrets exist, so an assistant can reason about your configuration. It cannot read, create, replace, restore, approve or delete one — on any path, even when the same person's other credentials would allow it in the portal.
It cannot quietly downgrade a secret into a plaintext config either. That request is refused with a pointer back to the portal.
> create a config called stripe-key that holds our live API token
For security, secrets must be created and changed in the FlagDash portal. Open Secrets → Create secret.
Every change is somebody's name and a timestamp.
Creation, replacement, restoration, approval, deletion and recovery all land in your audit log, in the same transaction as the change itself. If the entry cannot be written, the change does not happen. Values and keys are never recorded.
Stop pasting tokens into env files.
Secrets is included in Premium Plus and Enterprise, alongside GitOps and unlimited projects.