Identity & Access
Every user belongs to one organization and has one role. The role decides what the user can do everywhere in Zenfra, and the same three roles apply to API keys.
Roles
| Role | The product's description |
|---|---|
| Read | Can view stacks and runs but cannot make changes |
| Write | Can trigger runs and modify stack configurations |
| Admin | Full access including user management and billing |
Roles are cumulative: Write includes Read, Admin includes Write. The invite dialog defaults to Read. The Settings > Account page shows the same roles as Viewer, Editor and Administrator.
What each role can do
| Role | Actions |
|---|---|
| Admin | Create stacks; update stack details (name, worker pool, IaC engine and version); delete stacks; reindex a stack's resources. Create, update and delete configuration bundles. Create, verify, update and remove source control integrations and VCS connectors, and enable or disable repositories. Browse the files of a connected repository through the API. Create, verify, update and remove cloud integrations, and attach or detach them from stacks. Create, edit, rotate the key of, and delete worker pools. Create API keys. Invite, remove and change the role of users. View the audit log. Create, update and delete drift schedules. Roll back Terraform state and release a state lock left behind. Force cancel a cancelled run. Create, edit, enable, disable, attach, detach and delete plan policies, and dry-run a draft. Change organization settings, including the MFA policy. |
| Write | Trigger runs; approve, discard and cancel them. Change a stack's source, automation triggers and variables. Attach and detach bundles on a stack and reorder them. Re-evaluate a run's policies. Create, update and delete spaces. |
| Read | View stacks, runs and their logs, resources, spaces, bundles, integrations, worker pools, plan policies and their attachments, a run's policy verdict and its policy input, the dashboard and their own API keys. Every member, whatever the role, manages their own MFA factors and can revoke API keys they created. |
A request beyond the role's level is refused (403, error code insufficient_role). In the app this shows as You don't have permission to perform this action.
Managing users
Navigate to Organization > Users. The list shows Name (display name and email), Role, Status (active, invited or inactive), Verified (whether the email address is verified) and Last Login. You can search users and filter by role.
The row menu offers:
- Edit Role: change the user's role.
- Remove: removes the user from the organization. You type their email to confirm. They lose access to all organization resources immediately, and must be re-invited to regain it.
Both are disabled for the only Admin in the organization (This is the only admin. You cannot change their role. / You cannot remove them.).
Inviting users
Click Invite User (Admin only), enter the email address and choose a role, then Send Invitation. The invitee receives a link to join your organization. Invitations expire after 7 days and appear under Pending Invitations with Email, Role, Status and Expires, where you can Resend or Revoke them.
Authentication
- Email and password. Sign-up creates the user and their organization. Forgot password sends a reset link by email.
- GitHub or GitLab: sign in or sign up with either account (
Or continue with). - Email verification: a verification link is sent by email; the Users page shows whether it was completed.
- Invitation acceptance: the invitation link asks for a name and password (
Accept your invitation).
The Settings > Account page shows your name, email, role and verification status; it does not edit them.
Multi-factor authentication
Settings > Security manages your own second factors:
- Authenticator app (TOTP): Set up walks through scanning the secret, entering a verification code and saving the recovery codes. Disable turns it off.
- Passkeys & security keys: Add new registers a passkey with a nickname; each passkey can be renamed or removed.
- Recovery codes: enrolling your first factor issues 10 one-time codes (
{n} of 10 codes remaining). Regenerate replaces them.
Sensitive changes ask you to confirm with your password or a recovery code first (Confirm it's you).
When a second factor is enrolled, sign-in adds a Two-factor authentication step with a tab for each method you have available: Authenticator, Passkey and Recovery code.
Organization policy
An Admin can require MFA for every member, with an enrollment grace period (default 7 days, 0 to 30) for members who have not enrolled yet. Such a member is sent to the enrollment page at sign-in (Your organization requires every member to enroll a second factor before signing in.), which shows the time left; after the deadline, sign-in is blocked until they enroll. An Admin can also reset a member's MFA, for example after a lost device: all their second factors are removed and they are notified by email. Both actions are done through the API today; the Organization settings page has no MFA controls yet.
Enabling and disabling MFA, sign-in verifications and admin resets are recorded in the audit log.