Tenant Center

​

Why Tenant Center

The Tenant Center brings a traditional CI/CD workflow into Xano, and gives you a single place to run as many isolated copies of your backend as your business needs — each with its own database, its own URL, and its own lifecycle. With Tenant Center, you can:

• Run real dev / stage / production environments for the same workspace, instead of editing live and hoping for the best
• Isolate customers or user groups into their own tenants — perfect for per-customer data isolation, beta cohorts, or rolling out new features to one group at a time
• Deploy across regions to reduce latency for users in another part of the world or to satisfy data-residency requirements
• Stage Xano platform upgrades safely by running a tenant on a newer (or older) platform release and validating against it before rolling that version out everywhere else

Higher tenant tiers extend this further: a Dedicated tenant gets its own CPU, memory, and storage so it’s insulated from noisy neighbors and can be sized to its workload, and a Remote tenant runs on infrastructure in a specific region or cluster you control. See Tenant Types for the full breakdown.

​

Tenant vs. branch vs. workspace

​

Using Tenant Center

This section walks the full Tenant Center flow in the order you’ll actually use it: create a tenant, call its APIs, and deploy a release to it.

​

Creating New Tenants

​

Developing and Deploying Releases

Once you have one or more tenants, you push changes to them by cutting a release from your source workspace and deploying it. A release is a snapshot of logic and schema only — no data — taken from a source branch. Deploying a release to a tenant overwrites its function stacks, APIs, and table structure, but preserves:

• Tenant database records
• Environment variables
• Backups
• RBAC overrides
• Ingress and infrastructure settings

​

Preventing Deployment issues

​

Backups

Backups are available for your tenants by clicking the and selecting Backups. Create a backup by selecting Create New Backup. Backups are designed to be retained long term, and can be downloaded for offline archival. They contain the entirety of the tenant: database and logic.

​

Calling Tenant APIs

Each tenant will have their own base URL, which can be used to call a tenant’s APIs directly. You can find this URL and more by clicking and choosing Details. You can also utilize the X-Tenant header to route a request to a specific tenant instead of using that tenant’s base URL. Set the header as X-Tenant: <tenant name> against your source workspace’s base URL and the request will be routed to that tenant. This is useful when a single frontend needs to target multiple tenants without swapping base URLs.

​

Deployment Requests

For tenants where you want a second set of eyes before anything goes live — production, or any tenant with compliance requirements around who can ship — you can require a Deployment Request: a reviewable request that must collect a minimum number of approvals before its release is allowed to deploy.

​

Enabling the deployment gate on a tenant

Open a tenant’s Edit Tenant panel and enable Require Deployment Request. This reveals three settings: Setting Minimum Required Approvals to 0 (the default) turns the gate off entirely — deploys to that tenant behave as described in Developing and Deploying Releases, with no request required.

​

Creating a Deployment Request

You can start a request two ways:

• From a release deploy — when deploying a release and one or more selected tenants require approval, choose Request deployment instead of Deploy. This pre-fills the request with the tenant and release you selected.
• From the Deployment Requests page — click Create Request, then choose a target tenant (only tenants with the gate enabled are selectable), the release to deploy, and a title and description explaining the change.

Creating a request against a tenant doesn’t touch that tenant until the request is approved (or bypassed) and deployed — the tenant keeps running its current release in the meantime.

​

Reviewing a request

Anyone with the Tenant Center Deploy permission on the target tenant can review a request, with one exception: you can’t review your own request. There’s no separate reviewer list to manage — eligibility is based entirely on who already has deploy access to that tenant. Opening a request shows:

• A file tree of the objects (tables, function stacks, APIs, etc.) that differ between the tenant’s current release and the candidate release, with a side-by-side diff for each
• A comment thread, both general and scoped to individual changed objects
• The request’s status, approval progress toward the required minimum, and its revision/comment history

From here a reviewer can:

• Comment — leave feedback without casting a vote
• Approve — optionally with a comment. Counts toward the required minimum.
• Request Changes — requires a comment, and moves the request to changes_requested until the author addresses it and resubmits

​

Deploying an approved request

Once a request has enough approvals, it becomes eligible to deploy:

• If Allow Approve & Deploy is on for the tenant, the deploy happens automatically as soon as the last required approval is cast.
• Otherwise, an authorized user clicks Deploy on the approved request to push it, same as a normal release deploy.

The author can also Close a request at any point, to withdraw it or decline it, with an optional reason. Closing is final — there’s no way to reopen a closed request, so if the change is still wanted, open a new request.

​

Bypassing the gate

If a tenant has Allow Authorized Deployment Bypass enabled, a user holding the Tenant Center Deploy Bypass permission can deploy a release to that tenant — including their own pending request — without collecting any approvals. A reason is required for every bypass, and bypasses are always recorded in the tenant’s Logs. Use this sparingly: it’s meant for genuine emergencies (a hotfix that can’t wait on review), not as a routine way around the approval process. Tenants that should never allow this can simply leave Allow Authorized Deployment Bypass off.

