Cua Docs

Sandbox runtime support

Versioned image, runtime, customization, and transport support for the Sandbox SDK.

This reference describes the Python Sandbox SDK in cua-sandbox 0.4.3, exported by cua 0.1.6. An accepted image specification or generated Fleet template is evidence of SDK behavior, not proof that a guest boots on every host or deployment.

Operating systems and image kinds#

Local execution uses local=True. Fleet execution uses managed pools and claims. The same guest OS can have different image formats, runtime requirements, and available operations on those two paths.

Image inputGuest and kindLocal runtime selectionFleet SDK acceptance in 0.4.3Verification boundary
Image.linux()Ubuntu 24.04 VMBare-metal QEMU; requires qemu-system-x86_64Maps to a built-in registry artifactMapping and runtime selection checked; host and Fleet boot not tested here
Image.linux(kind='container')Ubuntu 24.04 containerDockerRejected; no built-in Fleet mappingConstructor and rejection checked; Docker image readiness not tested here
Image.linux('ubuntu', '22.04')Ubuntu 22.04 VMBare-metal QEMURejected; no built-in Fleet mappingRuntime selection alone does not establish a usable boot image
Image.windows()Windows Server 2022 VMHyper-V when available on Windows; otherwise Docker-wrapped QEMU, or bare-metal QEMU when Docker is unavailableMaps to a built-in registry artifact; template selects EFIMapping and firmware selection checked; deployment boot not tested here
Image.windows('11')Windows 11 VMWindows runtime selection; local ISO installation pathRejected; no built-in Fleet mappingRequires a suitable host, installation media, and guest setup
Image.macos() / Image.macos('15')macOS 26 / 15 VMLume on a compatible Apple silicon hostRejected as built-in Fleet inputsConstructor and selection checked; no macOS Fleet deployment established
Image.android()Android 14 VMAndroid emulatorRejected as a built-in Fleet inputConstructor and selection checked; emulator boot not tested here
Image.from_registry(...)Explicit guest OS and optional kindSet kind='vm' or pass a compatible runtime when kind is unresolvedRegistry reference acceptedAcceptance does not validate artifact contents, registry access, guest support, or readiness
Image.from_file(...)Disk or ISO with explicit guest OSCompatible local VM runtimeRejectedFormat and guest requirements depend on the runtime

The built-in registry mappings in 0.4.3 are:

Built-in imageRegistry artifact
Ubuntu 24.04 VMpublic.ecr.aws/k5j5w0x5/cua-ubuntu-24.04:main-38352d34
Windows Server 2022 VMpublic.ecr.aws/k5j5w0x5/cua-windows-2022:main-bac7daa3

These are versioned tags selected by the package. Use an immutable digest when artifact identity must remain fixed independently of a registry tag.

Windows firmware#

In released 0.4.3, FleetCloudTransport generates Firmware.EFI when image.os_type == 'windows'. The earlier claim that Windows always receives the default BIOS template does not apply to this release. This mapping does not prove that a particular account, registry artifact, or Fleet deployment can boot it.

Image.from_registry() defaults to os_type='linux' and kind=None; it does not inspect the disk to infer its OS. For a Windows VM artifact, specify os_type='windows', kind='vm'.

Image customization#

OperationLocal executionFleet execution in 0.4.3
Package and setup layers, including apt_install(), pip_install(), and run()Applied through local image setup; commands must match the guest OSRejected
env() and copy()Applied through local image setupRejected
expose()Backend-specific startup port mapping; bare-metal QEMU returns mappings in sb.exposed_portsDeclares named services on the pool template
Prebuilt registry artifactRequires a compatible runtime and bootable guest payloadAccepted as the boot artifact; software must already be installed
Sandbox.snapshot()Not implementedNot implemented; snapshot-derived image inputs are also rejected

The package retains snapshot code on its legacy CloudTransport. That does not enable snapshots on local connections or pool-backed Fleet connections.

Fleet customization means preparing and publishing a compatible guest artifact before pool creation. See Prepare and reference a Fleet image.

Ports and transports#

Sandbox connectionsb.tunnel.forward() in 0.4.3Connection behavior
Local VM through HTTPTransportNot implementedUse the runtime's startup mapping where available, such as bare-metal QEMU's sb.exposed_ports
Fleet pool claim through base FleetTransportNot implementedUse sb.services.request() for authenticated requests to a named service
SSH or ADB transportImplemented by those transportsForwarding depends on the transport; ADB also accepts Android socket names

Pool.claim(), Sandbox.create(pool=...), and the Fleet image path of Sandbox.ephemeral(image) all return the base FleetTransport. For persistent Fleet sandboxes, Sandbox.create(image) rejects a registry image without an explicitly named pool. Apply the pool first, then claim from it.

The older FleetCloudTransport class implements a numeric-port helper, but its presence in the package does not make that helper available on the pool-backed creation paths above. A method on the common Sandbox interface does not establish support on all transports.

Fleet service URLs require authentication. sb.services.request() uses the Fleet connection's authenticated lease. The lower-level Python Fleet SDK's request_service() sends authenticated service requests; the TypeScript SDK exposes serviceRequest(). A URL alone does not grant access. See Fleet pool credentials and Sandbox SDK interfaces.

The Fleet image path of Sandbox.ephemeral() in 0.4.3 accepts only the default region='us-east-1'; Pool.apply() has no region argument. Registry access, account permissions, resource limits, capacity, and readiness are deployment requirements that SDK validation cannot establish.

Evidence and limits#

The contracts above were checked against these public release artifacts:

Verification covers released source and offline contract checks. It does not include provisioned Fleet boots, authenticated service requests, local VM or container boots, or a deployment-wide operating-system certification. Specific recipe observations, such as the Windows Minecraft workflow, describe their own tested environment and do not broaden these guarantees.