Credentials and secret stores
This page documents storage boundaries and rotation rules. It must never contain a secret value, personal recovery contact, private incident link, or production access detail.
Provider dashboards and governed secret stores are the systems of record. A key copied into a ticket, chat, log, or Markdown file is exposed and must be rotated.
Secret stores
| Store | What belongs there | Application reference |
|---|---|---|
| Deployment environment | App-wide process configuration, scoped to Production/Preview/Development | src/lib/env.ts, direct runtime reads, framework config, deployment scripts |
| Per-client connector vault | Client-specific ad, commerce, CRM, and attribution credentials | platform_credentials, referenced by client_ad_accounts.credential_ref |
| Platform-service vault | Shared operational integrations | platform_service_credentials, managed from Admin → System Settings |
| Provider dashboard | Authoritative provider-side credential and ownership record | Provider console; never this repository |
Both database vaults use AES-256-GCM with CREDENTIAL_ENCRYPTION_KEY. Writes fail if the key is unavailable; reads fail closed according to the vault and caller. Losing or changing that key without a re-encryption plan can make stored credentials unreadable.
The platform-service source catalog currently includes ClickUp, Apify, Firecrawl, Deepgram, OpenAI, Cloudinary, TikTok Creative Center, and Google Cloud. The current database service constraint omits OpenAI, so OpenAI vault writes remain a documented schema gap until a migration aligns it.
Precedence and fallbacks
- Client connector bindings should resolve through
credential_ref; do not add inline credential columns. - Some platform integrations retain app-level environment fallbacks. Read the resolver before rotation so an older fallback cannot silently keep working.
PLATFORM_TOKENcan backfill selected legacy token settings when their dedicated values are absent. Treat it as shared blast radius and remove the fallback only with caller-by-caller verification.DEV_SUPERADMIN_*andAUTO_LOGIN_*are audit/development bypass settings. Keep them unset in normal Production deployments.
See Environment variables for the configuration scopes and Connectors for per-connector authentication shapes.
Rotation contract
There is no universal dual-secret rollout. For each credential:
- Identify every resolver and fallback that can supply it.
- Confirm the exact provider account, environment, tenant scope, and rollback path.
- Create the replacement with least privilege.
- Update the governed store and redeploy only if that consumer reads at build or process start.
- Verify the actual consumer: authentication plus a representative read/write path as applicable.
- Revoke the prior credential only after the replacement is proven.
- Record the owner and verification evidence in the access-controlled system of record.
Connector-vault changes normally do not require a deployment because jobs resolve the binding at runtime. Deployment-environment changes normally require a new deployment. OAuth changes may require provider consent rather than a simple value swap.
Recovery-critical material
The encryption key, database ownership, deployment ownership, provider recovery contacts, and emergency procedures belong in an access-controlled operations system. The public documentation should link to that system by policy, not duplicate its contents.
Verification status
This page was source-reviewed on 2026-08-26. It does not claim that production values, ownership, tiers, or connector health were live-verified. Use provider consoles, deployment settings, and Admin → Sync health for current operational evidence.