What exe.dev is

exe.dev gives you Linux VMs that boot in about two seconds. Each one gets a persistent disk, HTTPS out of the box, and SSH access. You pay for a pool of CPU and memory and run as many VMs in it as fit.

That is the short version. The rest of this page is the longer version you can give in a meeting, using exe.dev’s own words where possible.

The 30-second version

exe.dev says it is “a cloud for your company’s agentic software: the agents your developers build with, and the VMs that software runs on once it’s built” (https://exe.dev/docs/enterprise). In practice:

• A VM is just a computer. You get a real Linux VM with sudo and a persistent disk. There is no serverless runtime to fit your code into. In exe.dev’s words, “It’s just a computer, after all” (https://exe.dev/docs/lockin).
• HTTPS with no setup. Every VM is served at https://vmname.exe.xyz/ with TLS handled by exe.dev’s proxy. It stays private until you share it (https://exe.dev/docs/proxy).
• The API is SSH. ssh exe.dev opens a REPL, and every command in it is scriptable. The same commands also run over an HTTPS API and an MCP server (https://exe.dev/docs/api, https://exe.dev/docs/https-api, https://exe.dev/docs/mcp).
• You buy capacity, not individual VMs. Plans sell a pool of CPU and memory, and you run as many VMs in it as fit (https://exe.dev/docs/pools, https://exe.dev/pricing).
• A coding agent is included. Shelley runs on every VM created from the default image (https://exe.dev/docs/shelley/intro).

The two-minute version

Fast VMs with persistent disks

Most providers boot a VM from a base image onto a block device. exe.dev instead “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.” The trade-off is that you can’t choose the kernel (https://exe.dev/docs/faq/how-exedev-works).

The disk lives on the server’s local NVMe and is “streamed continuously to another server in the region so it survives the loss of a machine” (https://exe.dev/docs/enterprise). exe.dev says outright that it builds against the serverless model: “your VM comes with a normal, boring file system. Run a database on it. Write logs to it. Use sqlite” (https://exe.dev/docs/serverful).

A shared front door, not a public IP per VM

“We don’t give your VM its own public IP. Instead, we terminate HTTPS/TLS requests, and proxy them securely to your VM’s web servers. For SSH, we handle ssh vmname.exe.xyz” (https://exe.dev/docs/faq/how-exedev-works). That one decision brings several things with it:

• managed TLS
• private-by-default sites
• sharing by email or link
• built-in login headers that tell your app who is visiting (https://exe.dev/docs/login-with-exe)

Capacity pools

The founders’ design note says why: “We want to buy CPU, memory, and disk, and run the VMs we want” (https://exe.dev/docs/what-is-exe). Here is what a pool does:

• What you reserve: a pool reserves vCPUs and memory, and the VMs inside it share that capacity (https://exe.dev/docs/pools).
• Work plan: you get unlimited pools in any region, and each pool holds up to 1,000 VMs (https://exe.dev/docs/billing/work).
• Standalone VMs: these are the exception. They are billed per second and get their own capacity (https://exe.dev/docs/standalone-vms).

Built for agents

The same design that suits humans suits coding agents:

• Isolation: each VM is isolated by KVM.
• Secrets stay off the VM: Integrations inject credentials at the network edge, so “secrets never land on the VM where an agent could read them” (https://exe.dev/docs/enterprise, https://exe.dev/docs/integrations).
• Agents come pre-installed: the default image ships with claude, codex and pi (https://exe.dev/docs/upgrade-codex).
• Built-in coding agent: Shelley is exe.dev’s own web-based coding agent (https://exe.dev/docs/shelley/intro).

Who it is for

These use cases come from exe.dev’s docs and editorials:

The vocabulary you need

• Lobby. The main exe.dev server you reach with ssh exe.dev, where you create, list and share VMs. It is in the United States for all accounts (https://exe.dev/docs/regions, https://exe.dev/docs/api).
• exeuntu. The default VM image. Its Dockerfile is open source at https://github.com/boldsoftware/exeuntu (https://exe.dev/docs/lockin).
• Pool. Reserved CPU and memory shared by many VMs (https://exe.dev/docs/pools).
• Standalone VM. A VM outside any pool, metered per second at $0.105 per 2 vCPU/4 GiB unit-hour (https://exe.dev/docs/standalone-vms).
• exe.xyz. The domain where VMs live: vmname.exe.xyz for HTTPS and SSH, and name.int.exe.xyz for integrations (https://exe.dev/docs/proxy, https://exe.dev/docs/integrations).
• Shelley. exe.dev’s coding agent. It listens on port 9999 at https://vmname.shelley.exe.xyz/ (https://exe.dev/docs/shelley/intro).

See the full glossary.

Facts people get wrong

1. “Each VM gets an IP.” It doesn’t. VMs sit behind exe.dev’s TLS and SSH proxies (https://exe.dev/docs/faq/how-exedev-works).
2. “VMs are on a private network together.” They aren’t. “VMs, even within one account, are isolated from each other. There is not a ‘private network’ which connects them.” Users bring Tailscale, SSH, or VM-to-VM integrations (https://exe.dev/docs/faq/cross-vm-networking, https://exe.dev/docs/integrations-http-proxy).
3. “Disk is ephemeral like a container.” It isn’t. The disk is persistent and streamed to a second server in the region (https://exe.dev/docs/enterprise).
4. “Pricing is per VM.” Mostly not. You pay per pool, by capacity. Standalone VMs are the metered exception (https://exe.dev/docs/billing/overview).
5. “You have to use Shelley.” You don’t. Other agents run fine, and Shelley can be disabled with sudo systemctl disable --now shelley.service (https://exe.dev/docs/shelley/intro).

Where to go next

• How it is built: Architecture
• How much it costs: Economics
• Proving it in an hour: POC