exe.dev vs. Kubernetes with Qovery: Where Agent VMs End and Production Begins

Key points:

• exe.dev is a cloud of persistent VMs built for agents. You buy a pool of CPU and RAM, from $15 a month for 2 vCPU / 4 GB, and run up to 50 VMs in it on Personal or 1,000 per pool on Work. Each VM boots in about two seconds with root, Docker, an HTTPS URL and a coding agent (exe.dev).
• It is excellent for agent work: one VM per task, cloned with cp, secrets injected at the network edge so the agent never sees them, sandboxes billed by the second.
• Its Work plan is pitched "for teams who want to run production workloads" (exe.dev). For long-running services, the gaps are the parts a single VM cannot provide: replicas behind a load balancer, rolling deploys, health checks, horizontal autoscaling, a private network between services and a managed database. exe.dev documents none of these, and its 99.9% SLA covers Enterprise contracts only.
• Kubernetes provides all of them, but someone has to run it. That is the job Qovery does. It runs your services on Kubernetes in your own AWS, GCP, Azure or Scaleway account (or any existing cluster), and coding agents deploy through its MCP server, CLI and skills.
• The two fit together. Let agents build on an exe.dev VM, and ship what they build to a cluster you own. For a hobby service, stay on exe.dev: it is cheaper.

On exe.dev, one SSH command gives you a persistent Linux VM with root, an HTTPS URL and a coding agent already running inside it. The team includes David Crawshaw, Tailscale co-founder and its CTO from 2019 to 2024 (exe.dev), and you can tell. I like the product. After 15+ years in cloud infrastructure, "give each agent a real computer" is the cleanest answer I have seen to where coding agents should run.

exe.dev also wants to be where software runs after the agent is done. Its Deploy gallery lists 97 recipes: Claude Code, Codex and OpenClaw, but also n8n, Postgres, Redis, Rails, Next.js, Uptime Kuma and migrations off Heroku and Railway. Its Work plan says it is for production workloads. So CTOs now ask me a fair question: if an agent can build and host the app on the same VM, why run Kubernetes at all? This post is my answer, with exe.dev's documented facts on one side and Kubernetes with Qovery on the other.

What is exe.dev?

exe.dev, built by Bold Software, Inc., sells a pool of CPU and RAM, and you run as many VMs as fit in it. It calls itself "a private computer for your agents". The public developer preview opened on 15 December 2025 (exe.dev blog), and the company announced a Series A in April 2026, bringing total funding to $35 million (exe.dev blog). It runs on its own bare-metal fleet, load balancers and DNS, not on top of a hyperscaler.

The facts that matter for a production decision, checked on 9 November 2026 (exe.dev has changed its pricing twice this year, so check again before you decide):

What is exe.dev best at?

Anything that needs a computer for one task, one person or one agent:

• Coding agents in parallel. One VM per task or worktree, each isolated with root and Docker. Clone a known-good VM with cp, throw it away after.
• Untrusted, agent-written code. A sandbox with egress limited to integrations cannot reach the internet or read a key, because the keys live at the edge.
• Demos instead of pull requests. Share a running app by link, with exe.dev login in front of it.
• Personal and small-team tools. A Slack bot, a dashboard, a link shortener, an n8n instance that sends you a morning digest. exe.dev's own guide suggests running dev, test and prod on one VM for this kind of app (exe.dev).

For all of these, Kubernetes is overkill and I would say so to a customer. Local NVMe gives the IOPS that builds and test suites want. The edge-injected secrets solve a real agent risk, and the price is hard to beat.

What does a long-running production service need on top of a VM?

The test is what happens on a bad day: a host dies, a deploy ships a bug, traffic triples, an auditor asks where customer data lives. Take three apps from exe.dev's gallery that teams often promote to production: a customer-facing Rails or Next.js app with Postgres, an n8n instance that now routes leads and billing events, and an OpenClaw agent the support team relies on.

On exe.dev, each one is a VM with the app and its database side by side. The n8n recipe, for example, runs n8n, PostgreSQL 18 and nginx in Docker Compose on one VM and writes nightly backups to that same VM. The recipe itself says "a backup on a lost VM won't help much" and tells you to copy them off (exe.dev). That is careful, honest work, and it is still a single failure domain.

Here is how a single exe.dev VM, Kubernetes you run yourself and Kubernetes with Qovery handle a bad day:

None of this is a flaw in exe.dev. A VM is a VM, wherever it runs, and exe.dev's docs are honest about it. A developer running Rails on exe.dev in production described it as: "It's not HA; no failover, and there's little backup, but it works" (asadjb.com). On the Hacker News launch thread, Crawshaw answered a pricing question plainly: if one VPS covers your needs, "the exe pricing model is not going to bring you much value" (HN). The product is designed around many VMs for agents.

exe.dev vs. Qovery: what is the actual difference?

