Summary and recommendation
SonarQube user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
SonarQube's user management lives at Administration > Security > Users.
Permissions are not role-based in the traditional sense - discrete permission flags are granted directly to users or groups at either the global (instance-wide) or project level.
Permission templates let you auto-apply a standard set of project permissions to new projects, which is the closest SonarQube gets to bulk role assignment.
Quick facts
| Admin console path | Administration > Security > Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise Edition |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| System Administrator | Full access to all global and project-level settings, user management, permission management, system configuration, and all project data. | All editions (Community and above) | Counts as a user; no separate admin seat cost documented. | The built-in 'admin' account cannot be deactivated while it is the only active administrator. | |
| Global Permission Holder (non-admin) | Can hold one or more global permissions: Administer Quality Profiles, Administer Quality Gates, Create Projects, Create Applications, Create Portfolios, Execute Analysis, Administer System (grants admin). | Cannot access areas outside their granted global permissions. | Applications require Developer Edition or above; Portfolios require Enterprise Edition or above. | Standard user seat. | 'Create Applications' and 'Create Portfolios' global permissions only appear in editions that support those features. |
| Project-level User | Can hold project permissions: Browse, See Source Code, Administer Issues, Administer Security Hotspots, Administer Project, Execute Analysis. Permissions can be granted directly or via groups. | Cannot access global administration or other projects unless explicitly granted. | All editions | Standard user seat. | By default, new projects may grant 'Anyone' group browse access; this must be explicitly restricted for private projects. |
| Member of 'Anyone' group | Implicit group all authenticated and unauthenticated users belong to. Can be granted project-level permissions. | Cannot be managed or removed; it is a system-level implicit group. | All editions | No separate seat cost. | Granting permissions to 'Anyone' effectively makes content public. Force authentication setting removes unauthenticated access. |
Permission model
- Model type: hybrid
- Description: SonarQube uses a combination of global permissions (instance-wide capabilities) and project-level permissions (per-project access). Permissions are assigned to individual users or to groups. There are no named roles in the traditional RBAC sense; instead, discrete permission flags are granted directly. Permission templates can be created to auto-apply a standard set of project permissions to new projects.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Per-permission flag at both global and per-project level. Permission templates allow bulk application of project permission sets.
How to add users
- Log in as a user with 'Administer System' global permission.
- Navigate to Administration > Security > Users.
- Click 'Create User'.
- Enter Login (username), Name, Email, and optionally an initial Password.
- Click 'Create' to save the new local user.
- Optionally assign the user to one or more Groups via the Groups column on the Users list.
- Optionally grant global permissions via Administration > Security > Global Permissions.
- Optionally grant project permissions via the specific project's Administration > Permissions page.
Required fields: Login (unique identifier), Name, Password (for local accounts; not required for SSO/LDAP-provisioned users)
Watch out for:
- Login must be unique and cannot be changed after creation.
- Users provisioned via LDAP or SAML are created automatically on first login; manual creation is not required for those authentication methods.
- SCIM provisioning (Enterprise Edition + SSO) can push users from an IdP before first login.
- Email field is not mandatory in the UI but is required for certain notification features.
- Local users and externally authenticated users coexist; the authentication source is recorded per user.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | SCIM provisioning requires Enterprise Edition and an SSO (SAML) configuration. LDAP auto-provisioning on first login is available in all editions. |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: SonarQube does not permanently delete users through the UI. Instead, users are deactivated (disabled). A deactivated user cannot log in but their account record and associated data (issues assigned, comments, audit history) are retained. The official documentation describes only a 'Deactivate' action, not a hard delete. When SCIM is enabled, removing a user from the IdP triggers deactivation in SonarQube, not deletion.
- Log in as a user with 'Administer System' global permission.
- Navigate to Administration > Security > Users.
- Locate the user in the list.
- Click the user's action menu (three-dot or gear icon) and select 'Deactivate'.
- Confirm the deactivation prompt.
| Data impact | Behavior |
|---|---|
| Owned records | Issues and security hotspots previously assigned to the deactivated user retain the assignment but the user is marked inactive. Historical data is preserved. |
| Shared content | Comments and quality gate/profile changes authored by the user remain visible in the audit trail. |
| Integrations | Tokens generated by the deactivated user are revoked upon deactivation, breaking any CI/CD pipelines or integrations using those tokens. |
| License freed | Deactivating a user frees their seat; the user no longer counts toward active user metrics. |
Watch out for:
- User tokens (API tokens) associated with the deactivated user are immediately revoked; any automation using those tokens will fail.
- A deactivated user's login name is still reserved and cannot be reused for a new account.
- The built-in 'admin' account cannot be deactivated if it is the sole active system administrator.
- When SCIM is active, deprovisioning from the IdP automatically deactivates the user in SonarQube; manual deactivation is still possible as a fallback.
- Reactivating a deactivated user restores their account and group memberships but does not restore revoked tokens.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Lines of Code (LOC) based license | SonarQube is licensed per instance per year based on the total lines of code analyzed, not per named user seat. All users within the instance are included under the LOC license. | Varies by edition and LOC tier. Example: Developer Edition ~$2,500/year at 500K LOC; Enterprise Edition ~$35,700/year at 5M LOC (before discounts). |
- Where to check usage: Administration > Configuration > License Manager (Enterprise Edition and above) or Administration > System for edition/LOC details.
- How to identify unused seats: Navigate to Administration > Security > Users and filter by 'Last Connection' date to identify users who have not logged in recently. No built-in 'unused seat' report exists since licensing is LOC-based, not per-seat.
- Billing notes: SonarQube Server is priced per instance per year based on lines of code analyzed, not per user. Adding or removing users does not directly change the license cost. The license tier must be upgraded if analyzed LOC exceeds the current tier limit. Enterprise discounts of 39–46% are available. SonarQube Cloud (formerly SonarCloud) uses a separate per-LOC subscription model.
The cost of manual management
SonarQube is licensed per instance per year based on lines of code analyzed, not per named user seat. Adding or removing users does not directly change your license cost - the tier only needs to change if analyzed LOC exceeds the current limit.
SCIM provisioning, which automates user lifecycle across every app connected to your IdP, is gated behind Enterprise Edition; teams on Community or Developer Edition must manage users entirely by hand or rely on LDAP/SAML first-login provisioning. There is no bulk CSV import for users, so large-scale manual provisioning requires scripting against the Web API.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management is workable for small, stable teams where user churn is low and every app in the stack does not need to stay in sync with a central directory.
Once your team grows or you need consistent deprovisioning across tools, the lack of hard-delete, the token-revocation side effect, and the absence of bulk import become compounding operational risks.
If your instance is on Enterprise Edition and you already have SAML or OIDC configured, enabling SCIM is the cleaner path - it pushes provisioning and deprovisioning events from your IdP automatically. For everyone else, the Web API is the only route to automation.
Bottom line
SonarQube's manual user management is functional but carries real operational overhead: no hard-delete, no bulk import, permanent login reservation on deactivation, and silent token revocation that can break automation.
For teams where every app needs to reflect accurate, up-to-date membership, manual processes introduce lag and risk. SCIM on Enterprise Edition resolves the lifecycle problem at the IdP layer;
below that tier, the Web API is the only lever for automation.
Automate SonarQube workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
