Tenancy as an Application, Not a Platform

Multitenancy is usually described as running many customers on the same infrastructure. That framing hides the real problem. Sharing compute is the easy part; the hard part is guaranteeing that the identity, the network, the storage, and the management access of one customer never touch another's, while every customer administers its own slice without filing a ticket. That guarantee does not live in the hypervisor. It lives in the layer that decides who may create what, where, and within which limits. This series opened with exactly that argument: multitenancy on Nutanix is a control plane problem, and the primitives were already there, waiting for a control plane to compose them.

At .NEXT 2026, Nutanix announced that control plane: Service Provider Central, or SP Central, a purpose-built tenancy layer in early access today, with general availability targeted for the second half of 2026. The announcement is easy to read as a product launch. The more interesting reading is architectural, because the way SP Central is built confirms the thesis almost literally.

One Application Above the Clusters

SP Central is not a new platform to install next to your clusters. It is an application that runs inside Nutanix Central, the on-premises management plane Nutanix shipped earlier this year. The deployment chain makes the hierarchy explicit: you deploy a management Prism Central, deploy Nutanix Central from its Marketplace as an appliance, onboard one or more workload Prism Central instances, and install the SP Central application on top. The clusters underneath remain standard AOS and AHV. Nothing about tenancy is wired into the hypervisor.

This is a design decision with consequences, not a packaging detail. All control plane components, including the workload Prism Central instances that govern tenant clusters, live in a dedicated management domain on its own three-node cluster, while application domains hold nothing but workload clusters. Upgrading the control plane and growing tenant capacity become independent events, and the management failure domain is a single, sizable, protectable unit. If you come from VMware Cloud Director, the shape is familiar: a tenancy application above a management plane, not tenancy features inside the virtualization layer.

The Anatomy of a Tenant

The unit of tenancy is the Prism Central project, and the .NEXT session on architecting multi-tenant clouds was explicit that the construct was rebuilt for the purpose, to the point of calling it project 2.0. Today a project scopes quotas through the policy engine, role-based access, and VPC subnets. The rebuilt construct turns the project into a namespace for everything a tenant owns, and adds two things that change the operational model. Each tenant brings its own identity provider, with Active Directory, Entra ID, Okta, Google, and generic SAML supported, so tenant users are never guests in the provider directory. And each tenant gets a dedicated storage container, which makes storage policy and consumption accounting per-tenant properties instead of reporting exercises.

Access follows the same boundary. Every tenant reaches its environment through its own URL under the provider domain, passing the provider perimeter and landing on its own identity provider. The provider console is not exposed on that path at all; it is reachable only from the management VLAN. Read as a checklist, the per-tenant stack of identity, security policy, quotas, compute, VPC networking, and storage container is precisely what a service provider assembles by hand today with categories, naming conventions, and discipline. SP Central turns the checklist into an object.

Who Does What, and When

The role model has three actors on a Day 0 to Day 2 axis. The SP admin prepares tenancy: deploys the domains, builds the network underlay for the tenant use cases, onboards tenants, allocates capacity, assigns quotas. The tenant admin configures the environment: identity federation and users first, then networks, VMs, and storage inside the allocation. The tenant consumer runs workloads, with console access, backup and restore, and, notably, the same capabilities exposed as APIs for infrastructure as code.

The economics of an MSP practice live in that descending delegation. The provider touches a tenant twice, at onboarding and at quota changes; everything else happens inside the tenant, through portal or pipeline, without a ticket crossing the boundary. Self-service is not a portal feature here. It is the operating model the architecture is built to enforce, with guardrails defined above and enforced below.

What You Can Deploy Before GA

SP Central is in early access, but its foundation is shipping today, and the prerequisites are concrete. Nutanix Central on-premises 2.0 deploys from a Prism Central running 7.5.1 or later, through Marketplace bundle 4.3.4, as a seven-VM appliance totaling 109 vCPU and 208 GB of RAM. One form factor covers up to 25 Prism Central domains and 10,000 VMs, which is also the first real scale number an MSP can plan against. The platform expects wildcard DNS records and matching certificate SANs for three subdomains under the Central FQDN, so DNS and PKI are design inputs, not afterthoughts. Add the minimum compute floor, one three-node cluster for the management domain and at least one more for the first application domain, and the starting footprint is six nodes, sized before the first tenant onboards. This is a dedicated management substrate to size and protect as part of the provider architecture, not a portal bolted onto an existing cluster.

One more decision belongs to Day 0. A fresh Prism Central 7.5 makes a one-way choice between the two Flow deployment modes: Standalone, which Nutanix recommends on small and large instances and which moves the entire network control plane onto a cluster of its own, or Integrated, with no migration path from one to the other afterward. Every workload Prism Central in this design is a fresh install, so the door stays open, but it closes per instance the moment Flow is enabled.

None of this is wasted preparation. A provider that stands up Nutanix Central on-premises now is building the exact substrate SP Central installs into. And the Day 0 network design, transit, uplinks, public address pools, remains the provider's own work regardless of the product.

Where a Tenant Ends Today

The honest boundary is worth stating plainly. A tenant scales across clusters and across application domains, but it lives inside one management domain, one Nutanix Central instance with its SP Central application. Today a tenant does not span management domains; a provider operating multiple regions serves multi-site customers with per-domain tenancy plus shared service patterns, not with a global tenant object. That is a scoped fact about the first release, not a verdict, and it is the kind of fact to design around rather than discover.

The strategic read stays simple. Nutanix did not build new runtime for multitenancy. It built the control plane that composes years of platform primitives, projects, VPCs, storage containers, identity federation, into a tenant object with a lifecycle. The tenancy layer is also positioned to carry more than infrastructure: Nutanix has publicly framed platform services and AI workloads as the next floors on the same foundation, when and if they ship. The floor that exists today is the network, and the transit models that carry tenant traffic in and out of the platform are the subject of the next piece in this series.