documentation
04 admin

Users & teams

Exolvra supports multi-user, multi-team deployments. This page covers the role hierarchy, how to create and manage users, and how teams shape the visibility boundaries between groups of people sharing the same instance.

What this page is for

The Users & Teams admin area is where you decide who can do what on an Exolvra instance. In a personal single-user install you can ignore it — the bootstrap admin is the only identity. In any deployment with more than one human, it’s where you onboard, assign permissions, and draw the lines between different working groups.

The role hierarchy

Exolvra has three roles. They form a strict hierarchy: every capability granted to a lower role is also available to higher roles.

RoleCan do
OwnerEverything. Only one per instance. Can delete the instance itself and transfer ownership. Usually the person who deployed it.
AdminEverything except delete-instance. Can create/delete users, approve skills, configure providers, set budgets, read the audit log, access the admin pages.
MemberUse the dashboard normally: chat, create projects, run agents, manage bots they created, view their own activity. Cannot access admin pages, approve skills, or read other users’ sessions.

Role names are fixed — you can’t create custom roles. If you need finer-grained permissions, that’s what session-scoped grants and per-agent tool restrictions are for.

Common tasks

Create a new user

  1. Open /admin/users from the sidebar (or the admin menu)
  2. Click New user
  3. Fill in email, display name, and role
  4. Choose whether Exolvra sends an invite email or you provide the temporary password yourself
  5. Save

The user is prompted to set their own password on first login. If email isn’t configured, you’ll need to send them the temporary password out-of-band.

Change a user’s role

Open the user detail page from the user list. Click Edit and pick the new role from the dropdown. Save. The change takes effect on the user’s next request — if they’re mid-session, their tab refreshes and the new role applies immediately.

Promoting to Admin gives full admin access. Demoting from Admin to Member removes that access immediately — open admin pages become forbidden on the next click.

Deactivate a user

Open the user detail page and click Deactivate. The user can no longer sign in, but their identity, contributions, and session history all remain intact. Reactivate from the same page at any time.

Use deactivation instead of deletion when someone leaves but you want to preserve their history for audit or attribution purposes.

Reset a user’s password

From the user detail page, click Reset password. Two options:

  • Send reset email — if email is configured, the user gets a link
  • Generate temporary password — admin receives a one-time password to share out-of-band

Either way, the user’s old password is invalidated immediately. They’re signed out of every device.

Delete a user

From the user detail page, click Delete. Confirm. Deletion is permanent and unlike deactivation it removes the user record, with these side effects:

  • Sessions owned by the user remain but are attributed to a “deleted user” placeholder
  • Projects they owned stay in the project list; ownership transfers to the current admin
  • Audit log entries are preserved with the original username (the audit log is immutable)

Delete is reserved for cases where you have a compliance reason to erase the identity — for most ex-users, deactivate is the right call.

Teams

Teams group users together for scoping and visibility. A team is a namespace — projects can be attached to a team, and team membership decides who sees what.

The key rules:

  • Users can belong to any number of teams
  • Projects belong to exactly one team (or no team — “personal” projects are visible only to their creator and admins)
  • A user sees projects that belong to any team they’re a member of
  • Admins see everything regardless of team membership

Create a team from /admin/teams → New team. Give it a name and description. Add members from the team detail page by picking from the user list.

Team-scoped budgets

Each team can have its own budget cap, separate from the instance-wide cap. Use this when different teams share the instance but should have different cost ceilings — for example, a paid-tier Research team and a free-tier Marketing team.

Moving a project between teams

Open the project edit page (in /projects), change the team dropdown, save. The project immediately stops being visible to users of the old team and becomes visible to users of the new team. In-flight agent work continues unaffected.

Common pitfalls

Not creating a second admin. If you’re the only Owner/Admin and you lose your access, nobody can recover the instance without direct database access. Always create at least one backup Admin.

Giving everyone Admin because “it’s easier”. Admin is a lot of power — including the ability to read every session and delete every project. Grant it only to people who need it.

Forgetting that Members can still create their own projects. A Member user can create projects, assign agents, chat, and consume budget. If you want to restrict a user to pure consumption (chat-only, no new projects), that’s not currently a role setting — consider whether they belong in a shared chatbot instead.

Where to go next