Worker Secrets

Studio uses three Worker Secrets for authentication and lifecycle access. They are separate from provider credentials saved through Studio settings. Studio can generate candidate values in the browser but does not change its own Cloudflare configuration.

Responsibilities

Secret	Purpose	Lifecycle
STUDIO_AUTH_SECRET	Protect MFA material, sealed authentication state, encrypted provider credentials, and purpose-specific hashes	Preserve with the installation and database
STUDIO_INSTALL_TOKEN	Authorize initial installation	Delete the binding after installation
STUDIO_OPERATIONS_TOKEN	Authorize protected maintenance and recovery	Configure with the Operations allowlist when needed

Each value must contain 32–256 printable ASCII characters from ! through ~, with no spaces or control characters. Generate independent random values:

openssl rand -hex 32

Run the command separately for each Secret. The resulting 64-character value contains 256 bits of randomness. Keep a secure copy of STUDIO_AUTH_SECRET outside D1; database backups do not include Worker configuration.

Cloudflare Storage

In the Worker’s Variables and Secrets settings, add each required binding as a Secret, then apply the configuration. STUDIO_SITE_MODE and STUDIO_OPERATIONS_ALLOWED_IPS are ordinary plaintext Variables.

The running Worker can validate presence and format but cannot tell whether a value was stored as a Secret or a plaintext Variable: both arrive through the same environment interface. A Secret label in Studio describes the required storage type rather than a runtime inspection of Cloudflare configuration.

The equivalent Wrangler commands are:

npx wrangler secret put STUDIO_AUTH_SECRET
npx wrangler secret put STUDIO_INSTALL_TOKEN

Run them from the intended deployment repository. Applying configuration can create a new Worker version; use the deployment controls for that installation.

Installation and Activation

In initial mode, the installation checklist shows the required mode and Secret state. Its generate actions create independent browser-only values for you to store in Cloudflare. They never reveal a previously saved Secret.

After installation, delete STUDIO_INSTALL_TOKEN completely and switch to operational. Keeping the binding, even with an empty value, blocks normal access. Do not replace STUDIO_AUTH_SECRET during activation.

Operations credentials are not needed for initial installation. See Maintenance & Recovery for the allowlist, token, and setup-guide conditions.

Local Development

On first npm run dev, Studio creates an ignored .dev.vars with STUDIO_SITE_MODE=initial and separate generated authentication and install Secrets, provided no existing .dev.vars or .env configuration is present. Existing local configuration is preserved.

After local installation, remove the install token, set the mode to operational, and restart the server. Preserve the authentication Secret when reusing the local database. Add Operations credentials only when needed and never commit environment files or generated Secrets.

Replacement and Recovery

Changing STUDIO_AUTH_SECRET can make existing encrypted TOTP and provider credentials unusable. It also invalidates protected temporary authentication state and changes newly generated keyed hashes. It does not encrypt WebAuthn public keys or replace account password hashes.

If the Secret is lost or must be replaced, retain the database backup, configure one stable replacement, and follow MFA Recovery. A working current-host Passkey can help replace TOTP; otherwise use the eligible administrator or Operations recovery path. Re-enter affected GitHub, Analytics, and mail credentials afterward.

Moving or restoring the same installation requires its matching Secret. A new Secret is not a substitute for recovering encrypted values in an existing backup.