Environment Variables & Secrets
Applications are configured through environment variables. Miabi distinguishes between plain variables and secrets, and stores secrets in an encrypted workspace vault so sensitive values never sit in plain text.
Plain variables vs. secrets
| Plain variable | Secret | |
|---|---|---|
| Example | LOG_LEVEL, PORT, NODE_ENV | DATABASE_PASSWORD, API_KEY, JWT_SECRET |
| Stored | As written | Encrypted at rest |
| Shown in console | Value visible | Masked |
| In logs / audit | Value may appear | Never shown |
Use plain variables for non-sensitive configuration and secrets for anything that grants access or must stay private.
The workspace secret vault
Secrets live in a workspace secret vault, shared across the apps in that workspace. Define a secret once and reference it from any application that needs it — rotate it in one place and every consumer picks up the new value on its next deploy.
All secret values are encrypted at rest and are never logged or returned in plain text. See Encryption for how Miabi protects them.
Once a value is stored as a secret, the console masks it. Treat secrets as write-only — to change a secret, set a new value rather than expecting to read the old one back.
Referencing database credentials
When you provision a database, Miabi generates its credentials and stores them as secrets. Reference these from your application's environment instead of copying connection strings by hand. This keeps credentials in the vault, encrypted, and rotatable without editing each app manually.
Redeploy on change
Environment variables and secrets are baked into the running container, so changes take effect on the next deploy. After editing a variable:
- Save your changes in the Environment tab.
- Trigger a deploy (or let your pipeline do it).
- Miabi brings up a new release with the updated configuration, with zero downtime.
Group related apps and share secrets across them with Stacks, and use Environments to keep dev, staging, and production values separate.