They solve different problems, which is why a head-to-head can mislead. exe.dev gives you computers. Qovery is an Agentic DevOps platform that runs and operates Kubernetes in your own cloud account so your team, and its agents, can ship services without a dedicated DevOps engineer.

Plan details are on exe.dev pricing and Qovery pricing.

What does each option cost for a small production app?

Take a small SaaS backend: an API, a background worker, Postgres and Redis, sized at about 8 vCPU and 16 GB in total. Prices are list prices, AWS us-east-1 on-demand, as of November 2026. Your discounts and credits will change the AWS side.

Sources: EKS, EC2, RDS for PostgreSQL, ElastiCache, Elastic Load Balancing, VPC.

exe.dev Personal wins on price, and for a side project that settles it. Against exe.dev Work, Kubernetes on your own account costs about the same and adds Multi-AZ database failover, replicas and autoscaling. The fixed costs (control plane, NAT, load balancer) are shared by every service you add next, and the bill sits in your account, where Savings Plans, spot instances and AWS credits apply. The hidden line in the do-it-yourself column is the engineer who keeps the cluster healthy. Qovery's plans exist to remove that line.

Can you use exe.dev and Qovery together?

Yes, and I think that is the most useful setup for a team that builds with agents. The agent works on an exe.dev VM. When the code is ready, it deploys to your cluster through Qovery, where the service gets replicas, probes, a managed database and a preview environment per pull request.

exe.dev's HTTP proxy integration keeps the Qovery credential off the VM. Create a Qovery API policy token (in preview) whose policy allows only one project, then attach it at the edge:

ssh exe.dev integrations add http-proxy --name qovery \
  --target https://api.qovery.com/ \
  --header "Authorization:Token <scoped-qovery-token>" \
  --attach vm:my-agent-vm

From the VM, the agent calls https://qovery.int.exe.xyz/ and never sees the token. Or connect the Qovery MCP server to the agent and ask it to "deploy this app on our AWS account with Qovery, with a managed Postgres and a preview environment per pull request". Every action goes through Qovery's API, is limited by the token's policy and lands in the audit log for a human to review in the Console.

How do you decide where a service should run?

Ask these about the service, not the tool:

1. If it is down for four hours on a Saturday, does anyone outside your team notice? If not, an exe.dev VM is fine.
2. Does it hold data you would have to explain losing? Customer records, credentials and billing state need a managed database with point-in-time recovery, not a dump on the same disk.
3. Does its load vary? Queues, webhooks and traffic spikes need horizontal autoscaling.
4. Does a contract or an auditor care where it runs? Then it belongs in an account you own, with IAM and logs you control.
5. Will other services join it? From three or four long-running services, a shared cluster costs less per service and gives you one way to deploy everything.

If the answer to any of questions 2 to 4 is yes, move the service. Keep the exe.dev VM as the agent's workshop, and run the result on Kubernetes in your own account. You can try the Qovery side for free on a cluster you already have, or locally with qovery demo up.

Frequently asked questions

What is exe.dev?

exe.dev is a cloud of persistent virtual machines built for AI agents and developers. You buy a pool of CPU and RAM and run many VMs inside it, each with root access, Docker, local NVMe storage, an HTTPS URL and a built-in coding agent called Shelley. It launched in December 2025 and is built by a team that includes Tailscale co-founder David Crawshaw.

Is exe.dev good for production?

For small, non-critical services, yes. exe.dev supports custom domains and persistent disks, and its Work plan is aimed at production workloads. It does not document load balancing across VMs, health checks, rolling deploys or horizontal autoscaling, VMs have no private network between them, and the 99.9% SLA is for Enterprise contracts only. For customer-facing services, use infrastructure that provides those.

What is the difference between exe.dev and Kubernetes?

exe.dev gives you individual VMs that you or your agent manage like computers. Kubernetes schedules containers across a cluster of machines and handles replicas, health checks, rolling updates, autoscaling and service networking for you. exe.dev is faster to start and cheaper for one service; Kubernetes is built to keep many services running through failures and load changes.

Is exe.dev a Qovery alternative?

Only partly. Both let coding agents get software running, but exe.dev hosts VMs on its own hardware, while Qovery deploys and operates services on Kubernetes in your own cloud account. Many teams would use exe.dev as the agent workspace and Qovery to run production.

What happens to an exe.dev VM if its host fails?

exe.dev copies disk changes to other machines in the region and keeps a recent snapshot that can be restarted elsewhere. It does not publish a recovery point objective or say whether the restart is automatic. Data written after the last copy may be lost, which matters for a database on the VM.

How do I move an app from an exe.dev VM to Kubernetes?

Containerize the app if it is not already, move its database to a managed Postgres with a dump and restore, put secrets in a secret store, then deploy with replicas, health probes and an ingress. With Qovery, a coding agent can run the deployment through the MCP server or CLI on your AWS, GCP, Azure or Scaleway account, and you review the result in the Console.