Workload isolation

Workload isolation controls the runtime boundary around a workload after it is admitted to a subnet. It is separate from sandbox environments, subnet admission, and control-plane tenancy. 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:

Path	Responsibility
Build	Declare workload isolation intent, such as `--isolation-class secure-container`.
Operate	Set subnet runtime policy that allows, defaults, or requires isolation classes.
Provide	Configure nodes with the runtimes that serve the isolation classes a subnet accepts.

A workload runs with a given isolation class only when the target subnet admits that class and a provider node that serves it has capacity.

Isolation classes

An isolation class names the guarantee a workload can rely on. It does not name a runtime.

Isolation class	Guarantee	Intended use
`container`	Standard container isolation on the host kernel, which the workload shares with other workloads on the node.	Trusted workloads that need the highest compatibility, density, and start speed.
`secure-container`	The workload’s system calls are served by an application kernel running as an isolated process. No workload system call reaches the host kernel directly.	Untrusted code, such as sandboxes, AI agents, and user-submitted code.
`microvm`	The workload runs on its own guest Linux kernel behind hardware virtualization.	Tenant boundaries that call for a dedicated kernel.

Every class is a container execution class. You supply a container image and use the same workload lifecycle, logs, and exec in each class. You never manage virtual machine images, firmware, virtual disks, or hypervisor settings. isolation.class is set on the pod spec. Every container in a pod runs with the same isolation class. To run parts of an application with different classes, run them as separate workloads.

Runtimes

Provider nodes serve each class with a specific runtime:

Isolation class	Runtime	Host requirement
`container`	Docker Engine, or containerd with runc	Linux or macOS for Docker Engine; Linux for containerd
`secure-container`	containerd with gVisor	Linux. No hardware virtualization is required.
`microvm`	containerd with Kata Containers on QEMU	Linux with KVM

Builders request an isolation class on the workload. They do not choose the runtime. Operators decide which isolation classes a subnet accepts. Providers configure nodes with the runtimes that serve those classes. A node reports a class only when that class’s runtime passed the node’s checks on the host when the node started. A runtime that fails its checks is not reported; the node never offers a weaker boundary in its place.

microvm is in preview. No provider host has completed IDYL’s validation for it, so do not rely on microvm capacity for production workloads.

Availability

Capability	`container`	`secure-container`	`microvm`
Registry images, logs, exec, and shells	Available	Available	Preview, on Linux hosts with KVM
Network classes	`unrestricted` on Docker Engine nodes; `none` and `restricted-egress` on containerd nodes	`none` and `restricted-egress`	`none` and `restricted-egress`
GPU access	Available on Docker Engine nodes that report GPU capacity	Not available	Not available
Confidential execution	Not available	Not available	Not available

IDYL places a workload only on a node that offers every capability the workload requests for its isolation class. A request for a capability that no node in the subnet offers for that class does not schedule.

When to request stronger isolation

Use secure-container or microvm 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.
Images with an uncertain supply chain.
Workloads from another account.
Jobs running on private machines or sensitive networks.

secure-container is the default choice for untrusted code. It runs on any Linux host, including cloud instances without hardware virtualization. microvm, in preview, adds a dedicated guest kernel and requires provider hosts with KVM. Runtime policy controls which isolation classes a subnet accepts. Admission controls who can deploy workloads or provide capacity.

Enforce workload isolation

Subnet operators enforce workload isolation with runtime policy. A subnet can:

Allow only secure-container workloads.
Set secure-container as the default isolation class.
Require workload authors to set --isolation-class explicitly.
Allow several classes, such as container and secure-container.

For the full operator workflow, see Configure runtime policy.

Request an isolation class

Builders request an isolation class when the target subnet allows it:

idyl deploy nginx:1.27-alpine \
  --name web \
  --subnet <subnet> \
  --platform linux/amd64 \
  --isolation-class secure-container

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. When --network-class is omitted, IDYL applies a default network class: unrestricted for container, and none for secure-container, microvm, and a workload that states no isolation class. Docker Engine nodes do not serve none, so a workload with neither an isolation class nor a network class does not place on a subnet whose only capacity is Docker Engine nodes. Set --isolation-class container or --network-class unrestricted for such a workload.

Provide isolation capacity

Providers serve secure-container and microvm from Linux nodes on the containerd runtime profile. Each class is added by pointing the node at the runtime’s configuration:

idyl node join --fleet <fleet-id> \
  --runtime-profile containerd \
  --containerd-runsc-config-path /etc/containerd/runsc.toml \
  --containerd-restricted-egress-dns-upstream 192.0.2.53 \
  --start

The host must have the required runtime installed before the node starts. IDYL does not change a requested secure-container or microvm workload to a weaker class when compatible capacity is missing. For the provider workflow, see Configure a node.

Boundaries and guarantees

An isolation class is a placement guarantee, not a cryptographic attestation claim. It means IDYL schedules the workload onto a node that reports a runtime serving that class. It does not, by itself, 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

Request GPU access with the pod-level gpu requirement. GPU workloads run with container isolation on nodes that report GPU capacity. A subnet that accepts only secure-container or microvm does not place GPU workloads.

Terms

Term	Meaning
Container	A process-isolation model that shares the host kernel.
Application kernel	A kernel that runs as an isolated user-space process and serves a workload’s system calls in place of the host kernel. gVisor provides the application kernel for `secure-container`.
Guest kernel	A Linux kernel dedicated to one workload sandbox and run behind hardware virtualization. Kata Containers provides the guest for `microvm`.
KVM	The Linux kernel virtualization subsystem that hardware-virtualized guests run on.

​How workload isolation fits IDYL

​Isolation classes

​Runtimes

​Availability

​When to request stronger isolation

​Enforce workload isolation

​Request an isolation class

​Provide isolation capacity

​Boundaries and guarantees

​GPU workloads

​Terms

​Related pages

How workload isolation fits IDYL

Isolation classes

Runtimes

Availability

When to request stronger isolation

Enforce workload isolation

Request an isolation class

Provide isolation capacity

Boundaries and guarantees

GPU workloads

Terms

Related pages