WHITEBOARD / BOARD: REQUEST PATH
Board: the request path
The goal is to explain how thousands of VMs answer on HTTPS and SSH without a public IP for each one.
Whiteboard outcome
When you’re done, the board shows a browser and an SSH client, the shared edge (global load balancer, TLS proxy, SSH proxy), the auth decision, a pool holding two VMs, and the streaming disk copy.
Before you draw: three questions
- Is the app meant for the public, a team, or a single person?
- Does it need a custom domain?
- What port does it listen on?
Draw it in 8 steps
- On the left edge, draw a laptop with two arrows: “HTTPS https://app.exe.xyz” and “ssh app.exe.xyz”. Say: “Every VM gets a name. There’s no IP to manage.”
- Draw a wide rounded rectangle labeled “exe.dev edge: shared IPs, dozens of sites”. Say: exe.dev shares IPs because, in its words, a lot of VMs would be “far more than is reasonable to pay $2/month per IPv4 address” (https://exe.dev/docs/architecture).
- Inside it, draw two boxes, “TLS proxy (SNI + Host)” and “SSH proxy”. Say: “TLS and certificates are handled for you” (https://exe.dev/docs/proxy).
- Draw a diamond labeled “Who’s allowed?” with three exits: “private (owner + shares)”, “team”, and “public (
share set-public)”. Say: “New VMs start private. Making one public takes a single command” (https://exe.dev/docs/sharing). - On the right, draw a dashed rectangle “Pool: 4 vCPU / 8 GiB, LAX” with two VM squares inside. Say: “The VMs share the pool’s CPU and memory the way processes share a machine. Each one is KVM-isolated with its own disk” (https://exe.dev/docs/architecture).
- Draw an arrow from the TLS proxy to a VM labeled “port 80 (or
share port), + X-Forwarded-*, X-ExeDev-Email”. Say: “Your app learns who the user is from headers, so you don’t build a login page” (https://exe.dev/docs/login-with-exe). - Below each VM, draw a cylinder labeled “local NVMe”, with a dashed arrow to “streaming snapshot, other server”. Say: “You get laptop-speed IOPS, and the changes stream off the machine” (https://exe.dev/docs/architecture).
- At the bottom, write the rule: “One name per VM. The edge does TLS and auth. One public port per VM.” Circle “one public port”.
flowchart LR
L[Laptop / browser] -->|HTTPS app.exe.xyz| E
L -->|ssh app.exe.xyz| E
subgraph E[exe.dev edge: shared IPs]
T[TLS proxy<br/>SNI + Host]
S[SSH proxy]
end
T --> A{Who's allowed?<br/>private / team / public}
A -->|port 80 + X-ExeDev-Email| V1
S --> V1
subgraph P[Pool 4 vCPU / 8 GiB, LAX]
V1[VM app]
V2[VM worker]
end
V1 -.stream.-> D[(Snapshot on<br/>another server)]What they’ll ask
| Question | Answer | Source |
|---|---|---|
| “Can I get a static IP?” | No. Traffic arrives through the shared edge by name. Use a custom domain CNAME. | https://exe.dev/docs/faq/how-exedev-works, https://exe.dev/docs/cnames |
| “Other ports?” | 3000 to 9999 are forwarded for users with access. Only one port can be public. | https://exe.dev/docs/proxy |
| “Does it work behind Cloudflare?” | Use DNS only (grey cloud), or a Snippet/Worker that rewrites Host. The proxied orange cloud breaks routing. | https://exe.dev/docs/cnames |
| “Can VMs talk privately?” | There’s no private network. Use Tailscale, SSH or a VM-to-VM integration. | https://exe.dev/docs/faq/cross-vm-networking |
| “Next.js or Vite dev server is blocked?” | Allow the exe.xyz host in the dev server config. | https://exe.dev/docs/faq/nextjs-and-friends |