All articles
On this page

Production environment variables: prepare names, ownership and release checks

Manage application configuration by separating key names from secrets, checking build-time versus runtime use, and verifying the deployed process.

Vibe Hosting·Published About 2 min read

A deployment needs a defined configuration set, with private values delivered through the environment's supported process. Keep the names and purpose of required keys in the handoff, while storing actual secrets separately. This makes a release reproducible without turning the source archive into a credential store.

Classify each configuration key

For each key, record its purpose, whether it is required, which environment uses it and who controls its value. Distinguish public settings from server-only secrets. A value included in browser-delivered code should be treated as visible to visitors, regardless of how the build originally received it.

Check whether the framework reads a setting during the build or when the server runs. A runtime restart cannot necessarily change a value already embedded in generated browser assets. Use the installed framework's documented behavior when deciding whether a rebuild is needed.

Prepare the deployed process

  • Confirm the service account receives the intended configuration.
  • Keep production and preview destinations distinct.
  • Validate required keys without printing their full values.
  • Define how changes reach the process and which restart is required.
  • Exclude real environment files from public files and shared source commits.

In Node.js, environment values are accessed through process.env and need appropriate interpretation by the application. A textual value should not be assumed to have already become the intended number or boolean.

Verify behavior, not secret output

Check a safe application action that depends on the setting. For example, confirm the intended database environment or public base URL through controlled behavior rather than returning credentials in a diagnostic route. Review logs for accidental exposure during startup failures.

When an update changes configuration, include the required key changes with the release note and rollback plan. Support usually needs the key name, expected purpose and sanitised error to begin diagnosis; actual access details should follow the agreed private support process.

Continue with the next task

Database connection diagnosis · Staging before updates