RBAC (Role-based Access Control)

RBAC is available with Pro and Custom plans. On a different plan and want access? Contact sales to upgrade.

Role-based Access Control allows you to build custom user roles and assign granular workspace-level permissions for your team members. Use Xano’s RBAC feature to ensure team members only have access to and can only take action on the things that should be available to them.

Create roles

Define custom roles with the right level of access for each kind of team member.

Assign to team members

Apply a role when inviting a user, or adjust per-workspace permissions later.

Bulk operations

Copy/paste permissions between users and apply roles or changes to many at once.

Permissions reference

What each permission unlocks across the instance, workspace, and tenant center.

Accessing RBAC

From the instance selection screen, click the icon and choose Permissions (RBAC).

The Permissions Center

Xano offers five pre-defined user roles as described in the table below.

Role	Intended use	Access summary	Key limitations
Admin	Full administrative access across the instance, workspace, releases, tenant center, and tenant cluster.	Full access to workspace resources, release management, tenant center, backups, secrets, tenant cluster, RBAC, logs, deploy, impersonation, metadata API, exports, run/debug, and marketplace/connect features.	None in the predefined matrix.
Developer	Build and manage workspace functionality without full tenant/security administration.	Full access to most workspace resources, including database, content, APIs, functions, tasks, services, middleware, files, logs, settings, release, tenant center, backups, deploy, impersonation, metadata API, marketplace/connect, export, and run/debug.	Cannot manage Tenant Center RBAC, Tenant Center Secrets, Tenant Cluster, Tenant Cluster Secrets, or debug from request history.
Readonly	Review configuration, data, logs, and release/tenant information without making changes.	Read access to most workspace resources, release, tenant center, and tenant center logs.	Cannot create, edit, export, run/debug, use marketplace/connect, manage RBAC, deploy, impersonate, access secrets, backups, metadata API, or tenant cluster resources.
Billing	Limited access for billing or account-level visibility.	Read access to the instance workspace only.	No access to workspace resources, releases, tenant center, tenant cluster, logs, exports, run/debug, or feature actions.
Suspended	Temporarily or permanently block a user’s access.	No access.	All permissions are disabled.

Creating roles

In the Roles tab, click Add new custom role Give the new role a name, and click Add Custom Role You’ll see your new role appear in the list of roles below the Xano defined options.

A new role comes with all permissions enabled by default.

Click on a permission to adjust it for that role. There are four levels of access for each permission: Create (C), Read (R), Update (U), and Delete (D). Some, depending on context of the permission, will only offer Enabled or Disabled. There are also - and + options to quickly add or remove all permissions for that feature.

Active users inside the Instance won’t be immediately impacted by changes to permissions. They will have to leave the Instance and re-enter for changes to take effect.

Assigning roles

You can assign a role to a user when inviting them to your instance.

If they are already a member of your instance, you’ll see them listed under each workspace in the Workspace tab of the Permissions Center, and you can granularly adjust their permissions for each workspace. You can also filter the Workspace tab by team member and workspace to focus on one person’s access across the instance, or to see who has access to a specific workspace. To change a user’s role after they’ve already been invited, click the next to your instance on the instance selection screen and choose Manage Team.

Adjusting permissions

Click on a permission to adjust it for that user. There are four levels of access for each permission: Create (C), Read (R), Update (U), and Delete (D). Some, depending on context of the permission, will only offer Enabled or Disabled. There are also - and + options to quickly add or remove all permissions for that feature — turning everything on is sometimes referred to as Full access. When adjusting permissions for a user on a specific workspace, you’ll also see an Inherit option, which means that permission will obey what’s defined by the assigned role.

Inherit example: If you set Jane’s Run & Debug permission on Workspace A to Inherit, and Jane’s assigned role is Developer, then Jane’s Run & Debug access on Workspace A will match whatever the Developer role allows for Run & Debug. Change the role later and Jane’s inherited permissions follow automatically.

Bulk operations

You can manage permissions for many users at once from the Workspace tab of the Permissions Center.

Copy/paste permissions

Use Copy/Paste Permissions to quickly give one team member the same permissions as another — useful when several team members need identical access across each workspace. Click the Copy/Paste button, choose the team member to copy permissions from, then choose the team member to paste permissions to.

Bulk role assignment

