Core concepts
The seven words the rest of the documentation assumes you know — and the two surfaces you will spend your time in.
Deliberately short. These are the words the rest of the documentation leans on; everything else is explained where it is used.
The two surfaces
Most confusion between colleagues comes from not having these apart:
| The console | The portal | |
|---|---|---|
| Who uses it | you, building and operating | your organisation, using what you built |
| What it shows | deploys, logs, secrets, databases, version history | a catalogue of apps you may open |
| Where | console.dibbla.com | app.dibbla.com |
Sending a colleague a console link when they wanted the app is the single most common mix-up on this platform.
The seven words
App — one deployed thing, identified by its alias (lumen). The alias
is the name you pass to every command; the hostname it is served on is that
alias plus a short suffix for your organisation.
Deployment — one shipped version of an app. Every deploy is also a commit
in a repository the platform keeps for you, with your -m message as its
subject, so an app has a history whether or not you kept one.
Organisation — the boundary everything lives inside. Databases, secrets and apps belong to an org, not to a person. Being in an org is what lets a colleague see an app in the portal.
Secret — a value your app receives as an environment variable. The console
never displays one, so a browser session cannot leak it; the CLI will, with
dibbla secrets get. Secrets are either global to the org or scoped to one
deployment.
Database — managed Postgres, owned by the org rather than by an app. Creating one also creates the secret that carries its connection string.
Workflow — a graph of function calls the platform runs for you, with an HTTP endpoint of its own. Useful once a job outgrows a request handler; not something you need on day one.
Handbook — the markdown under docs/ in your project, rendered for your
users in the portal. Its subtitle is the line colleagues read in the
catalogue.
Function — an implementation a workflow node can call, provided by an execution server you run. Both are explained in the Workflows chapter, which is deliberately late.
What the platform gives every app, unasked
Worth knowing early, because it shapes what you don’t have to build:
- a URL, with TLS
- an optional login gate and access policy, enforced before your code runs —
and, once you turn it on, the signed-in user’s identity passed to your app
as
X-User-*headers - logs, without cluster access
- an LLM gateway your app can call with its Dibbla token instead of a provider key
- a place for the review that shipped with the deploy
The tour is a walk through those, one at a time.