Infrastructure Multi-Tenancy¶
Infrastructure Multi-Tenancy lets separate customer deployments run in separate pods while sharing underlying VMs. In a Compose-based plan, this is the behavior selected by OMNISTRATE_MULTI_TENANCY.
A deployment is a customer deployment instance, not a VM. Each deployment can contain multiple application components and replicas. Pods from several deployments can run on the same machine, so the number of deployments is not the number of VMs.
How Infrastructure Multi-Tenancy Works¶
- A customer creates a deployment through your SaaS interface or API.
- Your control plane, generated with Omnistrate, provisions the deployment's application pods.
- Pods are scheduled onto shared VMs according to their CPU and memory requests, allowing available capacity to be reused across deployments.
- Your control plane manages each deployment's lifecycle, even though its machine capacity is shared with other deployments.
See the Infrastructure Multi-Tenancy architecture for a diagram comparing the same deployments on shared and dedicated VMs.
When to use Infrastructure Multi-Tenancy¶
This model is suitable for cost-efficient tiers, high deployment density, and workloads where pod-level separation meets the customer's security and performance requirements. Define realistic resource requests and limits before relying on shared capacity for production workloads.
It does not require a tenant-aware application that serves multiple customers from one process. You can run a separate application deployment for each customer while sharing the machines underneath.
What Is Shared and What Is Separate¶
| Boundary | Behavior |
|---|---|
| Application pods | Separate per deployment; each deployment has its own workloads and resource configuration. |
| VM capacity | Shared across deployments; CPU, memory, and other machine resources can be subject to contention. |
| Kubernetes cluster, network, and provider account | Not dedicated per deployment by this tenancy setting. |
| Application data and access | Your application and deployment configuration must enforce credentials, authorization, endpoint, and data separation. |
Requests guide scheduling and limits constrain resource use, but they do not provide the same performance boundary as dedicated VMs. Plan for shared-capacity headroom, peak demand, backups, and upgrades.
Choose a Broader Isolation Boundary¶
If a customer requires dedicated VMs, a network, or a Kubernetes cluster, select Dedicated Tenancy and configure that level. These are dedicated-tenancy suboptions, not variations of OMNISTRATE_MULTI_TENANCY. For dedicated customer accounts, use BYOC. See the Dedicated Tenancy Overview.
For Helm, Kustomize, Terraform, and OpenTofu, use Custom Tenancy and define sharing and isolation in your deployment artifacts.
For configuration and rollout steps, see the Infrastructure Multi-Tenancy Deployment Guide.