Environment Variables And Secrets

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

Where Variables Are Used​

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.

Service Connection Secrets​

Managed service connection details are handled differently from application variables.

For private services such as databases, Moltern can show generated connection details on the service page. Non-sensitive fields, such as host, port, database name, and username, may be visible. Passwords, tokens, and generated connection strings stay masked until you reveal them with your connection details password.

Some catalog services also create initial login details, such as an admin email, username, password, or setup token. When a service exposes those managed credentials, they appear in the same Connection Details panel and use the same protected reveal flow.

The connection details password:

• Is separate from your login password.
• Can be set by social-login users.
• Protects sensitive service connection values only.
• Should be stored in a password manager.

See Connection Details Password for the setup and reveal steps.

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.