Skip to main content
Workload isolation controls the runtime boundary around a workload after it is admitted to a subnet. It is separate from sandbox environments, subnet admission, control-plane tenancy, and confidential computing. For temporary environments such as previews, agent workspaces, demos, or customer-specific deployments, see Sandboxes.

​
How workload isolation fits IDYL

Workload isolation is coordinated across workload authors, subnet operators, and provider nodes:
PathResponsibility
BuildDeclare workload isolation intent, such as --isolation-class microvm.
OperateSet subnet runtime policy that allows, defaults, or requires isolation classes.
ProvideConfigure nodes with runtime profiles that can satisfy the subnet policy and workload intent.
A workload can request stronger isolation only when the target subnet admits that isolation class and compatible provider capacity is available.

​
Isolation classes

IDYL uses isolation classes to describe the requested workload boundary:
Isolation classMeaning
containerStandard container isolation. Docker Engine and containerd/runc nodes can satisfy this class.
microvmMicroVM-backed workload runtime. Containerd with Kata Containers and an explicit Kata backend profile can satisfy this class.
A standard container shares the host kernel. This is the common path for trusted workloads, broad compatibility, and GPU workloads that depend on host driver integration. A microVM-backed workload runs behind a stronger runtime boundary. The workload runs with a guest kernel, while the virtual machine monitor and host virtualization boundary sit beneath that guest environment.

​
Terms

TermMeaning
ContainerA process-isolation model that shares the host kernel.
MicroVMA lightweight virtual machine that gives the workload a guest kernel.
VMMA virtual machine monitor, such as QEMU or Firecracker, that creates and runs virtual machines or microVMs.
KVMThe Linux kernel virtualization subsystem used by VMMs to run guest kernels efficiently.
Kata ContainersA runtime integration that can run container workloads inside VM or microVM boundaries.
If you are looking for sandboxed execution or sandboxed workloads in the runtime sense, use the workload isolation model described on this page.

​
When to request stronger isolation

Consider microVM-backed execution when the source, behavior, or operating context of the workload calls for stronger separation from the host than a standard container provides, such as:
  • Third-party containers.
  • AI agent workloads.
  • User-submitted code.
  • Supply-chain uncertain images.
  • Workloads from another account.
  • Jobs running on private machines or sensitive networks.
Runtime policy controls which isolation classes a subnet accepts. Admission controls who can deploy workloads or provide capacity.

​
Runtime options

Provider nodes report runtime metadata through runtime profiles:
Runtime profileIsolation classNotes
dockercontainerUses Docker Engine for standard container workloads.
containerd-runccontainerUses containerd and runc for standard container workloads.
containerd-kata-qemumicrovmUses containerd with Kata Containers and the QEMU backend.
containerd-kata-firecrackermicrovmUses containerd with Kata Containers and the Firecracker backend.
Builders request an isolation class on the workload. They do not choose the provider node runtime profile. Operators decide which isolation classes and Kata backends a subnet accepts. Providers configure nodes with compatible runtime profiles.

​
Enforce workload isolation

Subnet operators enforce workload isolation with runtime policy. A subnet can:
  • Allow only microvm workloads.
  • Set microvm as the default isolation class.
  • Require workload authors to set --isolation-class explicitly.
  • Allow both container and microvm workloads.
  • Restrict microvm capacity to specific Kata backends, such as QEMU or Firecracker.
For the full operator workflow, see Configure runtime policy.

​
Request microVM isolation

Builders can request microVM-backed execution when the target subnet allows it: 
idyl deploy nginx:1.27-alpine \
  --name web \
  --subnet <subnet> \
  --platform linux/amd64 \
  --isolation-class microvm
If the subnet has a default isolation class, the workload can inherit that default. If the subnet has runtime policy without a default, the workload must set --isolation-class explicitly.

​
Provide microVM-capable nodes

Providers use runtime profiles to configure the isolation class a node can satisfy. For a microVM-capable Linux node: 
idyl node join --subnet <subnet> --runtime-profile containerd-kata-qemu --start
The host must have the required runtime dependencies before the node starts. IDYL does not change a requested microvm workload to container isolation when compatible capacity is missing. For the provider workflow, see Configure a node.

​
Boundaries and guarantees

microvm is an isolation class, not a cryptographic attestation claim. It means IDYL schedules the workload for a node that reports a compatible microVM runtime path. It does not, by itself, prove confidential-computing execution or prove that a provider cannot observe or affect a workload. Pair runtime isolation with appropriate controls for network access, secrets, provider admission, device access, and audit requirements.

​
GPU workloads

GPU workloads usually require a different default. Common GPU stacks depend on host driver integration and device access. For that reason, GPU workloads commonly use standard container isolation unless the operator and provider have validated a microVM-backed GPU path for that subnet. MicroVM-backed GPU execution is an advanced provider-specific configuration. It depends on device passthrough, driver support, IOMMU configuration, runtime support, and subnet policy. Do not assume a node that satisfies GPU container workloads also satisfies microvm runtime policy.