Click the three dots above the roles list to open the bulk menu. Choose Managing Team Roles, select the role you want to apply, then select the users to apply it to. The role is applied to every selected user at once.

Bulk permission editing

From the same three-dot menu, choose Bulk Editing Permissions. Select the users you want to modify, then select the workspaces those changes should apply to. Adjust permissions as needed — any row left as Unmodified is skipped, so you only change what you explicitly set.

Permissions explained

Below, you’ll find a rundown of each permission and exactly what it changes for that user. Expand any permission to see its details.

Workspace & data

Workspace

The master gate for the entire workspace. Without Read, a user cannot see or enter any workspace at all.Related docs: Workspace Settings

Level	Controls
Read	Whether workspaces appear in the workspace list and selector.
Create	The “Create Workspace” button on the workspace list page. Also required to deploy a Release back into a workspace as a new branch.
Update	Renaming a workspace, changing its description, toggling and configuring Swagger docs, and changing push preferences. Also required to import a workspace via the metadata API.
Delete	Deleting a workspace — permanently destroys the workspace and all of its schemas, APIs, functions, tasks, middleware, files, and data. Blocked if any tenants are still active.

Importing a workspace export via the Metadata API requires Update, not Create. A user who can create new workspaces but lacks Update cannot restore from a file.

Database

Schema-level operations on database tables.

Level	Controls
Read	Visibility of the Database section
Create	Adding new tables and columns (manually or via the AI assistant).
Update	Modifying existing tables — renaming columns, changing types, editing relationships, adjusting indexes. Required to save any schema change.
Delete	Deleting tables and removing columns.

Does not affect data records inside tables.

Database Content

Read/write access to actual data inside database tables.

Level	Controls
Read	Viewing table records; required to export data.
Create	Adding new rows; importing records.
Update	Editing cell values, pasting into cells, bulk-update operations.
Delete	Deleting individual rows, bulk row deletion, table truncation.

Live Datasource

A secondary check that limits data operations specifically when the user’s active datasource is the live/production branch. Always checked alongside Database Content — both must allow the action.Related docs: Data SourcesIt uses the same C/R/U/D shape as Database Content, but applies only when the live datasource is selected. This lets you grant a user full edit access on staging while preventing any writes against production.

Files

File storage — the workspace’s vault of uploaded files (images, attachments, documents).Related docs: File Storage in XanoStandard C/R/U/D on files and access to the file manager.

Build & logic

API Endpoints

Level	Controls
Read	Visibility of the APIs section, API groups, and individual endpoints.
Create	Adding new API endpoints (from the editor, the AI assistant, the clone panel, or the quick-create modal).
Update	Editing endpoint logic, settings, inputs, and outputs.
Delete	Removing endpoints and API groups.

Functions

Reusable custom functions across the workspace.Related docs: Custom FunctionsStandard C/R/U/D on functions. Adding a function from inside the process stack requires Create.

Tasks

Scheduled background tasks.Related docs: Background TasksStandard C/R/U/D on tasks and access to the Tasks section.

Middleware

Request/response middleware — pre- and post-processing logic that wraps API endpoints.Related docs: MiddlewareStandard C/R/U/D on middleware definitions and access to the Middleware section. Read is also required for middleware to appear in the workspace settings modal’s Middleware Defaults section.

Addons

Addons — enrich database operations with data from related tables.Related docs: AddonsStandard C/R/U/D on addon definitions and access to the Addons section.

Services

Shared Services

Level	Controls
Read	Visibility of the Services section.
Create	Creating new shared services.
Update	Editing services; saving changes to shared services.
Delete	Removing shared services.

AI Tools

AI Tools for AI Agents and MCP servers built in XanoRelated docs: MCP Builder · AI Agents

Level	Controls
Read	Visibility of the AI Tools sections.
Create	Adding new tools
Update	Editing tool configuration; renaming.
Delete	Removing tools

Realtime

Realtime channels and settingsRelated docs: Realtime in Xano

Level	Controls
Read	Visibility of realtime channels.
Create	Adding new realtime channels.
Update	Editing channel configuration.
Delete	Removing channels.

Workflow Tests

End-to-end workflow testing — automated test scenarios for APIs, functions, and other logic.Related docs: Test SuitesStandard C/R/U/D on workflow tests. Test execution itself reuses the Functions permission.

