Skip to main content
Configure a node on the machine that will provide capacity to IDYL. The local node config controls the Node’s Network, contribution limits, runtime profile, and service readiness checks for that machine. Start here when you want to choose how the node should run workloads before joining a fleet or subnet. For the full join flow, see Connect a node. For the workload author, subnet operator, and provider node model, see Workload isolation.

​
Operating system support

Use the operating system that matches how the node will be used.
Use Linux for production provider nodes and for secure-container and microvm workload isolation.Install IDYL:
Linux nodes can use Docker Engine, or containerd with runc, gVisor, and Kata Containers when the host has the required runtime installed.
Verify the CLI:

​
Choose a runtime profile

Use --runtime-profile to choose the node’s runtime provider. A profile selects the provider with its default settings. On the containerd profile, runc always serves container. Each stronger class is added by configuring its runtime: The node reports each class only when its runtime passed the node’s checks on the host when the node started. microvm is in preview: no provider host has completed IDYL’s validation for it. A Docker Engine node, or a containerd node without the gVisor runtime configured, does not satisfy secure-container runtime policy. IDYL does not change a requested secure-container or microvm workload to a weaker class when compatible capacity is missing. The options available on a machine are shown by your installed CLI:

​
Initialize local node config

Log in before configuring or joining a node:
Initialize the local node config with a runtime profile:
For a containerd node that serves container and secure-container:
Set the Node’s Network explicitly when the machine should use a specific Network:

​
Limit contributed capacity

Contribution limits are local safety caps. IDYL uses the lower of the machine’s detected capacity and the limits you configure. Set CPU and memory limits:
Set disk and GPU limits when the node should contribute those resources:
View the current local config:
If the node service is already running, restart it for updated contribution limits or runtime settings to take effect.

​
Configure containerd settings

The containerd profile uses the default containerd socket and namespace unless you override them. Use a non-default containerd socket:
Use a non-default containerd namespace:

​
Network classes

On the containerd profile, the none and restricted-egress network classes resolve every name their policy depends on through one explicit DNS resolver. Set it as an IP address with an optional port:
Without a resolver, the node does not offer either network class. Because secure-container and microvm workloads run with none or restricted-egress, set the resolver on every node that serves those classes.

​
Serve secure-container

Install gVisor on the host, then point the node at the gVisor shim configuration. The configuration must run the sandbox on the host network stack of the workload’s network namespace and select a supported platform:
platform can be systrap, which needs no hardware virtualization, or kvm. The node refuses any other network mode or platform.

​
Serve microvm

microvm is in preview. No provider host has completed IDYL’s validation for it, so do not rely on microvm capacity for production workloads.
Install Kata Containers on a Linux host with KVM, then point the node at a Kata configuration that selects QEMU:
The node refuses a Kata configuration that could select a different virtual machine monitor.

​
Apply runtime changes

The host must be prepared before the node starts; IDYL does not install containerd, gVisor, or Kata Containers for you. Pass an empty value to a runtime flag to remove that runtime. Restart the node service after changing runtime settings. If a configured runtime is missing or misconfigured, the node reports a failed readiness check and does not offer that class.

​
Secure the node runtime

In this guide, securing the node runtime means choosing the appropriate isolation profile, limiting contributed resources, validating host readiness, and protecting the local node identity. It is not a remote attestation or confidential-computing claim. Use this checklist before admitting the node to a subnet that handles workloads requiring stronger runtime isolation: For production Linux nodes, render and validate the production service plan before installing or starting the service:
Use the profile and runtimes that match the node:

​
Join after configuration

Join through a fleet:
A node installed as a Linux system service receives its desired state, including software updates, as a Fleet member, so it joins with --fleet. It keeps the runtime profile it was installed with. A node run as a workstation or user service can join a subnet directly:
--display-name sets optional account-owned presentation metadata. It does not change the local node identity or runtime configuration. If you already initialized the node with the desired runtime profile, you can omit --runtime-profile during join:

​
Verify the node

Check local status on the provider machine:
Inspect the node from the subnet:
If a workload does not place on the node, confirm the node is admitted, the runtime serving the workload’s isolation class is ready, the subnet runtime policy matches the workload, and the node has enough available capacity.