Rotate secrets and env vars
Where configuration lives, how the console hides values it will not show you again, and what actually happens when you rotate a credential.
Every app needs configuration, and some of it is sensitive. Dibbla keeps both in the same place and treats the sensitive kind as write-only.
Two scopes
Secrets are either global to your organisation — every app gets them — or scoped to a single deployment. The console’s Secrets view lists both, with the scope in its own column.
Creating a managed database, for instance, adds a global secret holding its connection string, so any app in the org can reach it without you copying a DSN around.
# global: every app in the org $dibbla secrets set STRIPE_KEY # one deployment only $dibbla secrets set STRIPE_KEY -d my-first-app $dibbla secrets list
The per-app editor, and the four asterisks
The app card’s ⋮ → Edit deployment opens the environment editor. Reopen it after saving and you will see this:
**** is not a placeholder for a short value — it is the platform declining to
send the secret back to your browser. Three consequences worth knowing before
you edit anything:
- Saving
****keeps the stored value. You can change one variable without knowing, or disturbing, the others. - The set you submit replaces the stored set. Remove a row and that variable is deleted on save. This is why deleting a masked row asks you to confirm: the platform cannot show you what you are about to throw away.
DIBBLA_*variables never appear. The platform injects its own — the gateway URL, your app’s alias, service discovery — and filters them from the editor in both directions, so you cannot accidentally clobber them.
Rotating a credential
Rotation is just that first rule, used deliberately: type the new value over the mask and save.
Secrets reach a container as environment variables, and environment variables are fixed when the container starts. Saving updates the stored value and every pod that starts from now on; the pods already running keep serving with the old one. If you are rotating because a credential leaked, the leaked credential is still live in production until you restart:
dibbla apps restart my-app --service app--service is required. For a single-service app it is app; for a
manifest deploy, use the name as it appears in dibbla.yaml, and restart
each service that reads the secret.
A rotation you believe finished but did not is worse than one you know is pending.
The same principle governs API tokens in the portal: the full value exists on screen exactly once, at creation. After that the list shows a truncated form forever. Copy it into your secret store at that moment or create another one — there is no way to recover it, deliberately.
It is genuinely useful for a long-lived CI runner and genuinely dangerous everywhere else. Prefer a bounded lifetime and a calendar reminder over a token that outlives the person who made it.
Have a code agent rotate a secret without ever printing it.
Rotate the STRIPE_KEY secret for my Dibbla app "my-first-app" using the dibbla
CLI. Read the new value from the environment variable NEW_STRIPE_KEY rather
than putting it in a command line, and confirm afterwards that the secret is
listed but do not print its value.Where secrets should not go
Not in the image, not in the repository, not in -e flags that land in your
shell history. And not in a docs/ page — that directory is published to your
users as the app handbook.