Bring Your Own Cloud

Bring Your Own Cloud lets an organization power its product with infrastructure inside its own AWS account or GCP project.

MIOSA remains the orchestration and product control plane.

Activation gated Infrastructure packages built

Control plane and customer cloud

flowchart LR
  subgraph M["MIOSA control plane"]
    Desired["Desired state"]
    Scheduler["Placement and scheduling"]
    Acceptance["Host acceptance"]
    Evidence["Health, usage, and evidence"]
  end

  subgraph C["Customer cloud account"]
    Identity["Scoped cloud identity"]
    Network["Private network"]
    Hosts["MIOSA worker hosts"]
    Guests["Firecracker workloads"]
    Storage["Customer cloud storage"]
  end

  Desired --> Identity
  Scheduler --> Hosts
  Identity --> Hosts
  Network --> Hosts
  Hosts --> Guests
  Guests --> Storage
  Hosts -->|Outbound authenticated session| Acceptance
  Hosts -->|Health and runtime census| Evidence

The customer controls the cloud account, network, identity policies, provider resources, and provider bill.

MIOSA controls desired capacity, workload placement, immutable runtime generations, acceptance, scheduling, drain, and reconciliation.

What runs where

Layer	MIOSA control plane	Customer cloud
Organization and workspace policy	Yes	No
Desired capacity and placement	Yes	Reflected by worker capacity
Provider IAM and networking	Validated and orchestrated	Created and owned
Worker hosts	Observed and scheduled	Executed and billed
Firecracker workloads	Requested and tracked	Executed
Host runtime artifacts	Identified and verified	Downloaded and installed
Customer data stores	Bound by the application	Customer-selected
Acceptance evidence	Recorded	Produced by the host

Provider support

Amazon Web Services

Terraform and CloudFormation packages define private multi-AZ worker foundations, scoped IAM, immutable templates, and fail-closed acceptance.

AWS architecture →

Google Cloud

Terraform defines the service account, network, firewall, instance template, artifact access, and acceptance handoff.

Google Cloud architecture →

Customer onboarding path

sequenceDiagram
  participant Customer
  participant MIOSA
  participant Cloud as Customer cloud
  participant Host as Worker host

  Customer->>MIOSA: create customer-cloud region
  MIOSA-->>Customer: scoped identity and immutable runtime inputs
  Customer->>Cloud: apply reviewed infrastructure package
  Customer->>MIOSA: register provider outputs
  MIOSA->>Cloud: validate identity, network, quota, and image
  MIOSA->>Cloud: request one acceptance worker
  Cloud->>Host: boot verified runtime
  Host->>MIOSA: outbound acceptance evidence
  MIOSA->>MIOSA: verify KVM, storage, runtime, and session
  Customer->>MIOSA: enable placement

Infrastructure creation does not make a region live.

Placement begins only after provider preflight, one real host acceptance, recorded evidence, and explicit enablement.

Why activation is gated

The packages intentionally fail closed until the per-instance acceptance sequence is certified through a real provider canary. Cloud-provider state such as EC2 running is never enough to declare a MIOSA host ready.

BYOC compared with OpenComputers

	Bring Your Own Cloud	OpenComputers
Unit	Governed cloud region or host pool	Individual owned machine
Provisioning	Terraform or CloudFormation	Agent installation
Network	Customer VPC or subnetwork	Existing host network
Identity	Cloud IAM and instance identity	MIOSA host registration
Capacity	Provider fleet	Connected machines
Best for	Enterprise cloud boundaries	Local and owned hardware

Review responsibility boundaries Understand identity, networking, data, runtime, upgrades, and incident ownership.