bbyoc anywhere
a technical framework for bring-your-own-cloud

Zero Trust,
in someone else’s cloud.

The ten commandments of building platforms that deploy and operate software inside customer-owned environments: no shared perimeter, no ambient trust, and every credential, connection, artifact, and permission must justify itself.

 The Multiple Dimensions of Enterprise-grade BYOC
DATA SOVEREIGNTYCONNECTIVITYIDENTITY & PRIVILEGEDELIVERY & OPERATIONSACCOUNTABILITY & EXITIIIIIIIVVVIVIIVIIIIXX
ten commandments,
five dimensions
hover a commandment to see what it covers; click to read it

The trust paradox in modern infrastructure: as a vendor, you keep operational responsibility for your product (provisioning, upgrades, scaling, and incident response) while your customer keeps the account it all runs in, along with data residency, cloud spend, and compliance posture. Your systems must operate inside a perimeter that is fundamentally closed to you. That arrangement has a name: BYOC, Bring Your Own Cloud, the deployment model in which your software runs inside your customer's environment, pairing the managed experience of SaaS with the data control of self-hosting.

Building for that boundary is hard because perimeter thinking stops working the moment you cross it. There are two accounts, two networks, and two owners, and every credential, artifact, and action now moves between parties with different interests. Zero trust becomes the working model: verify every identity, scope every privilege, expire every credential, gate every artifact, record every action, and make every grant revocable by the party who granted it.

Your control plane is where those obligations concentrate. Its job is to hold desired state, publish signed artifacts and configuration, broker short-lived identity, and collect the evidence that proves what your agent did. It must never hold customer data, long-lived credentials into customer accounts, or a position on the customer's data path. Everything that touches data, keys, backups, and end-user traffic belongs in the customer account, run by an agent that pulls its instructions and reconciles toward them.

The diagram below maps the mechanics of the trust boundary across three example architecture models from Omnistrate (BYOC-Account / BYOC-VPC, BYOC-K8s (Kubernetes), and Air-gapped), showing where the control plane brokers short-lived identity and how network access adapts as isolation requirements tighten.

 the account boundary is the trust boundary
← flexibilityfully restricted →
vendor agent provisions and operates infra + services
PLATFORM ACCOUNT · CONTROL PLANECUSTOMER ACCOUNT · DATA PLANETHE TRUST BOUNDARYorchestratorfleet state · workflowsmonitoringhealth · metricsmetering · billingusage eventsreceives status, never datastores no credentialsdeployment cellaws·gcp·azureagentreconciles desired state locallyserviceagent ✓the workload · containersconfig · backups · PITRinfraagent ✓cluster · nodes · networkvolumes + KMS keys · registrycustomer data never leavesPRIVATE CONNECTIVITYoutbound only · mTLSsync statehealthmetricsmeteringno inbound path existsEXPORT AUDIT · CUSTOMER VISIBLE12:04:01health pod/db-0 → healthy12:04:03metrics p99 latency 12ms12:04:06metering cpu_hours +4.212:04:09sync helm/db → Complete12:04:12access jane@ read-only12:04:15health disk 71% → ok12:04:18metering gb_hours +12.812:04:01health pod/db-0 → healthy12:04:03metrics p99 latency 12ms12:04:06metering cpu_hours +4.212:04:09sync helm/db → Complete12:04:12access jane@ read-only12:04:15health disk 71% → ok12:04:18metering gb_hours +12.8vendor agent provisions and operates infra + services inside the customer account
PLATFORM ACCOUNT · CONTROL PLANECUSTOMER ACCOUNT · DATA PLANETHE TRUST BOUNDARYorchestratorfleet state · workflowsmonitoringhealth · metricsmetering · billingusage eventsreceives status, never datastores no credentialsdeployment cellany kubernetesagentreconciles desired state locallyserviceagent ✓the workload · containersconfig · backups · PITRinfraplatform teamcluster · nodes · networkvolumes + KMS keys · registrycustomer data never leavesplatformteamPRIVATE CONNECTIVITYoutbound only · mTLSsync statehealthmetricsmeteringno inbound path existsEXPORT AUDIT · CUSTOMER VISIBLE12:04:01health pod/db-0 → healthy12:04:03metrics p99 latency 12ms12:04:06metering cpu_hours +4.212:04:09sync helm/db → Complete12:04:12access jane@ read-only12:04:15health disk 71% → ok12:04:18metering gb_hours +12.812:04:01health pod/db-0 → healthy12:04:03metrics p99 latency 12ms12:04:06metering cpu_hours +4.212:04:09sync helm/db → Complete12:04:12access jane@ read-only12:04:15health disk 71% → ok12:04:18metering gb_hours +12.8customer platform team owns the infra; the agent operates services only
PLATFORM ACCOUNT · CONTROL PLANECUSTOMER ACCOUNT · DATA PLANETHE TRUST BOUNDARYorchestratorfleet state · workflowsmonitoringhealth · metricsmetering · billingusage eventsnothing to receive: the site is darkno telemetry · no tunnelsdeployment cellisolated siteserviceplatform teamthe workload · containersconfig · backups · PITRinfraplatform teamcluster · nodes · networkvolumes + KMS keys · registrycustomer data never leavesno live connection in or outsigned installer artifactimages + charts embeddedthe artifact installs + manages the serviceplatform teamno agent and no connection: the platform team drives everything through signed artifacts
the ten commandments
  1. I.The Sovereign Data PlaneSplit the system at the account boundary, organize it as cells, and keep every derived form of the data (backups, snapshots, keys) in customer custody
  2. II.Connectivity Without ExposureA spectrum of control-plane connectivity, from reverse tunnels to PrivateLink to air-gapped, with the same trust properties at every point
  3. III.The Data Path Is the Customer'sEnd-user traffic reaches the product over customer-controlled networking (internal load balancers, VPC peering, PrivateLink-style endpoints, or the customer's own public edge) with no vendor component in the path
  4. IV.Identity Over SecretsMutual TLS with per-cell identity plus workload identity federation, so no static key exists in either direction
  5. V.The End Customer Makes the RulesCeilings, phased grants, and runtime privilege changes: building a control plane parameterized by customer-set permissions
  6. VI.A Supply Chain the Customer Can GateImages and charts mirror into customer-owned registries so existing scanning, signing, and admission policies apply to vendor software
  7. VII.Reconcile, Don't CommandThe control plane ships desired state through a typed contract; an in-account agent reconciles it, retries idempotently, and self-heals drift locally
  8. VIII.Every Action Leaves Two TrailsAttribution, completeness, tamper evidence, correlation, and delivery: every agent action answerable in the customer's own tooling
  9. IX.Revocable by DesignCustomer-side trust anchors let the customer revoke access per phase, per cell, per session, or all at once, the moment they decide to
  10. X.Exit Is a FeaturePortability is the last line of sovereignty: the same service definition runs hosted, BYOC, on-prem, or air-gapped, and the data is already in the customer's account

These commandments come from production experience operating many BYOC control planes across multiple clouds, regulatory environments, domains, products and teams. Like the twelve factors that inspired their form, they are written to outlive any one implementation.