Skip to main content
Customers’ code runs on your machine, inside VMs. The agent installs and boots only software Runcrate signed, and it only connects out, so nothing on your network has to accept a connection. Each VM can reach the internet and nothing of yours, and every GPU check tests that. When a rental ends, the VM’s disk and its GPUs’ memory are wiped. The last section lists every file the agent adds.

​
Only signed software

Runcrate signs every release offline with an ed25519 key. The installer checks the agent’s signature with openssl before it installs anything, and the installer itself is signed the same way. The agent carries the same public key: it only installs an update that Runcrate signed and that is newer than the one running, and only boots a VM image Runcrate signed. A compromised download server can’t push code to your machine. The previous agent stays at /usr/local/bin/runcrate-host.prev.

​
Outbound HTTPS only

The agent calls Runcrate every 10 seconds over HTTPS with the machine’s state and gets back its commands: start a VM, stop one, take back a spot GPU, drain, benchmark, update. Nothing on your network needs to accept a connection, so the machine can sit behind NAT. Customers reach their VM through an outbound tunnel the VM opens to Runcrate, not through your network. The one exception: while a benchmark runs on two or more machines on the same site, iperf3 (and ib_write_bw with InfiniBand) listens on their private addresses for up to 5 minutes, open only to the site’s other machines.

​
How customer VMs are isolated

Every customer workload runs in a KVM virtual machine with its GPUs passed through. Customers never get a shell on your machine.
  • Each VM has its own network. A tap device and a /30 from 10.254.0.0/16, with no shared layer 2 between VMs.
  • Internet only. The firewall (nftables table inet runcrate_host) lets a VM reach the internet through NAT and nothing else: not your machine, not other VMs, not private, link-local or carrier NAT ranges. Nothing from outside can open a connection into a VM.
  • Watched, not set and forgotten. The firewall is re-applied every 5 seconds. Whenever the agent isn’t running (stopped, crashed, updating or removed), every VM’s network is set down, so isolation never depends on a firewall nobody is watching.
  • One host service. The only thing on your machine a VM can reach is the metadata server at 169.254.169.254, which answers each VM only about itself.
  • Your firewall stays yours. If Docker or ufw set the FORWARD policy to DROP, the agent adds two narrow accept rules for its own rc-* interfaces. If IPv4 forwarding was off before the install, the agent drops any other forwarding, so your machine doesn’t start routing for anything else. To keep VMs away from more ranges, add them to blocked_cidrs in /etc/runcrate-host/config.json.

​
Isolation checks

The GPU check boots a throwaway VM that tries to reach what a customer VM must and must never reach, on your machine and your network: Meanwhile your machine checks the other direction: a throwaway network namespace, routed through your machine the way a computer on your LAN would be, tries to open a connection to the VM and must fail. Each result, with what it tried, shows on the machine’s page in the dashboard. Re-run them at any time with Re-run check.

​
After every rental

When a rental ends, the agent stops the VM, overwrites its disk with zeros and deletes it. Then it boots a throwaway VM that overwrites the memory of the GPUs before they can be rented again.

​
What the agent can and can’t see

The agent can see:
  • the hardware: CPU, RAM, disk space, PCI devices, network cards and their speeds, and private IPv4 addresses (reported to group machines on a site);
  • the VMs it runs: their size, state and GPUs;
  • each customer’s setup script, which it hands to the VM in its boot seed (root only, deleted with the VM).
The agent doesn’t look inside VMs. It doesn’t read customer disks, memory, network traffic or GPU contents. Runcrate receives GPU health, VM states, load, the benchmark results and the hardware details above. GPU temperature and utilization are not reported, because the GPUs are inside VMs where the host can’t read them.

​
What you, as root, could see

An administrator can always read the memory and disk of VMs running on hardware they control. Runcrate doesn’t pretend otherwise. Customers are protected from you by your agreement with Runcrate, which forbids opening, inspecting or copying a VM, its memory, its disks or its traffic, and by the wipe after every rental. You are protected from customers by keeping their code inside VMs with no route into your network.

​
What the agent installs

The installer adds the packages QEMU/KVM, OVMF, nftables, genisoimage and iperf3 (and perftest when InfiniBand is present). It creates the unprivileged runcrate-vm user, and the agent adds one more user per VM slot (runcrate-vm-<slot>), so each VM’s QEMU runs confined as its own user. Then it writes these files:
  • /usr/local/bin/runcrate-host: the agent.
  • /etc/runcrate-host/: its config, config.json, and the machine’s credential, credential. Root only.
  • /var/lib/runcrate-host/: VM disks, the base image and the agent’s state. Root only.
  • /etc/systemd/system/: the agent’s service, runcrate-host.service, and runcrate-host-gpus.service, which moves the GPUs you gave Runcrate to vfio-pci at boot so no host driver takes them.
  • /etc/modules-load.d/: runcrate-host.conf, which loads the KVM and VFIO modules at boot.
  • /etc/modprobe.d/: runcrate-host-vfio.conf, only when Runcrate has every GPU, so vfio-pci claims them before any host driver.
  • /etc/udev/rules.d/: 90-runcrate-host.rules, which gives group kvm access to /dev/vhost-net.
  • /etc/default/grub.d/: 90-runcrate-host.cfg, only if the installer turned on the IOMMU.
Uninstalling removes all of it except the packages.

​
Useful commands

sudo runcrate-host status lists each VM’s id. To read a VM’s serial console, its last 1 MB, run sudo runcrate-host console with that id.