Granular admin permissions via RBAC

Administration on Sourcegraph has historically been an all-or-nothing decision: either a user was an administrator and could do everything, or they weren't and couldn't access any admin surface. We've replaced this with a set of fine-grained RBAC permissions that map onto distinct admin responsibilities. Now you can grant users exactly the access they need and nothing more.

Eight new permission namespaces are available in the role editor (Site admin → Users & auth → Roles), each grantable independently to any role.

• Repository management — add, modify, and delete repositories and code host connections; view repository statistics, mirror state, and recorded git commands; trigger reindex, reclone, optimize, and disk-cleanup operations.
• User management — create, modify, and delete users, organizations, and roles; manage access requests; view survey responses and pending permissions.
• Access tokens — list access tokens across the instance, create tokens on behalf of other users, and create site-admin:sudo-scoped tokens.
• Advanced configuration — view and edit site configuration, auth providers, SMTP, and other instance-level settings.
• Integration management — view and configure integrations such as Slack and outbound webhooks.
• Notifications — view, dismiss, and create administrator notifications, and send test emails from the instance.
• Out-of-band migrations — view and modify the direction of out-of-band database migrations.
• Entitlements — create, update, and delete entitlements and manage user grants.

Each namespace exposes READ and WRITE actions (where applicable) so that you can give someone visibility into an admin surface without granting them the ability to change it.

Several of these are flagged as high-trust permissions in the role editor — for example, ADVANCED_CONFIG#WRITE, USER_MANAGEMENT#WRITE, ACCESS_TOKENS#WRITE, NOTIFICATIONS#WRITE, OOB_MIGRATIONS#WRITE, INTEGRATION_MANAGEMENT#WRITE, and REPO_MANAGEMENT#READ — because the capability they grant is effectively equivalent to administrator access for that area of the product. Treat them accordingly when assigning roles.

How it works

Administrators continue to receive every permission by default, so existing deployments behave exactly as they did before the change. New permissions added by an upgrade are granted to the built-in SITE_ADMINISTRATOR role automatically, and a small set of grandfathering rules ensure that newly restrictive permissions don't break workflows on older installs.

To delegate admin capabilities, create or edit a role and check the permissions for the relevant namespace. Users assigned that role will gain access to exactly the admin endpoints those permissions cover — and nothing else.

Example roles

Here are a few roles that may be useful for your Sourcegraph instance:

• Repository operator — REPO_MANAGEMENT#READ, REPO_MANAGEMENT#WRITE. Can connect code hosts, add/remove repositories, inspect mirror state, and trigger reclone/reindex operations without seeing user data or site configuration.
• Support engineer — USER_MANAGEMENT#READ, REPO_MANAGEMENT#READ, NOTIFICATIONS#READ. Read-only access to the surfaces needed to triage customer tickets without the ability to change anything.
• Identity admin — USER_MANAGEMENT#READ, USER_MANAGEMENT#WRITE, ACCESS_TOKENS#READ. Owns user, org, and access-request lifecycle; can audit access tokens but cannot mint sudo tokens.
• Integrations owner — INTEGRATION_MANAGEMENT#READ, INTEGRATION_MANAGEMENT#WRITE, NOTIFICATIONS#WRITE. Manages outbound webhooks, Slack, and operational notifications for the instance.
• Release/migrations engineer — OOB_MIGRATIONS#READ, OOB_MIGRATIONS#WRITE, ADVANCED_CONFIG#READ. Can drive out-of-band migrations during upgrades and inspect site configuration without modifying it.
• Billing/entitlements admin — ENTITLEMENTS#READ, ENTITLEMENTS#WRITE, USER_MANAGEMENT#READ. Manages entitlements and user grants without broader admin reach.
• Read-only auditor — every #READ permission and no #WRITE. Useful for compliance reviewers who need full visibility into the admin surface without any ability to make changes.