Configure runtime policy

Use subnet runtime policy when a subnet should accept only specific workload isolation classes, such as secure-container for untrusted code. For the builder, operator, and provider model, see Workload isolation. Runtime policy is enforced at the subnet boundary. It controls workload admission and node eligibility for scheduling. It does not grant provider admission by itself, and it is separate from deploy approval.

How runtime policy works

IDYL keeps three concepts separate:

Concept	Example	Controlled by
Subnet runtime policy	`allowedIsolationClasses: ["secure-container"]`	Subnet operator
Workload isolation intent	`--isolation-class secure-container`	Workload author
Node runtime configuration	`--runtime-profile containerd --containerd-runsc-config-path /etc/containerd/runsc.toml`	Provider node operator

The supported isolation classes are:

Isolation class	Guarantee	Served by
`container`	Standard container isolation on the shared host kernel.	Docker Engine, or containerd with runc
`secure-container`	An application kernel serves every workload system call; none reaches the host kernel directly.	containerd with gVisor
`microvm`	A dedicated guest Linux kernel behind hardware virtualization.	containerd with Kata Containers on hosts with KVM

Runtime policy names isolation classes only. It never names a runtime or a virtual machine monitor, so a subnet’s policy stays valid as provider nodes change their runtime installations. An isolation class is not a cryptographic attestation claim. It means IDYL schedules the workload onto a node that reports a runtime serving that class.

Choose a policy

Policy	Use it when
No runtime policy	The subnet should not apply a subnet-level isolation rule.
`secure-container` with a default	Most workloads in the subnet run untrusted code, and workload authors may omit `--isolation-class`.
Strict `secure-container`	Every workload author must explicitly request `--isolation-class secure-container`.
`microvm` only (preview)	Every workload in the subnet needs a dedicated guest kernel, and the subnet’s providers run hosts with KVM.
Several classes	The subnet accepts, for example, `container` and `secure-container`, and each workload states the intended isolation class.

Create a subnet with runtime policy

Create a subnet with no runtime policy:

idyl subnet create --region us-east

Create a secure-container subnet with defaulting. Workloads that omit --isolation-class inherit secure-container:

idyl subnet create \
  --region us-east \
  --allowed-isolation-class secure-container \
  --default-isolation-class secure-container

Create a strict secure-container subnet. Workloads must explicitly request --isolation-class secure-container:

idyl subnet create \
  --region us-east \
  --allowed-isolation-class secure-container

Create a microvm subnet with defaulting. microvm is in preview: no provider host has completed IDYL’s validation for it, so use it for evaluation rather than production workloads:

idyl subnet create \
  --region us-east \
  --allowed-isolation-class microvm \
  --default-isolation-class microvm

Create a subnet that allows both container and secure-container workloads:

idyl subnet create \
  --region us-east \
  --allowed-isolation-class container \
  --allowed-isolation-class secure-container

You can also pass allowed classes as a comma-separated list:

idyl subnet create \
  --region us-east \
  --allowed-isolation-class container,secure-container

Update an existing subnet

Set or replace runtime policy:

idyl subnet edit <subnet> \
  --allowed-isolation-class secure-container \
  --default-isolation-class secure-container

Clear runtime policy:

idyl subnet edit <subnet> --clear-runtime-policy

When you set a policy, --allowed-isolation-class is required. --default-isolation-class is optional, but when present it must be one of the allowed isolation classes.

Verify the policy

Inspect the subnet:

idyl subnet get <subnet> -o yaml

Output similar to:

slug: "100000000001"
region: us-east
status: active
runtimePolicy:
  allowedIsolationClasses:
    - secure-container
  defaultIsolationClass: secure-container

List subnets:

idyl subnet list

When a subnet has a runtime policy, table output includes a runtime policy summary. Structured output includes the runtimePolicy object.

Workload admission behavior

When a workload is created in a subnet with runtime policy, IDYL resolves the effective isolation class in this order:

If the workload sets --isolation-class, IDYL uses that explicit value.
Otherwise, if the subnet sets defaultIsolationClass, IDYL uses the subnet default.
Otherwise, if the subnet has runtime policy but no default, IDYL rejects the workload because an isolation class is required.

The effective isolation class must be listed in allowedIsolationClasses. This workload is accepted by a secure-container subnet:

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

This workload is accepted only when the subnet has defaultIsolationClass: secure-container:

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

This workload is rejected by a secure-container-only subnet:

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

The error message includes:

isolation.class "container" is not allowed by subnet runtimePolicy

When a subnet has runtime policy but no default, a workload that omits --isolation-class is rejected with a message that includes:

isolation.class is required by subnet runtimePolicy

Coordinate compatible capacity

Runtime policy does not install runtimes or approve provider capacity. Provider nodes must still be admitted to the subnet, and each node must report a runtime that serves the classes the policy allows. Provider nodes serve classes through their runtime configuration:

Node configuration	Isolation classes it serves
`--runtime-profile docker`	`container`
`--runtime-profile containerd`	`container`
`--runtime-profile containerd` with `--containerd-runsc-config-path`	`container` and `secure-container`
`--runtime-profile containerd` with `--containerd-kata-config-path`	`container` and `microvm` (preview), on hosts with KVM

Join a node that serves secure-container through a Fleet:

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

A node can be admitted to a subnet but still fail to contribute compatible capacity for a workload. For example, a Docker Engine node, or a containerd node without the gVisor runtime configured, does not satisfy secure-container policy. Inspect connected nodes:

idyl node get --subnet <subnet>

On the provider node, inspect local runtime readiness:

idyl node status

Scheduling behavior

After a workload passes admission, the scheduler uses the effective isolation class and the isolation classes each node reports. A workload is placed only on a node that reports its isolation class. IDYL does not place a secure-container or microvm workload with a weaker class. Runtime selection belongs to node configuration; a workload never names a runtime. If no compatible node is available, the workload remains unplaced until compatible capacity is available. Runtime compatibility errors include the requested isolation class, for example:

no available nodes in subnet <subnet> support requested isolation class secure-container

Resource shortage errors do not include an isolation class compatibility reason:

no nodes available in subnet <subnet> with sufficient capacity and generic requirements

Troubleshooting

Symptom	What to check
Workload is rejected with `isolation.class is required by subnet runtimePolicy`	The subnet has runtime policy but no default. Add `--isolation-class` to the workload or set `--default-isolation-class` on the subnet.
Workload is rejected with `isolation.class "container" is not allowed`	The workload requested an isolation class that is not in `allowedIsolationClasses`.
Node is admitted but workloads do not schedule there	Confirm the node’s runtime configuration serves the workload isolation class and that `idyl node status` reports the runtime as ready.
`secure-container` workloads do not place	Confirm the subnet has admitted at least one containerd node with the gVisor runtime configured and available capacity.
`microvm` workloads do not place	Confirm the subnet has admitted at least one containerd node on a host with KVM, with the Kata Containers runtime configured and available capacity.
`container` workloads do not place	Confirm the subnet has admitted healthy Docker Engine or containerd capacity.

​How runtime policy works

​Choose a policy

​Create a subnet with runtime policy

​Update an existing subnet

​Verify the policy

​Workload admission behavior

​Coordinate compatible capacity

​Scheduling behavior

​Troubleshooting

​Related guides