Publishing apps

Anyone can register an app. The gate is rollout, not creation — how a self-registered app goes from private to visible, and who approves it.

Atrium is a directory anyone in the org can add to. Registering an app is not an admin action — the gate sits one step later, at rollout.

The two-step model

The distinction that makes open registration safe:

Nothing about a freshly-registered app touches the wider org: it is invisible, it holds no identity project, and it grants nobody anything. That is why creation can be open — the blast radius is zero until someone approves it.

Registering

Three doors, same service and same rules:

• UI — /admin → Register app
• API — POST /api/apps/register with { id, name, description }
• MCP / agent — the register_app tool, so a coding agent can do it mid-flow

You get back the app, its owner row (you), a dev group, and — when the DNS connector is connected — an auto-claimed subdomain <slug>.atrium.<zone>.

The safe envelope is forced server-side, not left to the client: visibility is pinned to SECRET and syncZitadel to false regardless of what the caller sends. A client cannot register a discoverable app by passing extra fields.

Getting it published

Ask an app publisher. The role exists precisely so approvals are not stuck behind the handful of instance admins.

atrium:app_publisher is a real Zitadel role key, which means it can be granted via a group rather than person by person. Atrium is itself a registered app, so granting a group the atrium app with that role key gives the role to every member — and because groups can mirror the directory, approver rights track the org chart automatically.

The intended mapping at OMMAX is the existing dynamic directory group omx_leaders_all ("ALL Employees with Level 5-7"), so every leader is a publisher without anyone maintaining a list. See Groups for how a directory group is mirrored, and Members and RBAC for the full role table.

What a publisher can and cannot do

Deliberately a role, not a tier:

• Can — see the admin area, register apps, and flip visibility on any app
• Cannot — change an app's category or isPublicAccess, delete apps, remap Zitadel, or touch groups, secrets, scripts, members or API keys

Approving an app is not the same as changing what it is, and it is not the same as handing it to the whole org without a grant — isPublicAccess stays admin-only for that reason.

A publisher also does not inherit owner rights on the app they approve. They pass the permission gate on publishing rights alone, so they cannot rewrite someone else's app description while approving it.

Note: the role must exist on the Zitadel Atrium project before it can be granted. Creating it is a one-time admin step; after that, assignment is group-based.