Build for BYOC Overview¶

What Is BYOC (Bring Your Own Cloud)?¶

BYOC is a deployment model where your software runs inside your customer's own cloud account, on-premise cluster, or private infrastructure — while you retain full operational control through Omnistrate's control plane. Instead of asking customers to manage the software on their own, you provide a managed experience on their own infrastructure.

This model addresses a fundamental tension in software distribution: customers want the convenience of a managed service, but they need their data, compute, and network traffic to stay within infrastructure they own and control.

Omnistrate supports three BYOC variants, each targeting a different security and connectivity profile:

Why Build for BYOC?¶

Data Sovereignty Is Non-Negotiable¶

Enterprise customers in finance, healthcare, government, and defense operate under strict regulatory frameworks — HIPAA, GDPR, PCI-DSS, SOC 2, FedRAMP — that dictate where data can reside and who can access it. BYOC eliminates the compliance conversation entirely: the data never leaves the customer's infrastructure.

Security-Conscious Customers Require It¶

Many organizations will not send sensitive data to a third-party cloud account regardless of certifications. BYOC lets you serve these customers without building a separate on-premise version of your product or negotiating complex data processing agreements.

Cost Efficiency at Scale¶

When customers run workloads in their own accounts, they use their existing cloud commitments — reserved instances, savings plans, enterprise discount programs, and committed-use contracts. This reduces the effective cost of your product and removes the margin pressure of passing through your own infrastructure costs.

Operational Control Without Infrastructure Ownership¶

Unlike traditional on-premise software where you ship a binary and lose visibility, BYOC through Omnistrate gives you full fleet management capabilities. You can monitor, upgrade, scale, and troubleshoot every deployment across every customer account from a single control plane — as if they were running in your own infrastructure.

Why BYOC Matters More in the AI Era¶

The rise of AI workloads has made BYOC not just a compliance checkbox but a strategic necessity.

AI Workloads Amplify Data Sensitivity¶

AI models train on, fine-tune against, and inference over your customers' most valuable data — proprietary datasets, customer records, intellectual property, and trade secrets. The data flowing through AI pipelines is often more sensitive than traditional application data because it reveals business logic, competitive advantages, and strategic direction. Customers will not send this data to your cloud account.

GPU Costs Demand Customer-Owned Infrastructure¶

AI inference and training require expensive GPU instances. Customers with existing GPU reservations, committed-use discounts, or specialized hardware (NVIDIA H100/H200 clusters, custom FPGA setups) need to run workloads on their own infrastructure to avoid paying retail prices. BYOC lets them leverage their existing compute investments while consuming your product as a managed service.

Regulatory Frameworks Are Catching Up¶

The EU AI Act, executive orders on AI safety, and emerging frameworks around model governance all push toward stricter controls on where AI workloads run and how training data is handled. BYOC positions your product ahead of these requirements by keeping data and compute within customer-controlled boundaries.

Edge and On-Premise AI Is Growing¶

Not all AI workloads belong in the cloud. Inference at the edge, on-premise GPU clusters, and air-gapped environments for classified or sensitive workloads are becoming standard deployment targets. BYOC On-Premise supports these scenarios with the same operational model as cloud deployments.

Build Once, Deploy Anywhere¶

One of Omnistrate's most powerful capabilities is that a single Plan can target any deployment environment. You define your application once and deploy it across the full spectrum of infrastructure:

• Your own cloud account — for fully hosted SaaS
• Customer cloud accounts — AWS, GCP, Azure via BYOC
• Neoclouds — Nebius, CoreWeave, Lambda Labs, and other specialized GPU cloud providers
• On-premise Kubernetes — EKS, AKS, GKE, Rancher, OpenShift, or bare-metal clusters via BYOC On-Premise
• Local development — k3s, k3d, or minikube for testing and validation
• Air-gapped environments — fully disconnected networks via the air-gapped installer

This means you do not build separate versions of your product for different deployment targets. The same Helm chart, the same configuration, the same lifecycle hooks, and the same operational tooling work everywhere. Your customer chooses the deployment model at subscription time, and Omnistrate handles the rest.

graph LR
    A[Your Plan] --> B[Hosted SaaS]
    A --> C[BYOC - AWS/GCP/Azure]
    A --> D[Neoclouds]
    A --> E[On-Premise K8s]
    A --> F[Edge / k3s]
    A --> G[Air-Gapped]

From k3s to Enterprise Cloud — the Same Control Plane¶

A SaaS provider building an AI inference platform can start by validating their Plan against a local k3s cluster, promote it to their own AWS account for development, deploy it into a customer's GCP account via BYOC, run it on a Nebius GPU cluster for high-performance training workloads, and ship an on-premise installer for a defense customer — all from the same Plan definition and the same Omnistrate control plane.

This flexibility is unique to Omnistrate and eliminates the traditional tradeoff between reach and operational complexity.

BYOC Variants in Detail¶

Standard BYOC¶

Standard BYOC deploys your application into your customer's cloud account (AWS, GCP, or Azure). Omnistrate establishes a trust relationship between your account and the customer's account, then uses secure, encrypted channels with mTLS to manage the deployment lifecycle.

Your customer onboards their cloud account through a CloudFormation stack (AWS), Terraform module (GCP/Azure), or the Customer Portal. Once onboarded, you can deploy, monitor, upgrade, and troubleshoot instances in their account as if they were your own.

Customers can also bring their own VPC (BYO-VPC) for tighter network control over where workloads are placed.

BYOC PrivateLink¶

BYOC PrivateLink adds a zero-public-exposure guarantee on top of standard BYOC. All control-plane traffic between the customer's dataplane and your Omnistrate-managed control plane flows over AWS PrivateLink. The customer's EKS cluster has no public endpoint and no internet-facing load balancers for control traffic.

This variant is selected per customer account at onboarding time — no compose-spec changes required. It is essential for customers with strict no-public-egress policies, typically found in regulated financial services and government environments.

BYOC On-Premise¶

BYOC On-Premise extends the BYOC model to any Kubernetes cluster the customer operates — cloud-managed or bare-metal, in a data center or at the edge. The customer installs a lightweight dataplane agent that opens an outbound mTLS/gRPC connection to your control plane. No inbound access to the customer's cluster is required.

This variant supports the widest range of deployment targets, from enterprise Kubernetes platforms (EKS, AKS, GKE, OpenShift, Rancher) to lightweight distributions (k3s, k3d) and purpose-built GPU clusters.

Getting Started¶

1. Build a Plan using a compose specification or plan specification that defines your application's resources, parameters, and lifecycle
2. Configure BYOC deployment in your Plan specification — see deployment models for the schema
3. Onboard customer accounts through the Customer Portal or omnistrate-ctl — see BYOC cloud accounts for the operational guide
4. Deploy and operate instances across your customer fleet from the Omnistrate control plane