Which environment variables must be configured in production?

Which environment variables must be configured in production?

The required production environment variables are the ones the deployed application actually reads for its enabled features. There is no universal list that fits every wedding application. Start with the configuration schema, environment example file, and code paths rather than copying a development environment without review.

A useful inventory records each variable's purpose, whether it is secret, and which deployment environments need it.

Map variables to working features

Typical categories include:

• Database connection details for the production data store.
• Authentication secrets and provider configuration.
• Email credentials and an approved sender identity.
• Storage credentials and bucket configuration when uploads exist.
• Application origins used to create links and redirects.

Names vary by library and application. An illustrative DATABASE_URL or APP_URL is not automatically the name the code expects. Configure only integrations that the current release uses.

Separate server secrets from public configuration

Database passwords, signing secrets, and email API keys belong in server-side configuration. In Next.js, variables intentionally exposed with the NEXT_PUBLIC_ prefix can be included in browser code; they must not contain secrets. Next.js documents this distinction.

A public site origin can be client-visible when necessary, but values used for secure redirects should still be validated according to the application's rules.

Apply and verify the production scope

On Vercel, variables can target environments such as Production, Preview, and Development. Changes apply to new deployments rather than altering existing ones. Configure the correct scope and deploy again. Vercel's environment-variable guide explains this behavior.

Verify configuration through controlled feature checks and safe presence diagnostics, not by printing secret values. Confirm that production points to production services and that previews use isolated test resources. Keep the example environment file current using placeholders so future deployment work remains repeatable.