> ## Documentation Index
> Fetch the complete documentation index at: https://docs.idyl.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Workload isolation

> Understand standard containers, microVM-backed workloads, runtime policy, and compatible provider capacity.

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](/concepts/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 microvm`.                       |
| Operate | Set subnet runtime policy that allows, defaults, or requires isolation classes.               |
| Provide | Configure 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 class | Meaning                                                                                                                       |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `container`     | Standard container isolation. Docker Engine and containerd/runc nodes can satisfy this class.                                 |
| `microvm`       | MicroVM-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

| Term            | Meaning                                                                                                     |
| --------------- | ----------------------------------------------------------------------------------------------------------- |
| Container       | A process-isolation model that shares the host kernel.                                                      |
| MicroVM         | A lightweight virtual machine that gives the workload a guest kernel.                                       |
| VMM             | A virtual machine monitor, such as QEMU or Firecracker, that creates and runs virtual machines or microVMs. |
| KVM             | The Linux kernel virtualization subsystem used by VMMs to run guest kernels efficiently.                    |
| Kata Containers | A 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 profile               | Isolation class | Notes                                                             |
| ----------------------------- | --------------- | ----------------------------------------------------------------- |
| `docker`                      | `container`     | Uses Docker Engine for standard container workloads.              |
| `containerd-runc`             | `container`     | Uses containerd and runc for standard container workloads.        |
| `containerd-kata-qemu`        | `microvm`       | Uses containerd with Kata Containers and the QEMU backend.        |
| `containerd-kata-firecracker` | `microvm`       | Uses 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](/operate/configure-runtime-policy).

## Request microVM isolation

Builders can request microVM-backed execution when the target subnet allows it:

```bash theme={null}
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:

```bash theme={null}
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](/provide/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.

## Related pages

* [Sandboxes](/concepts/sandboxes)
* [Subnets](/concepts/subnets)
* [Pod specs and containers](/concepts/pod-specs)
* [Capacity](/concepts/capacity)
* [Configure runtime policy](/operate/configure-runtime-policy)
* [Configure a node](/provide/configure-a-node)
* [Deploy a workload](/build/deploy-a-workload)