Guides

Environment & secrets

The scope model — global, per-deployment, per-service — plus the platform variables you get for free and the ones you must not fight.

Rotate secrets and env vars covers the console side. This page is the model underneath it: where a value lives, and who sees it.

Three scopes

Scope	Set with	Who gets it
Global	`dibbla secrets set KEY`	every app in the organisation
Deployment	`dibbla secrets set KEY -d my-app`	one app, all its services
Service	`dibbla secrets set KEY -d my-app --service api`	one service of one app

The narrowest scope that holds a value wins. Reach for global sparingly: it is right for something genuinely shared (a database every app queries) and wrong for anything an app owns.

# pipe the value in — it stays out of your shell history
$printf '%s' "$STRIPE_KEY" | dibbla secrets set STRIPE_KEY -d my-app
 
# from a file, for bulk import
$dibbla secrets import .env -d my-app
 
$dibbla secrets list
$dibbla secrets delete STRIPE_KEY -d my-app --yes

Omit the value and the command looks like it has frozen

There is no prompt. dibbla secrets set NAME -d app with no value reads stdin until EOF — no message, no hidden input, and what you type is echoed in the clear. It is not hung; it is waiting for Ctrl-D. Pipe the value in, as above, rather than typing it.

Plain env vars versus secrets

dibbla deploy -e KEY=value and apps update -e KEY=value set values that persist across updates, and both survive an update — but they are not stored like secrets. A deploy -e variable is written inline into the container’s pod spec, in plain text, where anyone who can read the deployment can read it. Anything sensitive should go in through secrets set, which keeps the value in a Secret object and out of your command line, your CI log and your shell history.

Build time is not run time

Frontend bundlers inline variables at build time. A value you set after the build — including anything you add with apps update -e — will not appear in an already-built bundle, no matter how correct it looks in the console. If a browser needs a value, it has to be present when the image is built; if a server needs it, run time is fine.

What the platform injects

Your app receives a set of DIBBLA_* variables it did not set: its own alias, its service name, the LLM gateway URL, service-discovery addresses for its siblings. Two rules:

Do not try to set them. The platform filters DIBBLA_* in both directions — they never appear in the console’s editor and are dropped if you submit them.
Read them rather than hardcoding. The gateway URL and sibling addresses differ per environment; that is the entire point of them being injected.

The delete-by-omission rule

The console’s environment editor submits the whole set, so removing a row deletes that variable on save. Existing secret values come back as ****, and saving **** preserves them — which is what lets you change one variable without knowing the others. Deleting a masked row asks for confirmation, because the platform cannot show you what you are about to discard.

The CLI is explicit instead: secrets set adds or replaces one key, secrets delete removes one. Nothing is implied by omission.

← Previous

Deploying apps

Connecting a database