Deployment Models¶

What Deployment Models are supported by Omnistrate¶

Deployment models describe where your application runs and who owns the runtime environment. They do not specify how much infrastructure each customer deployment shares.

Choose tenancy separately: use Infrastructure Multi-Tenancy for separate pods on shared VMs, or Dedicated Tenancy for dedicated VMs with optional network or Kubernetes cluster boundaries. For dedicated customer accounts, use BYOC so deployments run in accounts supplied and owned by customers. See Tenancy Types for the supported types and isolation suboptions.

For a comprehensive overview of all deployment scenarios and use cases, visit our Use Cases section.

For Hosted SaaS tenancy options, see the Infrastructure Multi-Tenancy Overview and Dedicated Tenancy Overview.

Hosted SaaS¶

The Hosted SaaS model runs your application in provider-owned cloud accounts. Customers access the service without supplying their own cloud accounts. This describes account ownership, not a particular vendor's internal architecture or tenancy model.

You can offer pod-level infrastructure multi-tenancy or dedicated VMs, networks, and Kubernetes clusters through different plans while keeping the runtime provider-owned. For dedicated customer accounts, offer BYOC instead. Your control plane, generated with Omnistrate, performs runtime provisioning and lifecycle operations.

The diagram shows two deployments in the provider account. Each deployment contains the same application components; whether their underlying VMs are shared or dedicated is a separate tenancy choice.

Customer Networks¶

For customer-specific network boundaries while keeping the runtime in your provider account, combine Dedicated Tenancy with Customer Networks. Customers choose or create a network and can configure private connectivity. Deployments using the same customer network can share the network and its host cluster; this feature does not move the workload to a customer-owned account.

To learn more about configuring customer networks, see Customer Networks.

BYOC Anywhere¶

BYOC runs your application in a customer-owned cloud account. Customers onboard their account and grant scoped permissions to your generated control plane, which provisions and manages the deployments inside that boundary.

BYOC can use dedicated VMs or pod-level infrastructure multi-tenancy in the customer's account. To provide a dedicated account boundary, onboard a separate customer-owned account for each required boundary. BYOC does not create one cloud account per deployment; deployments in the same onboarded account share that account boundary.

BYO-VPC is the option to deploy within an existing customer-supplied network. Account ownership, VM tenancy, network isolation, and Kubernetes cluster isolation remain distinct decisions.

The diagram separates the provider's generated control plane from runtime infrastructure in two customer accounts. Each customer deployment has the same application components. The management arrows show responsibility, not public ingress or a required network path; use the BYOC networking capabilities to choose connectivity that matches customer policy.

To learn more, check the BYOC Anywhere use case.

Air-Gapped¶

Air-Gapped delivery runs your application in an isolated customer environment, on cloud infrastructure or local hardware. You deliver an installer and the required approved artifacts; the customer installs, upgrades, and operates the software locally. Runtime operations must not depend on live access to your external control plane or public artifact repositories.

The diagram shows an approved artifact transfer, not an active network connection into the isolated environment. The customer controls artifact import and local lifecycle actions; tenancy and resource isolation are defined by the deployment artifacts.

Learn more about air-gapped deployments in the Air-Gapped Use Case. For a step-by-step guide to building an air-gapped installer, see Air-Gapped Installer Plan.