​

Managing Tenants

Once you’ve created a tenant, you can click the ⋮ icon to access tenant settings.

​

Edit Tenant

Change the settings applied when creating the tenant, such as the display name or description.

​

Deploy Release

Push a release (a snapshot of your workspace logic and schema) to this specific tenant. This is the same flow described in Developing and Deploying Releases, scoped to a single tenant. When you open the panel you’ll see:

• Release selector — choose any release from the source workspace. Each entry shows the release name, hotfix label (if any), and the timestamp it was created.
• View Changes — opens a diff of the current tenant content versus the selected release so you can review exactly what will change before deploying. If the tenant is already on the selected release, this option is disabled.
• Deploy — runs the deployment. The panel reports per-tenant progress and elapsed time.

A few behaviors worth knowing:

• If a release references a database object (table, field, etc.) that doesn’t exist on the target tenant, the deploy fails with a database reference error and the tenant is left on its previous release. Resolve the missing reference and re-run the deploy.
• You can deploy to multiple tenants in one operation from the main Tenant Center view; deployment runs sequentially and stops on the first failure.
• Deploy Release does not change the tenant’s platform version — for that, use Deploy Platform below.
• If this tenant has Require Deployment Request enabled, this panel opens a Request deployment flow instead of deploying immediately — see Deployment Requests.

​

Deploy Platform

Update the Xano platform version this tenant runs on. This is independent of Deploy Release: a release ships your workspace logic, while Deploy Platform updates the underlying Xano runtime the tenant executes against. The panel shows:

• Platform selector — choose any available Xano platform version. Each entry shows the platform ID, name, and the date it was published. The selector defaults to the tenant’s current platform.
• Deploy — applies the selected platform to the tenant.

While the platform deploy is running you’ll see “Your tenant is being updated. This may take a few minutes.” — the tenant’s pods are recreated against the new platform image, so expect a brief restart of the affected services. Use Deploy Platform to:

• Stage a tenant on a newer platform version to validate your workspace against it before rolling that version out to production tenants
• Pin a tenant to a specific platform version for stability
• Catch a tenant up to the platform other tenants are already running

​

Manage Resources

Edit the CPU, memory, storage, autoscaling, affinity, and toleration settings for this tenant’s deployments. Available on Resource Isolation and Regional Isolation tenants. This panel is covered in detail in Configuring Resources for Tenants, including the Small / Medium / Large templates, the Custom editor, per-deployment configuration for the database and Redis instances, the Horizontal Pod Autoscaler fields, and how affinity and toleration rules interact. Two save options are available at the bottom of the panel:

• Save — persists your resource changes without redeploying the tenant’s platform.
• Save & Deploy — persists the changes and immediately redeploys the platform so the new resource allocation takes effect. If the tenant has no platform assigned yet, only Save is available.

​

Infrastructure

A read-only observability view into the live Kubernetes resources backing this tenant. Use it to check pod health, verify a deployment rolled out correctly, look up the tenant’s external IP, or confirm storage is provisioned. The panel is organized into six tabs, each backed by live data from the cluster. A Refresh button at the top reloads the current tab. CPU is reported in cores or millicores (e.g. 1.2 cores or 850m) and memory in Gi or Mi depending on magnitude. The Infrastructure panel is read-only — to change any of these values, use Manage Resources or Deploy Platform.

​

Impersonate

Access the tenant in its current state. Great for troubleshooting tenant-specific issues and manual verification of pushed changes. Impersonation can also run in read-only database mode. Use this when you need to inspect a tenant’s data to diagnose a problem but want a guarantee that the session can’t modify it — a safer default for support work on a production tenant.

​

Environment Variables

You can access and manage this tenant’s environment variables from here. Use these to store things like API keys and other sensitive information to be used in that tenant’s function stacks. For example, if you are pushing a feature that calls OpenAI, and each tenant has their own OpenAI API key, you’d put that here and just make sure the variable name matches what your function stacks reference.

​

Backups

Create or restore a backup of a tenant

​

Logs

Review logs directly associated with that tenant, such as release deployments, backups, and impersonations.

---

​

Tenant Types

Some workspaces may have access to different tenant types, which unlock significant operational flexibility beyond the default Shared Namespace. Upgrading to a Dedicated or Remote tenant lets you:

• Choose dedicated CPU, memory, and storage so a tenant is insulated from noisy neighbors and can be sized to its actual workload
• Pin a tenant to a specific region for data residency compliance or to reduce latency for users in that region
• Run a tenant on a specific Xano platform release, which is invaluable for safe development — you can stage a tenant on a newer or older platform version and validate your workspace against it before rolling that platform version out to production tenants

