Exe Dev

Summary

exe.dev is a hosted service that creates persistent Linux virtual machines in about two seconds. It is useful as a remote home for coding agents, development servers, databases, prototypes, and small hosted applications.

• Product: exe.dev
• Core model: Many VMs share a paid pool of CPU, memory, disk, and transfer, or use metered resources.
• Default image: exeuntu, an Ubuntu-derived image maintained by exe.dev.
• Status checked: 2026-07-14

Problem

An autonomous coding agent needs time, root access, a real network, and a durable filesystem. Running it on a laptop risks local files and stops when the laptop sleeps.

exe.dev gives the agent a separate remote computer that can keep working. It is like renting a locked workshop across town: the work continues when you go home, and only the materials placed there are exposed.

How It Works

• Real VM: Each instance uses KVM-backed virtual-machine isolation with its own kernel and disk, rather than a shared-kernel container.
• Host infrastructure: VMs run on bare-metal machines rented by exe.dev. Current docs name Cloud Hypervisor but warn that this detail may change.
• Fast creation: A container image becomes the VM root filesystem and is connected to a persistent block device. The provider claims creation takes about two seconds.
• Persistent machine: Files stay on disk when a VM stops. Stopping releases active CPU and memory back to the shared pool.
• Root access: Users receive a normal Linux machine and can install tools or run services.
• No public IP: exe.dev brokers SSH and terminates HTTPS at its proxy before forwarding traffic to the VM.
• Access methods: SSH, a browser terminal, an HTTPS API, and the official JavaScript SDK.
• Images and cloning: Users can start from exeuntu or another Docker image. Sandbox-oriented product material says VMs can be cloned for separate agent runs.

Security Boundary

• Separate kernel: Guest root is contained by a VM boundary, which protects the laptop and other guests better than an ordinary container.
• Remote location: The VM has no direct access to laptop files, credentials, or local network unless the user copies or connects them.
• Key-only SSH: Password login is disabled. Account SSH keys authorize access.
• Private web access: The HTTPS proxy requires exe.dev login by default. A user must explicitly make one selected port public.
• No exposed ports: The VM has no public IP; inbound web traffic goes through exe.dev’s proxy. SSH is also brokered.
• Secrets outside the VM: Integrations can add credentials to outbound HTTP calls after they leave the guest.
• Important limit: Official pages reviewed do not describe an outbound deny-by-default firewall. A remote VM reduces access to local data, but readable guest data may still be sent over its real network.
• Persistent compromise: Malicious files or startup changes survive a stop. Rebuild, clone from a trusted base, or delete untrusted VMs when persistence is unwanted.
• Provider trust: exe.dev controls the host, proxy, disks, identities, and integrations. Users must trust its service and operations.

Platforms And Agents

• Client platforms: Any computer or tablet with SSH, a browser, or an API client can manage a VM.
• Guest: Linux only. Users cannot select a custom kernel.
• Preinstalled agents: Current docs list Claude Code, Codex, Pi, and exe.dev’s browser-based Shelley agent on new exeuntu VMs.
• Other agents: Any agent that runs on Linux can be installed.
• Remote access: A browser session makes it possible to monitor an agent from a tablet or phone while another computer is asleep.

Setup

1. Connect to ssh exe.dev and register an email address and SSH key.
2. Create a VM through the SSH management interface, web interface, HTTPS API, or JavaScript SDK.
3. Connect to the named VM over SSH or open its browser terminal.
4. Clone or copy the repository and authenticate only the services the work needs.
5. Run a preinstalled agent or install another Linux agent.
6. Stop the VM to keep its disk while returning active capacity to the pool.

VM creation accepts a name, container image, initial command, disk size, CPU, memory, environment values, and an initial Shelley prompt. Passing secrets as environment values makes them visible inside the guest; integrations are safer when available.

Network And Credentials

