> ## Documentation Index > Fetch the complete documentation index at: https://runcrate.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # What runs on your machine > How customer VMs are kept away from your network, what the agent can and can't see, and every file it installs. 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](#what-the-agent-installs) 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: | Check | Passes when the VM | | - | - | | Internet | reaches `https://www.runcrate.ai` | | DNS | resolves `www.runcrate.ai` | | Metadata | reaches the metadata server at `169.254.169.254` | | The VM's gateway | can't connect to the host side of its own link | | Your machine | can't connect to any of your machine's own addresses | | Your router | can't connect to your machine's default gateway | | Docker | can't connect to the Docker bridge, when there is one | | Private ranges | can't connect into `10/8`, `172.16/12` or `192.168/16` | | Carrier NAT | can't connect into `100.64/10` | | Link-local | can't connect to `169.254/16` other than the metadata server | 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](https://runcrate.ai/docs/hosts/install.md#what-the-installer-does) 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-`), 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](https://runcrate.ai/docs/hosts/uninstall.md) removes all of it except the packages. ## Useful commands ```bash wrap theme={"theme":{"light":"github-light","dark":"catppuccin-mocha"}} # Config, GPUs and VMs on this machine sudo runcrate-host status # The agent's log, live sudo journalctl -u runcrate-host -f ``` `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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.