Managed and AWS BYOC sandboxes
MIOSA-managed sandboxes run on capacity operated by MIOSA. AWS BYOC places eligible sandboxes on accepted hosts in a customer’s AWS environment while retaining the public sandbox API and resource contract.
Runtime boundary
Each customer host runs the standalone miosa_host runtime.
Customer hosts do not run miosa_compute. miosa_compute remains inside the MIOSA control plane, where it performs admission, policy evaluation, catalog resolution, scheduling, lifecycle coordination, and usage accounting.
The host initiates an outbound session to the MIOSA control plane. The control plane can revoke that session and fence the host so a disconnected, replaced, or stale host process cannot continue receiving placement. No inbound control-plane listener is required on the customer host.
The public sandbox API does not expose customer host IDs, provider instance fields, placement records, network addresses, credentials, or session fencing details.
Certified artifacts
BYOC sandboxes boot only from immutable artifact generations certified for the selected public template.
Templates and sizes in GET /api/v1/templates identify customer-visible configuration, not mutable host paths or provider images.
A host must have the required certified generation and pass artifact integrity and runtime compatibility checks before it can be accepted for placement. MIOSA does not silently substitute an uncertified local image when that generation is missing.
Host acceptance before placement
Registering a host does not make it schedulable. MIOSA must accept the host before any sandbox can be placed on it.
Acceptance verifies the conditions required by the preview environment, including:
- Compatible
miosa_hostand control-plane protocol versions. - Required hardware virtualization and host capacity.
- Storage and network prerequisites.
- Availability and integrity of the certified artifact generation.
- A healthy outbound session with a current fencing generation.
- Runtime readiness checks required for sandbox execution.
Acceptance can be withdrawn when one of these conditions stops holding. A withdrawn or fenced host receives no new placement until it passes acceptance again.
Configuration vs request parameters
Environment configuration determines which accepted hosts, templates, resource contracts, policies, and limits are available to a tenant. That configuration is established outside ordinary sandbox create requests.
Per-sandbox requests select only public workload behavior:
template_idsizetimeout_secidle_timeout_secalways_onpersistent
Use GET /api/v1/templates as the catalog source.
Select only a size listed for the chosen template as fast_ready or cold_boot_only, and use that template’s default_size when no other supported size is requested. cold_boot_only is valid but slower; missing is unavailable.
The default small resource contract is 2 vCPU, 4096 MiB RAM, and 10240 MiB disk when the selected template advertises it as ready.
Responsibility boundary
| Area | Customer responsibility | MIOSA responsibility |
|---|---|---|
| AWS environment | Account ownership, host capacity, network egress, customer IAM, and customer-controlled infrastructure policy | Document required connectivity and reject environments that do not satisfy acceptance |
| Host operation | Keep the accepted host and its operating environment available and within the agreed configuration | Provide and coordinate miosa_host, session fencing, runtime compatibility checks, and acceptance state |
| Artifacts | Preserve the storage and access prerequisites needed by the accepted host | Publish immutable certified generations and prevent placement when the required generation is absent or invalid |
| Sandbox control | Choose public template, size, lifecycle, and persistence parameters | Resolve versioned resource contracts, enforce policy, schedule only onto accepted hosts, and coordinate lifecycle operations |
| Isolation and access | Control the customer AWS boundary and access to customer infrastructure | Enforce sandbox isolation and avoid exposing internal host or provider details through the public API |
| Usage records | Reconcile usage with customer infrastructure records when required | Report public usage measurements and preserve unavailable or stale measurement semantics |
Availability and limits
BYOC does not imply a guaranteed sandbox count, launch rate, or geographic scale. Actual availability is bounded by accepted customer capacity, certified artifact readiness, tenant policy, and current catalog state. MIOSA will publish measured limits only after they have been validated for the applicable environment.
Managed and accepted BYOC sandboxes use the same customer-visible lifecycle operations, including extend, pause, resume, fork, usage, and destroy. See Sandboxes for request examples and Persistence, pause, and forks for lifecycle behavior.