Configure an environment
Set process configuration through typed names while keeping secrets and role authority separate.
Outcome
Each process receives only the configuration required by its current role, and invalid origins or missing production credentials fail explicitly.
Prerequisites
Choose the environment (local, preview, staging, or production) and its app, worker, or
migration role. Review the generated setting names; it is the current code
truth for the implemented Settings model.
Steps
- Put non-secret local values in the ignored environment file or current shell.
- Put production secrets in the hosting provider's secret manager.
- Give migration administration credentials only to the pre-deploy migration job.
- Give the app and worker distinct least-privilege database credentials as those roles activate.
- Use absolute HTTP(S) origins without a path for public API and CORS configuration.
- Restart the owning process after configuration changes.
Do not copy example values into production. Do not place database administration, Temporal, object administration, compute organization, connector, or model-provider credentials inside a sandbox.
Verify
Run the process readiness check and the relevant contract tests. For local Slice 0, pnpm check
validates the Settings model and full story. Production verification must additionally prove the
effective role and secret boundary, not merely that environment variables exist.
Recover
If startup rejects a value, restore the last known-good environment revision and fix the named field. If a secret may have crossed a boundary, revoke and rotate it before restarting work, then inspect logs and artifacts for exposure.