Organizations & roles
Team workspaces, member roles, invitations and the audit trail behind them.
Everything in Relayer - apps, releases, API keys, devices, the audit log - belongs to an organization, not a personal account. You get a personal organization at signup; create more from the switcher in the sidebar and move between them freely.
Roles
| Capability | Owner | Admin | Member |
|---|---|---|---|
| View apps, fleet, releases, audit log | ✓ | ✓ | ✓ |
| Publish releases, change rollouts, pause/rollback | ✓ | ✓ | - |
| Create/rename apps, manage channels & policies | ✓ | ✓ | - |
| Mint & revoke API keys | ✓ | ✓ | - |
| Invite/remove members, change roles | ✓ | ✓ | - |
| Rename organization | ✓ | ✓ | - |
| Delete apps | ✓ | - | - |
Members are read-only: they can watch a rollout, they can't touch it.
Mutations attempted without the required role fail with 403 - including
through the API.
Invitations
Invite from Organization → Members. Two paths, same invitation:
- Email - the invitee gets a link (when email sending is configured).
- Copy link - every pending invitation has a copyable URL you can drop into Slack or a ticket.
The link carries the invitee through the whole flow: if they're signed out they can sign up or log in on the spot (email prefilled), and the invitation is accepted automatically at the end - accepting also switches their active organization to the one that invited them. If they're signed in with a different email than the invitation was addressed to, they're offered an account switch instead of a silent failure.
Invitations expire, can be revoked while pending, and every step - invite sent, accepted, revoked, member removed, role changed - lands in the audit log with the acting user.
API keys are org-scoped
A key minted in an organization sees exactly that organization's apps - nothing else. Keys act with publish-level permissions and every action they take is audited under the key's name, so a CI key can publish releases but its whole history is one filter away.