Customer infrastructure

MIOSA can orchestrate products across infrastructure operated by MIOSA or controlled by the customer.

The application keeps one resource model and control plane while placement determines where work executes.

Choose an infrastructure model

MIOSA-managed

MIOSA operates the compute, networking, host lifecycle, and capacity.

Best for fast onboarding and products that do not require a customer-owned cloud boundary.

OpenComputers

Connect individual machines through an outbound agent session.

Best for workstations, local models, owned servers, and desktop workflows.

OpenComputers →

Bring Your Own Cloud

Install a governed MIOSA worker region inside a customer AWS or GCP environment.

Best for cloud-account ownership, private networking, and enterprise infrastructure policy.

BYOC architecture →

Hybrid placement

Keep governed workloads in customer infrastructure and use other capacity only where policy permits.

Placement remains explicit per organization, workspace, environment, and workload.

One orchestration layer

flowchart TB
  Product["Your product"] --> MIOSA["MIOSA control plane"]
  MIOSA --> Managed["MIOSA-managed compute"]
  MIOSA --> Owned["OpenComputers"]
  MIOSA --> BYOC["Customer cloud region"]
  BYOC --> AWS["AWS account"]
  BYOC --> GCP["GCP project"]
  Managed --> Evidence["Common status and evidence"]
  Owned --> Evidence
  AWS --> Evidence
  GCP --> Evidence

Your product should not need a different workflow for every provider.

MIOSA resolves the target, checks policy and capacity, dispatches work, and reports one status and evidence shape.

Product promise

Bring Your Own Cloud is not a second, disconnected MIOSA installation.

MIOSA remains the orchestration authority while workload hosts, cloud resources, and provider billing remain inside the customer’s account or project.

Understand the shared responsibility model See which responsibilities belong to the customer, MIOSA, and the cloud provider.

Was this helpful?