Run & debug

Run & Debug

The “Run & Debug” panel that executes any workflow from inside of Xano.When Enabled, the user sees the “Run & Debug” button on every editable workflow — APIs, custom functions, tasks, middleware, workspace triggers, addon functions, and workflow tests — and can launch it. When Disabled, the button and the keyboard shortcut are hidden, all inputs in the panel are locked, and execution is impossible from any surface.

Read-only access to view code is unaffected. This permission only governs execution.Does not distinguish between branches — a user with this permission on a live branch can run against production data unless also restricted by Live Datasource.

Request History

The Request History feature — a captured log of API requests that can be replayed and inspected.Related docs: Request History

Level	Controls
Read	Visibility of request history; loading the dashboard’s history widget; required for the toolset page’s history playback feature.
Update	Changing request history retention settings; enabling history playback in the toolset page.
Delete	Clearing request history.

Run Debug from Request History

The “Activate Debugger” button inside the Request History panel — replays a captured request through the Run & Debug panel.Related docs: Request History · Testing and Debugging Function StacksWhen Enabled, clicking a request history item shows an “Activate Debugger” button. Clicking it pre-populates the Run & Debug panel with that request’s captured inputs and (for non-tenant sessions) re-executes against current code; for tenant impersonation sessions, it shows the historical result read-only. A confirmation prompt appears before re-running against a live branch or production datasource.

Important nuance: The replay always runs against current code, not the historical snapshot. Historical inputs combined with current logic can yield different results than the original captured request.This is separate from Run & Debug — a user could theoretically have one without the other (unusual but possible).

Settings & integrations

Workspace Settings

Access to the Workspace Settings modal and all of its sub-panels — a multi-section configuration surface covering most workspace-level preferences.Related docs: Workspace Settings · Environment Variables · Git Sync

Level	Controls
Read	Opening the Workspace Settings modal at all. The “Settings” sidebar nav item is hidden without it.
Create	Adding new Workspace Triggers and Processing Jobs.
Update	Saving changes to any of the following sections: General (name, description, Swagger, doc token, AI settings); Branch Defaults (request history retention); Environment Variables; Git Sync (GitHub repo for XanoScript backup); Middleware Defaults (workspace-wide middleware); Realtime configuration; Database Preferences (table format, custom SQL names, PK type); Xano Link (cross-workspace API distribution). Also required to save the Database Connector configuration (in the “Connect” modal, despite the name) and to delete a workspace. Also gates the Environment Variables and Unit Tests pages.
Delete	Removing a Git Sync connection.

Big surface area. This permission spans 10+ distinct sub-features. The most common ones to call out are env vars, Git Sync, and realtime config.The Database Connector lives under “Connect,” not “Settings,” but is still gated by Workspace Settings Update — an easy point of confusion.

Compliance Log

The workspace’s audit/compliance log — a record of administrative actions taken in the workspace (separate from request traffic logs).Related docs: Audit LogsStandard C/R/U/D on the log. Read is required to view the log list.

Not request logs. This is the audit trail (who did what), not the captured-request log. Request traffic lives under Request History.

Workspace Export

Workspace export operations — both schema/logic exports and data exports.Related docs: Export & SharingWhen Enabled, the user can run two distinct exports from inside the Workspace Settings modal:

XanoScript MultiDoc Export — exports the workspace as a XanoScript document containing schemas, logic (functions/queries/tasks/middleware/etc.), env vars, records, drafts, workflow tests, actions, and triggers (each toggleable). Useful for version control and migration.
Data Export — exports database records (and optionally hosted files) as a downloadable archive. Runs in the background; you will receive an email with a 12-hour download link when complete.

When Disabled, both export buttons are hidden/disabled.

Sensitive content warning: The MultiDoc export can include environment variable values (these often contain API keys and other secrets). Document this if exposing the feature to users with low trust.

Marketplace

The Marketplace, where users can install Xano-provided workspace templates.Related docs: MarketplaceWhen Enabled, the Marketplace nav item appears in the workspace sidebar and Marketplace pages are accessible. However, you will still need to enable the Marketplace inside of the workspace along with this permission. When Disabled, the entire Marketplace feature is hidden.

Connect

