Build for BYOC Anywhere Overview¶

What Is BYOC Anywhere?¶

BYOC Anywhere is a spectrum of deployment and operating models where your software runs inside a customer-controlled environment while you retain operational control through Omnistrate's control plane. Instead of asking customers to manage the software on their own, you provide a managed experience across the customer's account, network, Kubernetes platform, or disconnected environment.

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 and a related Air-Gapped distribution model, 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.

For the broader zero-trust principles behind these architecture models, read BYOC Anywhere: The 10 Commandments.

BYOC Variants in Detail¶

BYOC-Account¶

BYOC-Account 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-VPC¶

BYOC-VPC deploys into a customer-approved network boundary rather than assuming a fresh account or default network. The deployment must respect the customer's VPC or VNet, subnets, routing, DNS, firewall, private endpoints, and egress policies.

This model is suitable when customers require private connectivity, centralized firewall inspection, egress allowlists, internal DNS and certificate policies, or existing network segmentation. See Customer Networks and BYOC Deployment: Bring Your Own VPC.

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-K8s¶

BYOC-K8s 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 provides the runtime and platform standards; you deploy and operate the application through Helm, operators, or other Kubernetes-native mechanisms.

The customer may enforce admission policies, image scanning, secrets management, storage classes, ingress controllers, service mesh rules, node pools, GPU scheduling, and observability integrations. Cluster version, CNI behavior, storage drivers, quotas, and registry access therefore become shared responsibilities with the customer's platform team.

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.

How each model maps to customer needs¶

Across every model, BYOC Anywhere must support the full lifecycle: provision, deploy, configure, govern, upgrade, meter, observe, and operate. This requires least-privilege permissions, zero-inbound access where possible, egress allowlists, supply-chain integration, auditability, and customer-safe observability.

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