Docs
PricingConsole

Isolation claims

Last updated 2 November 2026

View .md

Machines are not open yet. These pages describe Machines as they will open; until then, a create answers region_not_offered (422), “Machines are not offered in any region yet.”

Read this when you review Machines for security: it states Tonbo’s isolation claims exactly, and links the mechanism behind each.

CL1 to CL7 are Tonbo’s signed claims, word for word; the table under them says how each is enforced, and explains their terms where they first matter. Isolation guarantees says the same in a user’s words.

The claims

  • CL1 Jailed microVM. Each activation runs in its own KVM microVM. Firecracker runs under the jailer as a non-root, capability-less, seccomp-filtered process, in its own chroot, mount, PID and network namespaces and cgroup.
  • CL2 Network. A guest reaches nothing on the host or in the VPC except:
    • replies to connections the host opened;
    • Tonbo's DNS stub;
    • the cell's fixed internal Streams entry.

    It reaches the internet only through the cell's Machines NAT gateway, or Amazon S3 in its region through the cell's S3 gateway endpoint, over IPv4. It never reaches the instance metadata service, any private, link-local, shared or other non-public range, the node port (7470), the kubelet (10250), the Ursula ports (4437–4439) or SMTP (25, 465, 587).

  • CL3 Residue. No byte of one activation's disks or memory is readable by a later activation on the host.
  • CL4 Resources. A guest cannot exhaust host resources other activations need. Memory is never overcommitted; CPU, I/O, pids and network are bounded.
  • CL5 Credentials. Credentials live only in node memory, only for the activation's life (node-v1 N6).
  • CL6 Usage. Usage is measured on the host, and a guest cannot change it.
  • CL7 Release. The node runs only artifacts listed in the reviewed release lock.

Not claimed:

  • resistance to microarchitectural side channels beyond the host kernel's defaults;
  • resistance to a host-kernel 0-day (only its blast radius is bounded, NET3);
  • availability across host loss.

Where each claim is enforced

ClaimMechanism
CL1Each guest, the virtual machine one activation (one wake) runs in, is a Firecracker process: the jailer starts each in its own chroot and namespaces, with no capabilities, under Firecracker’s seccomp filters (the kernel’s seccomp), on hosts set up as Firecracker recommends (see The microVM).
CL2The host’s rules for each guest’s network device, the region’s NAT gateway for Machines and its S3 gateway endpoint, and a block on the instance metadata service (see Network path).
CL3Every wake boots fresh on new disk files, and the kernel gives a new virtual machine only zeroed memory.
CL4Each virtual machine’s cgroup bounds its CPU, I/O and processes, its network device is rate-bounded, and a host admits no more memory than it has.
CL5N6, the rule that the node, Tonbo’s agent on each host, keeps the credentials it is given only in its memory and drops them when the wake ends; the guest gets its token in a memory-backed file.
CL6The host reads the virtual machine’s cgroup counters and its scratch drive from outside the guest (see Metering and holds).
CL7The reviewed release lock: the list, with checksums, of the host software each release runs, changed only through a reviewed change.
NET3The network layers outside the host that bound what a flaw in the host’s kernel could reach: the network rules of the region’s private cloud network (the VPC) for the subnets of the cell, the hosts that run Machines in the region, and the NAT gateway above.