Third-party platform integrations with specific Connect statements (e.g. Webflow). This does not impact access to the External Database Query functions.Related docs: ConnectWhen Enabled, the user can save and manage Connect integration configurations. When Disabled, the Connect modal’s actions are blocked.

Releases & Tenant Center

Releases

Releases — named, versioned snapshots of a workspace branch that can be deployed to tenant environments. This permission is enforced for Metadata API access (used by CI/CD pipelines and the Xano MCP server). The Tenant Center’s release-deploy flow uses Tenant Center Deploy instead.Related docs: Branching & Merging · Xano CLI Releases

Level	Controls
Read	List releases; get release details; export a release as a XanoScript MultiDoc; get a signed download URL for the release archive.
Create	Create a release from a named branch; create a release from a MultiDoc upload; import a `.tar.gz` release archive; deploy a release back into a workspace as a new branch.
Update	Rename or update the description of an existing release.
Delete	Permanently delete a release.

Tenant Center

The master gate for the Tenant Center — the workspace-level interface for managing isolated tenant environments (each tenant has its own database and receives logic from releases).Related docs: Tenant Center

Level	Controls
Read	Whether the Tenant Center nav item appears at all, and which individual tenants are visible (Read can be granted per-tenant via overrides). Without it, the user sees an upsell page instead.
Create	The “Add Tenant” button — provisioning a new tenant environment.
Update	Editing tenant properties: display name, description, custom domain, RBAC toggle, task and ingress toggles.
Delete	The per-row “Delete” action — permanently destroys a tenant and its infrastructure.

The Tenant Center is also subject to a plan/feature gate checked separately from RBAC: the instance must have at least one tenant slot allocated. Both must pass for the UI to show.

Tenant Center RBAC

Manages the tenant’s own role-based access control — distinct from the top-level workspace RBAC. Governs which roles, permissions, and team members exist inside RBAC-enabled tenants.Related docs: Tenant CenterWhen Enabled, you’ll see the “RBAC” / “Manage Members” button in the Tenant Center header and can open the tenant-RBAC management panel to view and edit roles, permissions, and member assignments for tenants that have RBAC turned on. When Disabled, the button is hidden and the panel is read-only or inaccessible.

Tenant Center Logs

The Tenant Center audit log — a structured record of administrative actions performed against tenants (creation, deletion, deployment, impersonation, license views, env var changes, backups, etc.).Related docs: Tenant Center · Audit LogsWhen Enabled, the user sees the “Audit Logs” button in the Tenant Center header (showing logs across all tenants) and a “Logs” action in each tenant’s row menu (showing logs for that one tenant).

These are audit logs, not request/traffic logs. They record administrative events, not API request data. API traffic is in Request History.

Tenant Center Backups

Backup operations for tenant environments — full snapshots of tenant data that can be restored later.Related docs: Tenant Center · Backup & Restore

Level	Controls
Read	Listing backups; downloading a backup archive.
Create	Creating a new backup; importing a backup file.
Update	Restoring a tenant from a backup (replaces all current tenant data); importing backup files.
Delete	Deleting backup archives.

The Restore operation maps to Update, not Create.

Tenant Center Deploy

A multi-purpose permission covering four distinct deployment-related actions in the Tenant Center.Related docs: Enterprise Deployment · Resource ManagementWhen Enabled, the user can access:

Deploy Release — push a versioned logic release to one or more tenants in bulk. Available for all tenants. Diff viewing is supported before confirming.
Deploy Platform — tier2/tier3 only. Migrate a tenant from one infrastructure platform to another (used during Xano-managed platform upgrades).
Manage Resources — tier2/tier3 only. Configure compute resources for a tenant: CPU/RAM per deployment, replica counts, node affinity, toleration effects, storage settings.
Infrastructure — tier2/tier3 only. View the live infrastructure state of a tenant: pods, deployments, services, storage volumes, ingresses, jobs. Read-only monitoring view.

Also gates the top-level “Releases” panel in the Tenant Center header.

Easy to confuse: Deploy Release pushes application logic; Deploy Platform moves the underlying Xano version. They are different operations entirely.The Infrastructure panel is read-only but still requires this permission to open.

Tenant Center Impersonate

