Decide who can open it
A login gate and one of three access policies, set per app from the console — and the denial page the proxy serves to everyone else.
By default your app is open: anyone with the URL can load it. That is right for a status page and wrong for almost everything else you will build internally. Fixing it takes two decisions and no code.
The two decisions
Open the app card’s ⋮ menu and choose Access & users.
The first decision is whether login is required at all. The second — which only appears once login is on — is the policy:
| Policy | Who gets in |
|---|---|
| All organization members | anyone in your Dibbla organisation |
| Invite only | only people you grant access to, one by one |
| Email domain | anyone whose e-mail matches a domain you list — no membership needed |
Email domain is the one worth knowing about: it lets you share an internal tool with a client or a contractor without adding them to your organisation.
Every change in this dialog is saved as you make it. The one exception is choosing Email domain with no domains listed — that refuses, and tells you why, rather than silently locking everyone out.
What everyone else sees
Someone who fails the policy does not get a broken page or a raw 403. The proxy serves them a branded refusal on the app’s own host:
It names the app, shows who they are currently signed in as, and offers Sign out and try a different account — which is the actual fix most of the time, since the usual cause is being signed into the wrong account.
Setting it at deploy time
The same two fields are flags, so an app can ship locked from its very first deploy rather than being public for the minutes it takes you to click:
$dibbla deploy . --alias my-first-app -m "feat: initial deploy" --require-login --access-policy invite_only --access-policy accepts all_members and invite_only. Email domain is
set in the console, because it needs the domain list alongside it. Note
also that the flag is a bare boolean on dibbla deploy but takes a value on
dibbla apps update (--require-login true).
Have a code agent lock down an app you already deployed.
The Dibbla app "my-first-app" is currently public. Make it require login and
restrict it to members of my organisation, using the dibbla CLI. Tell me what
the app's access policy was before you changed it.A note on what this is not
This gate controls who can open the app. It is not authorization inside your
app: once someone is through, your code decides what they may do. What your app
receives is a set of X-User-* headers describing the authenticated person —
enough to build roles on, without implementing login yourself.