When creating a new tenant, you may see a Type dropdown. This allows you to select which tenant type to assign to the new tenant.

​

What’s available at each tier

Shared tenants are the right starting point when isolation between customers is the only goal and your workloads can safely share resources. Dedicated tenants add control over the infrastructure each tenant runs on — sizing, autoscaling, platform version, and live observability — which is what you need once a tenant has SLAs, predictable load requirements, or has to be staged on a specific Xano version. Regional tenants extend that further by running on infrastructure in a region or cluster you control, which is the only option that satisfies data-residency requirements or in-region latency targets.

​

Tenant Infrastructure

When deploying a Resource Isolation (Dedicated Namespace) or Regional Isolation (Remote Namespace) tenant, after creating the tenant you’ll be prompted to select the specific infrastructure allocation for that tenant. We offer three pre-defined infrastructure packages, plus a Custom option:

• Small = “Get me live fast.” Best for MVPs, prototypes, internal tools, early-stage production, or moderate traffic.
• Medium = “We’re in production and growing.” For apps with steady real users, more endpoints, more background jobs, and higher concurrency.
• Large = “We need serious headroom.” Built for high traffic, enterprise workloads, heavy automation, larger datasets, and lots of simultaneous users.
• Custom = manually define all aspects of a tenant’s available resources for more advanced configurations.

​

Configuring Resources for Tenants

Resource Isolation and Regional Isolation tenants both run on dedicated infrastructure, which means you control exactly how much CPU, memory, storage, and scaling capacity is allocated to each deployment. After a qualified tenant is created, open its ⋮ menu and choose Manage Resources to open the resource configuration panel.

​

Templates vs Custom

At the top of the panel you’ll see four options: Small, Medium, Large, and Custom.

• Clicking Small / Medium / Large applies one of the predefined infrastructure packages described above — a quick starting point for most tenants.
• Any time you change an individual value, the selection automatically switches to Custom, indicating that you’ve diverged from a template. You can return to a template at any point by re-selecting it (this will overwrite your custom values).
• Toggling Verbose at the top reveals additional detail in the summary view, including affinity and toleration rules.

​

Deployments

A tenant with configurable resources is made up of two independently configurable deployments:

• Database — the tenant’s Postgres instance, including persistent storage
• Redis — the tenant’s Redis instance, used for caching and realtime features

Each deployment can be toggled ON or OFF using the colored buttons near the top of the panel. Disabling a deployment frees its resources but will disable any tenant functionality that depends on it, so only turn these off if you’re sure your tenant doesn’t need them. Click the edit (pencil) icon on a deployment to configure its resources.

​

CPU and RAM

For each deployment you can configure four values: Requested values reserve capacity on the node; limits cap burst usage. As a rule of thumb, set requests to what the workload normally needs and limits to a safe ceiling above that. Setting requests equal to limits gives you the most predictable performance.

​

Autoscaler (Horizontal Pod Autoscaler)

Deployments that support autoscaling expose an Autoscaler section with three fields: When average CPU across running pods exceeds the threshold, Kubernetes adds replicas (up to Max). When utilization drops, it scales back down (no lower than Min). Increase Min replicas for workloads that need hot capacity on standby; increase Max replicas to give the tenant more headroom for traffic spikes.

​

Storage

For deployments with persistent storage (the database), set the Storage value to the size of the persistent volume. Storage can typically be increased later but not decreased, so start conservatively and grow as needed.

​

Affinity

Affinity rules control which nodes in the cluster your tenant’s pods are allowed to run on. This is especially useful on Regional Isolation clusters where you’ve tagged nodes by zone, hardware class, or customer. Each expression consists of:

• Key — the node label to match (e.g. topology.kubernetes.io/zone)
• Operator — In, NotIn, Exists, DoesNotExist, Gt, Lt
• Value — the value (or values) to match against
• Type — Required (hard constraint; pods won’t schedule without a match) or Preferred (soft constraint; scheduler tries but will fall back)

Click Add Affinity… to add additional expressions. All expressions are combined to select eligible nodes.

​

Toleration

Tolerations let tenant pods run on nodes that have been tainted — for example, nodes reserved for a specific customer or workload class. Each toleration consists of:

• Key — the taint key on the node
• Value — the taint value (when applicable)
• Operator — Equal or Exists
• Effect — NoSchedule, PreferNoSchedule, or NoExecute

Tolerations don’t require the pod to run on tainted nodes — they just allow it to. Combine tolerations with affinity rules when you need to both allow and require placement on specific nodes.

​

Saving changes

When you’re finished, click Ok to close the edit view for a deployment, then Save & Deploy (or Deploy if you arrived from another flow) at the bottom of the panel. Resource changes are rolled out immediately, which may cause a brief restart of the affected deployment.

