Members & roles

Every member of a workspace has exactly one role. Roles are workspace-scoped: a user can be admin in one workspace and guest in another.

The four roles

Role	Pipelines & builds	Secrets	Members	Repositories	API keys	Settings
owner	Trigger, cancel, manage	Read, write, rotate	Invite, change roles, remove anyone	Connect, configure, disconnect	Create; see & revoke all	Rename, delete, require 2FA
admin	Trigger, cancel, manage	Read, write, rotate	Invite & remove members and guests	Connect, configure, disconnect	Create; see & revoke all	View only: cannot change plan or delete
member	Trigger, cancel own builds	Use in builds (no read)	View list	Connect new repos, configure own	Create & revoke own	View only
guest	View, watch logs	None	View list	View list	Revoke own	View only

Every workspace has exactly one owner at any time. Ownership can be transferred but not duplicated.

The rules around changing roles

Loha enforces a strict hierarchy at the API level. These aren't just UI affordances:

• Only an owner can change another owner's role, including promoting a non-owner to owner. There is no co-owner role; promoting transfers ownership.
• Admins cannot demote, promote, or remove other admins. Only owners can. This stops a compromised admin account from cleaning house.
• No one can change their own role. Even the owner; ownership transfer happens via the dedicated transfer flow on the settings page.
• No one can remove themselves. There is no self-removal or "leave workspace" action. Ask another owner or admin to remove you.

If you try to perform a forbidden action (for example, an admin attempting to remove a peer admin), the API returns 403 Forbidden and the action is recorded in the audit log.

What happens when a member is removed

The moment a member is removed:

1. Their member row is deleted.
2. All of their sessions are invalidated: any open browser tab, dashboard, or live build view will fail on the next request and prompt re-auth.
3. Their workspace-scoped API keys are revoked: any CI integration or scripted access stops working immediately.
4. An audit-log entry records who removed whom, the previous role, and how many sessions and keys were revoked.

Removed members keep what they've already cloned

Revoking access stops them from triggering new builds, reading secrets, or seeing future activity. It does not retroactively reach into local clones, downloaded artifacts, or notes they've already taken. Rotate any secrets the removed member had access to. See Secrets management.

Inviting people instead of adding them directly

Loha doesn't expose "add this user directly": every new member arrives via an invitation, even when the user already has a Loha account. This keeps the audit trail honest: every membership has a recorded inviter.

Audit trail

Member-management actions write to the workspace audit log:

• invite_sent: when an invitation is created or re-sent (details.resend = true for re-sends).
• invite_accepted: when the invitee clicks accept.
• role_changed: when a member's role is updated. Both old and new role are recorded.
• member_removed: when a member is removed. Includes the role they had at the time and counts of sessions/API keys revoked.
• delete (resourceType invitation): when a pending invitation is revoked.

Audit entries are visible to owners and admins under Settings → Audit log. See the Audit log catalog for every event Loha emits.

PDPA Article 30

Membership events (invitations, role changes, removals) process personal data (names, emails). Loha records them with actor, timestamp, IP, and result to satisfy PDPA Article 30 (records of processing activities). The full retention, export, and sovereignty story is on the Audit log and Data sovereignty pages.