Impersonation — opening a live workspace session inside a tenant environment as the calling user.Related docs: Tenant CenterWhen Enabled, the user sees the “Impersonate” action in each tenant’s row menu. Clicking it generates a one-time token, exchanges it for tenant-scoped credentials, and opens the target tenant’s workspace in the browser. The session is bound to the impersonating user’s identity — all actions taken inside the tenant are attributed to them, and the impersonation event itself is recorded in the tenant audit log.

Impersonation respects the tenant’s RBAC configuration once inside — the impersonating user may have different access in the tenant than they do in the parent workspace.Not available when a tenant has a Proxy URL configured.

Tenant Center Metadata API

The gateway permission for the Xano Metadata API in tenant context. The Metadata API exposes machine-readable endpoints for all workspace operations (creating tables, deploying releases, managing API groups, etc.) and is consumed by external CI/CD pipelines, the Xano MCP server, and the Metadata API Explorer.Related docs: Metadata APIWhen Enabled, the user’s access token is allowed to authenticate and call any Metadata API endpoint that resolves to a tenant context. When Disabled, all Meta API calls to tenant-scoped resources are rejected regardless of the token’s other permissions.

This is an unlock prerequisite, not a full bypass. After granting it, the token still obeys all other workspace-level permissions for each individual endpoint.

Tenant Center Secrets

Sensitive tenant data — covers two distinct surfaces: the tenant License and tenant Environment Variables.Related docs: Tenant Center · Environment Variables

Level	Controls
Read	Opening the License panel (showing the raw license/credential string for tier3 tenants); viewing environment variable names and values.
Create	(Implicit in Update for env vars — the same operation adds or replaces values.)
Update	Saving changes to the License; adding or modifying env vars; replacing the entire env var set.
Delete	Removing individual environment variables.

The two surfaces are:

License — for tier3 (self-hosted / Regional Isolation) tenants, the license contains cluster credentials or external database connection strings. Exposure allows direct database or cluster access outside the Xano platform, hence treated as a secret.
Environment Variables — key-value pairs injected into the tenant runtime; typically API keys, connection strings, and feature flags.

The default for standalone deployments is full access. Self-hosted Xano users should review this — it exposes infrastructure credentials to all developers by default.

Tenant clusters

Tenant Cluster

Tenant Clusters — registered remote clusters used to host tier3 (Regional Isolation) tenants. Self-hosted/enterprise feature only; available when the instance has tier3 tenant slots allocated.Related docs: Resource Management

Level	Controls
Read	Visibility of the “Tenant Clusters” nav item and the cluster list; viewing individual cluster details. Also disables the “Create Workspace” button when an existing cluster is detected.
Create	The “Add new cluster” button — registers a new remote cluster with its credentials, domain, type (standard vs run), warm instance pool sizing, and ingress configuration.
Update	Editing cluster name, description, domain, type, warm pool sizes, ingress rules.
Delete	Removing a cluster registration.

Cluster registration stores credentials at create time; subsequent credential management is governed by the separate Tenant Cluster Secrets permission.

Tenant Cluster Secrets

The cluster credentials stored for each registered remote cluster — the complete credential set for managing that cluster.Related docs: Resource Management

Level	Controls
Read	The “Credentials” button on a cluster’s view panel; viewing the raw credential configuration.
Update	Saving replacement cluster credentials.

Both Read and Update events are written to the audit log.

Highest-privilege permission. Exposure of these credentials grants full control over the remote cluster — this should be granted only to operators who need to rotate or inspect credentials.Distinct from Tenant Center Secrets (which covers tenant database credentials, not cluster-level credentials).

Create roles

Assign to team members

Bulk operations

Permissions reference

​Accessing RBAC

​The Permissions Center

​Creating roles

​Assigning roles

​Adjusting permissions

​Bulk operations

​Copy/paste permissions

​Bulk role assignment

​Bulk permission editing

​Permissions explained

​Workspace & data

​Build & logic

​Run & debug

​Settings & integrations

​Releases & Tenant Center

​Tenant clusters

Accessing RBAC

The Permissions Center

Creating roles

Assigning roles

Adjusting permissions

Bulk operations

Copy/paste permissions

Bulk role assignment

Bulk permission editing

Permissions explained

Workspace & data

Build & logic

Run & debug

Settings & integrations

Releases & Tenant Center

Tenant clusters