Skip to main content

Environment Variables And Secrets

Variables let you configure workloads without committing values to source code.

Where Variables Are Used​

WorkloadVariable Behavior
ApplicationRuntime variables are injected into the running app. Build variables can also be injected during build.
Catalog serviceRequired fields are collected during deployment, with password fields marked sensitive.
Service dependencyCredentials may be generated or passed through the service setup.

Runtime Variables​

Runtime variables are available after the workload starts.

Use runtime variables for:

  • Database URLs.
  • API keys.
  • Feature flags.
  • App configuration.
  • OAuth client IDs and secrets.
  • SMTP settings.

Build-Time Variables​

Build-time variables are available during application build.

Use them only when the build needs the value, such as:

  • Installing from a private package registry.
  • Setting public frontend build configuration.
  • Selecting a build target.

Avoid exposing runtime-only secrets to the build step.

Sensitive Values​

Moltern treats sensitive names as write-only after save. Names containing words such as SECRET, PASSWORD, TOKEN, KEY, or PRIVATE may be masked.

If a value is masked:

  • Leave it unchanged if it should stay the same.
  • Enter a new value if you want to rotate it.
  • Do not expect to reveal it from the UI later.

Individual Mode​

Use individual mode when:

  • You have a small number of variables.
  • You need to mark specific variables as build-time.
  • You want to delete one value safely.

Bulk Mode​

Use bulk mode when pasting many variables.

Format:

NODE_ENV=production
PORT=3000
DATABASE_URL=postgres://example

Rules:

  • One KEY=VALUE per line.
  • Lines starting with # are ignored.
  • Sensitive values may not be shown back after save.
  • Switch to individual mode to set build flags.

Rotation Checklist​

When rotating a secret:

  1. Generate the replacement value in the source system.
  2. Open the workload settings.
  3. Replace the variable value.
  4. Save.
  5. Redeploy or restart if the app needs to reload configuration.
  6. Confirm the workload is healthy.
  7. Revoke the old value in the source system.

What Not To Do​

  • Do not commit secrets to Git.
  • Do not paste real secrets into docs or tickets.
  • Do not put credentials in build logs.
  • Do not reuse production credentials in development environments.
  • Do not share one database credential across unrelated apps.

Service Credentials​

Many catalog services ask for usernames, passwords, keys, or connection settings during deployment.

For production:

  • Use unique credentials per service.
  • Store generated credentials in your approved secret process.
  • Rotate credentials when ownership changes.
  • Document which app uses which credential without writing the credential itself.