Managing application secrets
Public variables vs secrets, encryption and best practices for sensitive data.
An application often needs configuration values: some harmless (log level, public URL), others sensitive (passwords, API keys, connection strings). Nubiecloud tells the two apart.
Public variables vs secrets
| Public variables | Secrets (sensitive variables) | |
|---|---|---|
| What for | non-sensitive configuration | confidential data |
| Examples | LOG_LEVEL, ENVIRONMENT | DATABASE_URL, API_KEY, JWT_SECRET |
| Storage | clear text | encrypted |
| Display | visible | hidden, never shown again |
Add / change
Variables are managed in the deployment configuration (at creation time, or through Edit on an existing deployment):
- Open the application's configuration.
- Environment variables section for public values, Sensitive variables (secrets) section for secrets.
- Add key / value pairs, then save. The application is redeployed with the new configuration.
🔒 Secrets are encrypted at rest and injected into the application at runtime. Once saved, a secret is never shown in clear text again: when editing, the field appears empty — you can replace the value (by entering a new one) or remove the row, but not read the old one back.
ℹ️ There is no separate "secrets manager" page: secrets live at the level of each deployment. There is no (yet) automatic rotation — to change a secret, edit it manually and redeploy.
Best practices
- Put everything sensitive (database passwords, NubiS3 keys, tokens) in the secrets, never in the public variables.
- Use different secrets per environment (dev / prod).
- After a suspected leak, change the value at the source (e.g. regenerate the API key) and update the secret.