The exe architecture

Three layers make up exe.dev: a shared edge, a pool of CPU and memory, and local NVMe disks that stream to a second server. Once you understand those three, you can explain almost every product behavior.

This page is drawn from https://exe.dev/docs/architecture, https://exe.dev/docs/what-is-exe, https://exe.dev/docs/faq/how-exedev-works and https://exe.dev/docs/infrastructure.

The request path, end to end

flowchart LR
  B[Browser] -->|HTTPS| LB[Global load balancer<br/>shared IPs, dozens of sites]
  S[SSH client] -->|ssh vm.exe.xyz| LB
  LB --> TP[TLS proxy<br/>routes on SNI + Host]
  LB --> SP[SSH proxy<br/>routes by name]
  TP --> V1[VM: own VMM,<br/>port 80, disk]
  SP --> V1
  TP --> V2[VM]
  subgraph Pool[Your pool: hard CPU/RAM on a server]
    V1
    V2
  end
  V1 -.streams disk changes.-> BK[(Streaming snapshot<br/>on another server<br/>in the regional cluster)]

Layer 1: the edge (shared IPs, TLS and SSH proxies)

exe.dev pools IP addresses because, in its words, “you need a lot of VMs, far more than is reasonable to pay $2/month per IPv4 address.” It does this by “running a TLS proxy that looks at SNI and the HTTPS Host header, and some new tricks for SSH.” The global load balancer for those IPs terminates “at dozens of sites around the world” (https://exe.dev/docs/architecture).

What this means for your design:

• No public IP per VM. Inbound traffic arrives through https://vmname.exe.xyz/ or ssh vmname.exe.xyz (https://exe.dev/docs/faq/how-exedev-works).
• TLS is managed. Certificates for exe.xyz names and for custom domains you register are handled by the proxy (https://exe.dev/docs/proxy, https://exe.dev/docs/cnames).
• SSH routing usually works by hostname. When it doesn’t, ssh vm+my-vm@vm.exe.xyz always works (https://exe.dev/docs/faq/ssh-destination).
• Your app sees forwarding headers. The proxy adds X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-For (https://exe.dev/docs/proxy).

Layer 2: pools (a cgroup of hard CPU and RAM)

“A pool is a set of hard CPU/RAM resources on underlying hardware. (For those familiar with linux, consider it a cgroup.) Inside this pool of CPU/RAM, we manage VMM processes for you: one for each VM you want” (https://exe.dev/docs/architecture).

• VMs share capacity like processes do. The VMs in a pool share its CPU and memory “the way processes do on your computer or Docker containers do on a linux machine”. You decide how they use it.
• Isolation is KVM. “Each VM is KVM-isolated, with its own port 80 and its own disk” (https://exe.dev/docs/enterprise). The hypervisor happens to be Cloud Hypervisor, which exe.dev calls “a bit of an implementation detail (and may change!)” (https://exe.dev/docs/faq/how-exedev-works).
• Who gets pools. Personal accounts get one pool, while Work accounts create as many as they need (https://exe.dev/docs/architecture, https://exe.dev/docs/billing/work).
• Hyperthread sharing in teams. By default a team’s VMs may share the two hyperthreads of one physical core, but “They never share a core with VMs outside the team”. Admins can switch this off with team settings core-sharing off (https://exe.dev/docs/teams/vms).

Layer 3: disks (local NVMe plus streaming durability)

“VM disks run directly on local NVMe. This means you see the sort of high-IOPS performance you are used to on your laptop, not the low-IOPS performance you typically see on a traditional cloud server that puts the disks 1ms RTT away over ethernet” (https://exe.dev/docs/architecture).

For durability, exe.dev says it will “constantly stream changes to your VM disk off machine to another part of the regional cluster. There is a streaming snapshot of your VM, somewhere else in the cluster where it can be rapidly restarted.”

exe.dev states the trade-off openly. This is “a different kind of durability than you get out of a traditional cloud NAS. The tradeoff is IOPS.” When asked about RPO or RTO numbers, say they are not published in the docs [verify with exe.dev].

Disk usage is measured as ext4 filesystem usage. exe.dev also runs fstrim from time to time to reclaim free space (https://exe.dev/docs/faq/disk-usage).

Boot: container image onto a block device

Most clouds boot a VM from a base image. exe.dev “starts with a container image (by default, ‘exeuntu’), and hooks it up with a block device with the image on it. This makes creating a new VM take about two seconds. In exchange, we lose some flexibility: you don’t get to choose which kernel you’re using” (https://exe.dev/docs/faq/how-exedev-works).

Two practical consequences:

• Any image works. new --image=<image> accepts any container image, and the exeuntu Dockerfile is a good starting point (https://exe.dev/docs/customization).
• Private images are pulled host-side. They are pulled “before your VM exists”, so they need --registry-auth (https://exe.dev/docs/private-image).

Where it runs

“exe.dev is a heterogeneous platform. The public product runs on bare metal hosting providers and we rack our own clusters” (https://exe.dev/docs/infrastructure).

The infrastructure sub-processors listed are Amazon Web Services, Google Cloud, Latitude.sh and NetActuate. ClickHouse is listed for log storage and analytics (https://exe.dev/docs/sub-processors, last updated 2026-01-01).

Regions

Source: https://exe.dev/docs/regions. Each account has a region, which you can change with set-region. VMs in a pool run in the pool’s region. “The lobby (main exe.dev server) is located in the United States for all accounts.”

Networking between VMs

“VMs, even within one account, are isolated from each other. There is not a ‘private network’ which connects them” (https://exe.dev/docs/faq/cross-vm-networking). There are three supported ways to connect them:

1. Tailscale. Users run it themselves, and there is also a Tailscale workload identity federation integration (https://exe.dev/docs/integrations).
2. SSH. Forward your agent or register extra keys.
3. A VM-to-VM integration. Use integrations add http-proxy --peer. Requests arrive with an attested X-Exedev-Source-Vm header (https://exe.dev/docs/integrations-http-proxy).

Outbound traffic

VM egress can be limited to integrations only, or left open with egress <vm> integrations|all. DNS is served at 169.254.169.254 (https://exe.dev/docs/internet-access).

Whiteboard this

The request path board turns this page into a five-step drawing.