exe.dev ▶ doc how-exedev-works
How exe.dev works (how-exedev-works) - press q to exit
You're an engineer. We're engineers. Let's talk about what's going on under the hood.
An "exe.dev" VM runs on a bare metal machine that exe.dev rents. We happen to use Kata Containers and Cloud Hypervisor, but that's a bit of an implementation detail (and may change!).
With most providers, your VM starts with a "base image" and is given a block device. Exe.dev instead starts with a container image (by default, "exeuntu"), and hooks up an overlay filesystem to the VM. This makes creating a new VM
take about two seconds. In exchange, we lose some flexibility: you don't get to choose which filesystem you're using, nor which kernel you're using.
On the networking side, 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.The two constraints are that, one, when small underlying resources are expensive (we hope to fix that soon by not being small!), and two, we do not want to make the resource allocation so small that the VM feels unpleasant to use. So there is a floor on how small we make them.
That said, I very very much want to drop prices. We started with conservative numbers.
``` ssh exe.dev Please complete registration by running: ssh exe.dev Connection to exe.dev closed. ```
The threat is having a private key stolen, in which case, having multiple keys can mitigate the amount of damage a threat actor can do. However, to steal your private key would involve a successful attack against your client, not against any server you might have given the public key to.