• Inbound web: exe.dev supplies an HTTPS hostname and certificates. Access is private by default; one chosen port can be made public. Authenticated users can reach additional proxied ports from 3000 through 9999.
• SSH: The platform brokers SSH by hostname and accepts registered public keys only.
• GitHub: A per-repository GitHub App integration supports private clones and gh commands without storing a personal access token in the VM. It can act as the app or, for personal integrations, as the user.
• HTTP proxy: An integration can inject a bearer token, basic authentication, or another header into calls to a fixed upstream service. The secret stays at exe.dev’s proxy.
• Cloud identity: Official docs list AWS and Google Cloud workload identity integrations that use short-lived identities instead of fixed keys.
• LLM access: Managed, user-key, and ChatGPT-backed model integrations are supported. Shelley token prices follow model-provider rates without a stated markup.
• Peer VMs: A proxy integration can create a scoped VM-to-VM credential and identify the source VM.
• Risk: Proxying a credential prevents direct key theft, but an agent may still misuse the permitted service. Scope each integration to the smallest repository, API, VM, or cloud role.

Pricing

Official prices checked 2026-07-14:

• Personal pooled plan: $20 per month; up to 50 VMs, 100 GB pooled disk, 200 GB transfer, and a displayed baseline of 2 vCPU / 8 GB memory.
• Team pooled plan: $25 per user per month; up to 50 VMs per user, 100 GB pooled disk, 250 GB transfer, team administration, and shared burst capacity.
• Reserved Cloud Pool: From $35.84 per hour in the displayed 512 vCPU / 2,048 GB configuration; thousands of VMs, 500 GB disk, 2 TB transfer, SSO, and AWS VPC integration.
• Pooled overages: $0.08perGB-monthofdiskand$0.05 per GB of added transfer.
• Usage plan: $0.05percore-hour,$0.016 per active GB-hour of memory, and $0.08 per GB-month of disk. An inactive VM has no CPU charge and memory falls to the disk rate.
• Example from exe.dev: A continuously busy 2-core, 8 GB, 25 GB VM for 30 days is estimated at $166.16 on usage pricing.

Prices can change. Confirm the official pages before budgeting.

Strengths

• Keeps working: A remote agent continues while the laptop sleeps or disconnects.
• Strong host separation: A separate VM kernel keeps agent root away from the developer’s machine.
• Low-friction start: One SSH entry point creates and manages machines.
• Persistent disk: Dependencies, repositories, databases, and agent state survive stops without manual snapshots.
• Many machines per plan: Pooled pricing encourages one VM per project or task instead of one crowded server.
• Browser access: A tablet or phone can check long-running work.
• Credential proxy: GitHub and HTTP integrations keep supported keys outside agent memory.
• Built-in hosting: Private-by-default HTTPS makes previews and small applications easy to share.
• Portable Linux: Normal files and services can often move elsewhere with standard copy tools.

Limits

• Cloud custody: Source and copied data live on third-party infrastructure.
• No offline use: Internet or service outages block access.
• No custom kernel: Starting from a container image does not provide kernel choice.
• No public IP: General inbound protocols do not get the same simple exposure as HTTPS and brokered SSH.
• Outbound controls unclear: The reviewed docs emphasize secret injection and inbound protection, not a strict destination allow-list comparable to Clawk or Vercel Sandbox.
• Persistent risk: Agent damage survives unless the VM is replaced or restored from a trusted source.
• Shared capacity: Pooled CPU and memory are not described as dedicated per VM; performance can depend on pool use and provider controls.
• Cost shape: The $20 pool is attractive for many small VMs, but metered continuous workloads can be much more expensive.
• Young service: Public product documentation and features are still changing.
• Security history: exe.dev publishes bulletins. One medium-severity issue fixed in February 2026 exposed all HTTP ports to recipients of a shared VM instead of only the selected port.

Activity And Maturity

Checked 2026-07-14:

• Current service: Public, paid, multi-region product with personal, team, and large-pool plans.
• Regions: Los Angeles, New York, Dallas, Frankfurt, Tokyo, Sydney, Singapore, and London accept or host accounts; Portland was not accepting new accounts.
• Recent changes: May 2026 release notes added default Reflection integration, custom-domain allow-listing, and larger CPU/memory resize options.
• Security response: A public security bulletin page and disclosure email exist, but there is no bounty program.
• Open-source boundary: Supporting projects and images have public repositories, but the reviewed sources do not present the complete hosted platform as open source.
• Assessment: More mature than a personal sandbox prototype and already useful for ongoing development, but younger and less independently documented than major cloud VM platforms.

Best Fit

exe.dev best fits a developer or small team that:

