Store and rotate application secrets

Store server-side credentials

Application secret values are submitted through write-only fields and stored in Azure Key Vault. The control-plane database keeps metadata, version history and external references. Ordinary project/secret responses do not return values or provider references. Current workspace owners and administrators manage secrets; project membership alone does not authorize mutations.

Open the project's Secrets area, select the environment, choose the name and submit the value. Public frontend prefixes such as PUBLIC_ and NEXT_PUBLIC_ are not accepted for private backend secrets. Reference the name from authorized backend code; never copy the value into frontend source or a build artifact.

Names and environment scopes are fixed after creation. Use rotation to replace a value. Production, preview and development scopes are distinct. Preview selects eligible preview values ahead of development and does not use production values.

Deployment copies and module access

Compilation resolves eligible active, unexpired values and records their versions in an authenticated encrypted deployment snapshot. Production releases are immutable. The edge decrypts the snapshot, and runtime policy controls which private values enter the module environment.

Per-module name, environment and version grants require the scoped-policy rollout and a fresh compatible deployment. A historical policy without those rules retains its legacy coarse permissions during migration. Do not assume enabling secrets automatically limits each module to one secret.

Once delivered, a value is readable by application code. Host-side secret wrappers reduce accidental platform logging; they cannot stop a module from returning, logging or sending a secret. Review module code, user authorization and outbound HTTPS permissions together.

Rotate, adopt and retire

1. Create or rotate the credential with its external provider as appropriate.
2. Rotate the BlinkHost secret to the intended value and allow its new version where scoped grants apply.
3. Build and activate fresh releases for affected environments.
4. Verify application authentication and regional configuration adoption.
5. Revoke the old credential with its provider when the cutover is safe.

BlinkHost retains old external references while deployment adoption is unresolved. Its lifecycle moves from awaiting_adoption to retirement_queued, then retired after recorded external-store deletion. Missing acknowledgements, failed deployments and unverifiable old snapshots keep retirement pending. Configuration adoption is not proof that the external API accepts the new credential.

Disabling or expiring a secret prevents its selection for new snapshots; it does not retract copies already delivered in old releases. Deleting a Key Vault reference does not revoke a Stripe, email or other provider credential. Provider retention can also keep deleted values recoverable for a period.

Emergency revoke

Emergency revocation disables project secrets and locks the project, including when every secret is already disabled. A durable generation prevents reactivating or unlocking an obsolete release. Deploy current safe configuration before unlocking.

Edges reject new execution and cancel host operations when they receive the signed denial. Delivery, durable acknowledgement, partitions and already-running code affect enforcement time; there is no instantaneous global revocation guarantee. Preview checks each new invocation but does not push cancellation into an already-running preview guest. Revocation cannot undo committed SQL or an external request already sent.

Deletion and abandoned-value cleanup use durable retry records. Operators investigate untracked external entries before removing anything; an untracked reference can belong to another platform service. Keep credential values and temporary bearer URLs out of logs and support reports.