Skip to content

Infrastructure Multi-Tenancy Deployment Guide

This guide configures pod-level infrastructure multi-tenancy for a Compose-based Hosted SaaS plan. Each customer deployment runs in separate pods, while VMs are shared across deployments. It does not configure dedicated machines, networks, Kubernetes clusters, or accounts.

Before You Begin

  • Prepare your application's Compose specification and onboard the provider cloud account that will host the service.
  • Decide whether shared VM capacity and pod-level isolation meet the plan's security and performance requirements.
  • Identify CPU and memory requirements for every component, and how each deployment separates credentials, data, and access.
  • Use Dedicated Tenancy instead if the required boundary is a VM, network, or Kubernetes cluster. For dedicated customer accounts, use BYOC.

Configure Infrastructure Multi-Tenancy

Set OMNISTRATE_MULTI_TENANCY and configure your provider account with hostedDeployment. This AWS example illustrates account configuration; tenancy and account ownership are separate choices. See the deployment schema for other cloud account fields.

x-omnistrate-service-plan:
  name: 'Infrastructure Multi-Tenant SaaS'
  tenancyType: 'OMNISTRATE_MULTI_TENANCY'
  deployment:
    hostedDeployment:
      awsAccountId: '<AWS_ACCOUNT_ID>'
      awsBootstrapRoleAccountArn: 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/omnistrate-bootstrap-role'

Replace the account placeholders with your provider account details, and merge this block into your application Compose specification.

Configure Resource Requests and Limits

Set requests and limits for every application component. The following is an illustrative resource configuration, not a production sizing recommendation:

services:
  app:
    image: '<YOUR_APPLICATION_IMAGE>'
    deploy:
      resources:
        reservations:
          cpus: '0.25'
          memory: 256M
        limits:
          cpus: '0.50'
          memory: 512M

Requests guide pod placement on shared VMs; limits constrain resource consumption. Size these values from measurements of your workload, including startup, peak demand, and maintenance operations. Shared machines can still experience contention, so requests and limits are not a dedicated-VM guarantee.

If customers need configurable resource sizes, expose the resource-request and resource-limit API parameters shown in Tenancy Types.

Protect Each Deployment's Data and Access

Give each deployment the credentials, storage configuration, and access controls its application requires. Infrastructure multi-tenancy does not mean that deployments must share a database, a login, or an application process. Verify that one deployment cannot read another deployment's data or use its credentials or administrative endpoints.

For an application that serves several tenants inside one deployment, also enforce in-app tenant isolation. That is a separate application concern.

Validate Before Publishing the Plan

  1. Build the SaaS product from the Compose specification and create at least two test customer deployments using the plan.
  2. Confirm that each deployment has its own application workloads and deployment identifiers. A deployment identifier refers to the customer deployment, not a VM.
  3. Confirm the plan uses OMNISTRATE_MULTI_TENANCY; actual pod placement depends on available VM capacity and workload requirements.
  4. Test data and access separation, resource limits, and the effect of peak load from one deployment on others.
  5. Exercise scaling, upgrades, backups, restores, and deletion for one deployment while another remains active.
  6. Check shared-capacity headroom and autoscaling before publishing the plan to customers.

For Helm, Kustomize, Terraform, and OpenTofu, use a Service Plan specification with Custom Tenancy, and define the corresponding isolation in your artifacts rather than using this Compose tenancy setting.

What's Next