Environment variables without leaking production secrets

Classify your variables

• Public build values: safe to expose in browser bundles after review.
• Runtime configuration: read by server-side code at request time.
• Secrets: credentials and tokens that must never be included in build output or client-side code.

1. Create environment scopes

Use development for local testing, preview for pull requests, and production for live traffic. Keep the same variable name where possible so application code does not branch on environment-specific keys.

2. Add a secret

apex env set DATABASE_URL --environment production --secret

Secret values are encrypted at rest and redacted from deployment logs. Grant access through project roles rather than copying credentials into chat, tickets, or local dotfiles.

3. Rotate safely

Create the replacement credential first, update Apex, deploy, verify the new value is used, then revoke the old credential. This keeps a rollback path available while the migration completes.

Common mistake

Do not prefix a secret with a browser-exposed variable convention or import it into client code. Anything shipped to the browser should be treated as public.