​

Tenant Clusters

A Tenant Cluster is a remote Kubernetes cluster registered with your instance and used to host Regional Isolation tenants (the Remote Namespace type). Tenant Clusters are what make it possible for a tenant created in the Tenant Center to run in a different region, a dedicated production environment, or any other Kubernetes footprint you control. Typical use cases:

• Hosting tenants in a specific geographic region for latency or data-residency requirements
• Running isolated production environments separate from your main instance
• Dedicating infrastructure to a particular customer or customer segment

Tenant Clusters are managed from the Tenant Clusters panel (available on plans that include Regional Isolation). Once a cluster is registered, it becomes a selectable target when you create a Regional Isolation tenant in the Tenant Center.

​

Creating a Tenant Cluster

From the Tenant Clusters panel, click Add new cluster and provide:

​

KubeConfig

The Credentials field accepts a standard Kubernetes kubeconfig YAML document — the same file format produced by kubectl config view --raw or by your cloud provider’s CLI (e.g. aws eks update-kubeconfig, gcloud container clusters get-credentials, az aks get-credentials). Xano uses this KubeConfig to connect to your cluster and provision, update, and remove tenant workloads. A few things to keep in mind:

• Required permissions — the credentials must have sufficient RBAC permissions in the target cluster to create and manage namespaces, deployments, services, ingresses, and secrets.
• Network reachability — the cluster’s API server must be reachable from Xano. If your control plane is behind an IP allow-list, make sure Xano’s outbound IPs are whitelisted before saving the KubeConfig.
• Long-lived credentials — prefer service-account tokens or other long-lived credentials over short-lived user tokens, since Xano needs ongoing access to manage tenants over the cluster’s lifetime.
• Updating credentials — you can rotate the KubeConfig at any time by opening the cluster, clicking Credentials, and pasting the new YAML. This requires the TenantClusterSecrets: Update permission.

​

Editing and Deleting Clusters

Opening a cluster from the list shows its general settings and ingress configuration. From here you can:

• Edit general settings — name, description, type, warm pool sizes, and domain
• Edit Ingress — update ingress secrets, TLS hosts, and annotations independently of the general settings
• Credentials — view or replace the cluster’s KubeConfig
• Delete — remove the cluster registration. Deletion requires typing a confirmation phrase and cannot be undone

​

How Tenant Clusters relate to the Tenant Center

Tenant Clusters are the infrastructure layer; the Tenant Center is where you create and operate the tenants that run on them. The flow is:

1. Register a cluster in Tenant Clusters by supplying its KubeConfig, domain, and ingress settings.
2. Create a tenant in the Tenant Center and choose Regional Isolation (Remote Namespace) as the type.
3. Select the cluster you registered as the target for that tenant.
4. Deploy releases to the tenant from the Tenant Center exactly as you would for any other tenant — the release is deployed into the remote cluster transparently.

If you’re using a Run-type cluster with warm tenants configured, new tenant creation pulls from the warm pool for near-instant provisioning; Xano then replenishes the pool in the background.

​

Permissions

Tenant Cluster management is gated by dedicated RBAC permissions:

• TenantCluster — Create, Read, Update, Delete cluster registrations
• TenantClusterSecrets — Read and Update the KubeConfig credentials stored on a cluster

​

RBAC: Tenant Center

The Tenant Center addon includes additional Role-based Access Control (RBAC) settings you can use to manage tenant-related permissions. These permissions include:

• Tenant Center - Enables access to the Tenant Center
• Tenant Center RBAC - Enables access to Tenant Center RBAC Override settings Note: This does not disable the ability to disable/enable Tenant Center RBAC Overrides, but does disable access to editing the specific override settings.
• Tenant Center Logs - Enables access to the logs inside of the Tenant Center
• Tenant Center Backup - Determines if a user can modify backup settings or perform backup/restore operations for tenants
• Tenant Center Deploy - Determines if a user can deploy releases to tenants. On tenants with the deployment gate enabled, this permission also determines who can review and approve Deployment Requests — anyone with Tenant Center Deploy on a tenant can review requests for it, as long as they aren’t the request’s author
• Tenant Center Deploy Bypass - Determines if a user can skip the Deployment Request review gate on tenants that have Allow Authorized Deployment Bypass enabled. This is independent of, and more privileged than, Tenant Center Deploy — grant it only to trusted users who may need to deploy in an emergency without waiting on review
• Tenant Center Impersonate - Determines if a user can impersonate (access directly) a tenant
• Tenant Center Secrets - Enables access to secrets for a tenant, such as Environment Variables

​

RBAC Override

From the Edit Tenant panel, you can enable RBAC Override. This option allows you to specify individual user permissions for each tenant by clicking RBAC at the top of the Tenant Center.

​

Common role recipes

​

Best Practices