Next.js

Authdog Vault stores environment-scoped configuration values and secret material. Use it for credentials consumed by Authdog-managed workflows or workloads explicitly integrated with your Authdog environment.

Current access model

Vault management is console-only today. Select project and environment, then open Secrets → Vault in Authdog console. Console uses internal management GraphQL operations; they are not a supported public secret-management API. Do not automate against those operations.

Vault is separate from API access secrets:

Vault entries hold your values, such as provider credentials, JSON, YAML, PEM, or opaque files.
Environment API secrets authenticate backend calls and carry scopes such as environment:read or environment:update.

Do not paste an environment API secret into Vault as a substitute for proper workload secret storage.

Create a secret

Select correct project and environment.
Choose Add new.
Enter unique name. Use / separators, such as production/database/password, for console folder organization.
Enter text or select file.
Add optional description and expiration date.
Keep Encrypt variable enabled for sensitive values.
Save and verify intended entry appears in selected environment.

Text mode preserves multi-line UTF-8. File mode Base64-encodes bytes before storage; consumers must Base64-decode value to recover original file. Names must be unique within environment.

Encryption behavior

Encrypted entries use AES-256-GCM authenticated encryption. Service refuses encrypted writes when required server encryption key is missing; it does not fall back to a built-in default key. Encrypted ciphertext uses versioned storage format so implementation can evolve.

Authorized console reads currently decrypt and return secret value for editing. Therefore, “encrypted” means protected at rest, not write-only. Anyone with sufficient Authdog console access to read Vault can receive plaintext. Apply least privilege to console membership and protect administrator sessions with MFA.

Console also exposes environment KMS controls:

AES-256-GCM keys can be generated and selected as default.
KMS UI designates a default for new encrypted material.
Marking key as rotating records rotation state.
Disabling a key still in use can make existing ciphertext unavailable.

Current Vault write path does not expose a public control that binds a Vault entry to selected KMS key; it uses service-managed encryption configuration. Do not assume changing KMS default automatically re-encrypts existing Vault entries. RSA-OAEP-4096 appears as an option, but current console states keypair generation is not yet wired up. Treat Vault/KMS re-wrap automation and RSA KMS support as incomplete.

Rotate a secret

Vault update replaces value while retaining entry identity and metadata. Safe rotation:

Create replacement credential at upstream provider.
Update Vault value.
Verify dependent workflow.
Revoke old credential upstream.
Review audit activity.

There is no documented public API for atomic multi-secret rotation or version rollback. Coordinate changes that span several entries, and keep external recovery material where required.

Expiration and deletion

Expiration is metadata shown by console. Do not assume Authdog automatically rotates value, revokes upstream credential, or deletes expired entry unless your integration explicitly implements that behavior.

Deletion is irreversible in console. Confirm environment, dependency, and recovery plan before deleting.

Operational guidance

Use separate entries in every environment; never reuse production credentials in development.
Prefer narrow credentials with provider-side scopes and expiration.
Keep encryption enabled unless plaintext storage is an explicit, reviewed requirement.
Never store user passwords, TOTP codes, session tokens, or private data without defined need and retention policy.
Record owner and purpose in description.
Rotate after staff or vendor access changes.
Review Audit logs after create, update, or delete operations.

Vault