Skip to main content
Esta página ainda está em inglês. A tradução para português está em andamento.

​
Users and Roles

EvoNexus uses a role-based access control (RBAC) system. Every user has exactly one role, and each role defines what resources the user can access and what actions they can perform.

​
Default Roles

Three built-in roles ship with every installation: Built-in roles cannot be deleted, but you can create custom roles with any permission combination.

​
Permission Comparison

​
Creating Users

​
Via the Dashboard

  1. Navigate to Users in the sidebar (requires users:manage permission)
  2. Click Add User
  3. Fill in:
    • Username (unique, used for login)
    • Email (optional)
    • Display name (shown in the UI)
    • Password (minimum 8 characters, hashed with bcrypt)
    • Role (select from available roles)
  4. Click Create
The new user can immediately log in at the dashboard URL. User Management

​
First User (Setup Wizard)

The very first user is created during the setup wizard when the dashboard starts with an empty database. This user is always assigned the admin role.

​
Custom Roles

​
Creating a Custom Role

  1. Go to Roles in the sidebar
  2. Click Create Role
  3. Enter a name and description
  4. Use the permission matrix to toggle actions per resource
  5. Click Save
Roles permission matrix

​
Permission Matrix

Each cell in the matrix is a resource + action combination: Resources (16 total): chat, services, systems, integrations, reports, agents, memory, skills, costs, config, users, audit, files, templates, routines, scheduler Actions (3 types):
  • view — read data, see pages
  • execute — run routines, use chat, start/stop services
  • manage — create, update, delete (users, config, memory files)
Not all resources support all actions. For example, audit only supports view, and templates only supports view.

​
Example: “Finance Viewer” Role

A role that can only see financial reports and costs:

​
Example: “Community Manager” Role

A role that can run community routines and view reports:

​
How Permissions Are Enforced

Every API endpoint checks permissions using the has_permission(role, resource, action) function. If the current user’s role does not include the required permission, the API returns 403 Forbidden. The frontend also uses permissions to conditionally render sidebar items and action buttons — if you lack users:view, the Users page does not appear in the navigation.

​
Audit Trail

All user-related actions are logged to the audit trail:
  • User creation and updates
  • Role changes
  • Login attempts (successful and failed)
  • Config changes (including .env edits)
View the full audit log at Audit Log in the sidebar (requires audit:view).