• wants coding agents to work continuously away from a laptop;
• wants a full, persistent Linux machine rather than a short job runner;
• regularly creates many project, branch, or agent environments;
• values SSH and browser access more than a large cloud control panel;
• needs private previews and credential-proxy integrations;
• accepts third-party hosting and a monthly subscription.

It is a weaker fit for confidential code that cannot leave the laptop, strict outbound data-loss prevention, custom-kernel work, offline development, or public non-HTTP services requiring their own address.

Comparison

• Versus Clawk: Clawk is local and mounts an existing worktree into a disposable, deny-by-default VM. exe.dev is remote, persistent, stays online without the laptop, and includes hosted HTTPS plus service integrations. Clawk keeps source local; exe.dev avoids laptop access entirely.
• Network safety: Clawk filters outbound destinations below the guest. exe.dev’s clearest differentiator is keeping supported credentials at a proxy, but reviewed docs do not establish the same general outbound allow-list.
• Versus Vercel Sandbox: Both are hosted VM environments with credential proxying. Vercel focuses on programmatic, time-bounded untrusted-code execution and large fleets; exe.dev feels like a durable Linux computer with SSH, persistent disk, and fixed pooled pricing.
• Versus E2B and short-lived sandboxes: exe.dev emphasizes automatic disk persistence, built-in HTTPS authentication, and use as both an agent machine and a hosted server. Short-lived sandboxes often provide stronger disposal semantics and task APIs.
• Versus a cloud VPS: exe.dev removes public-IP, certificate, SSH-hardening, and per-server billing work. A standard VPS offers more infrastructure choice, static networking, and mature cloud controls.
• Versus a Mac Mini: A home server may be cheaper over several years and keeps custody local. exe.dev avoids hardware, electricity, remote-access setup, and maintenance while offering many isolated VMs immediately.

HN Context

In HN thread 48892859:

• Remote continuity: skybrian preferred a remote Linux VM because laptop agents stop when the laptop sleeps. They reported an exe.dev agent working while they used a tablet and said they could also check from a phone.
• Cloud isolation: nzoschke gave another vote for cloud sandboxes because they run continuously and remain separated from the laptop.
• Credential proxy: The same commenter highlighted exe.dev integrations that let a sandbox use GitHub or Stripe without giving the agent the raw key.
• Buy versus build: They judged 50 VMs for $20 per month cheaper than building and maintaining a Mac Mini setup.
• Counterpoint: trencedamp noted that $20permonthis$240 per year and could buy a used Mac Mini, while also raising the risk of future price increases.

The useful choice is therefore not only isolation strength. It is whether the user prefers local ownership and setup work or paid remote continuity and managed credentials.

Direct Sources

• https://exe.dev/
• https://exe.dev/docs/what-is-exe
• https://exe.dev/docs/faq/how-exedev-works
• https://exe.dev/docs/use-case-agent
• https://exe.dev/docs/boxes
• https://exe.dev/docs/proxy
• https://exe.dev/docs/section/3-integrations
• https://exe.dev/docs/integrations-github
• https://exe.dev/docs/integrations-http-proxy
• https://exe.dev/docs/regions
• https://exe.dev/docs/billing/overview
• https://exe.dev/pricing
• https://exe.dev/usage-pricing
• https://exe.dev/security
• https://exe.dev/sandbox
• https://news.ycombinator.com/item?id=48892859
• https://news.ycombinator.com/item?id=48893748
• https://news.ycombinator.com/item?id=48894410
• https://news.ycombinator.com/item?id=48903488

Unknowns

• Independent audit: No exe.dev VM-isolation audit or penetration-test report was found in the reviewed official material.
• At-rest encryption: The reviewed pages do not clearly explain disk encryption, key ownership, backup retention, or secure deletion.
• Outbound firewall: A general per-VM destination allow-list or deny-all control was not found in the reviewed docs.
• Recovery: Backup, point-in-time restore, and clone retention guarantees need confirmation for important data.
• Availability target: No formal uptime service-level target was found in the reviewed pages.
• Resource guarantees: Pooled CPU and memory contention, throttling, and exact active-memory enforcement are not fully quantified publicly.
• Platform source: Public images and integrations do not establish that the hosted control plane or VM manager is fully open source.

Sources

• • imported AI research note for Exe Dev.