A cloud of your own.
On metal you can touch.
Right now your apps, your agents, and your CI all rent time in someone else’s cloud — and the bill scales with everything you do. Heyo cuts that stack down to two tools: heyvm turns a Dockerfile into a bootable Firecracker micro-VM image, and heyctl deploys it behind your own load balancer — autoscaling pools, warm standby, one command to a URL. Same stack on your home server, your rack, or Heyo machines.
Three primitives. No platform.
A public cloud is thousands of products because it has to serve everyone. A cloud you run for yourself needs exactly three things — images that boot, a pool that scales, and a network that connects them — and nothing else.
Micro-VM Images
heyvm builds a bootable Firecracker rootfs from any Dockerfile. The result is a file you keep, push to your own artifact store, and boot anywhere in about 120ms.
Deployment Pools
heyctl puts an image behind your own load balancer: autoscaling pools, warm standby, scale-to-zero, TLS, and routing — on whatever box runs it.
Hosted Intranet
One private network across your metal and your cloud. Services find each other by name; nothing faces the open internet unless you route it there.
The DIY cloud
Everything you pay a PaaS for — build, deploy, route, scale — on hardware you already own. Build the image once, hand it to the load balancer, and get back a URL with a live pool behind it. Postgres runs the same way: a deployment with no public route that scales to zero between queries.
# Dockerfile to deployed micro-VM in three commands heyvm mvm build -f Dockerfile -n web-app ✓ Image "web-app" ready heyctl create deployment web --host web.example.com \ --image web-app --port 8080 --min 1 --max 4 ✓ Deployment "web" created · warm standby heyctl rollout status web ✓ 1/1 ready · micro-VM booted in 120ms · https://web.example.com
No YAML sprawl, no cluster to babysit. The load
balancer meters traffic, recycles unhealthy VMs,
and pauses idle pools — and
heyctl top shows you exactly what
your box is doing.
Build your DIY cloud →
Agent fleets on bare metal
Per-seat sandbox pricing punishes the thing agents are best at: parallelism. On your own metal, a fleet is just a deployment — one agent image, a pool that scales to zero when the queue is empty, and a fresh micro-VM around every agent so a misbehaving one can’t touch its neighbors.
# One agent image, a pool that wakes on demand heyvm mvm build -f agent/Dockerfile -n agent ✓ Image "agent" ready heyctl create deployment agents --no-route \ --image agent --min 0 --max 32 ✓ Deployment "agents" created · scale-to-zero · no public route # Each command lands in its own isolated micro-VM heyctl exec agents -- claude -p "triage the backlog" heyctl shell agents
Thirty-two agents working in parallel costs the same as one: the electricity your box was already drawing. Snapshot the image when you get the environment right, and every agent in the fleet boots into it. Run headless agents →
Own your CI/CD
The metered runner is the most expensive computer you rent, and the slowest to start. Run the loop on your own hardware instead: a clean sandbox per branch for tests, then one command that builds the image from your checkout and rolls the pool onto it — build, deploy, and rollback all on your side of the bill.
# A clean sandbox per branch — off the metered runner heyvm wt feat/payments -b ✓ Sandbox "feat/payments" ready heyvm exec feat/payments -- npm test ✓ 42 passed # Green? Build from the ref and roll the pool onto it heyctl build web --ref feat/payments --wait --logs ✓ build succeeded · pool rolling · 0 dropped requests
Every build artifact lands in your own store, so a rollback is a pull of the previous digest — not a support ticket. See the full CI/CD loop →
Four ways teams put it to work
Stateful machines you mount into, snapshot, and fork — on hardware you own.
Local CI/CD →A clean sandbox per branch. The whole build-test-ship loop, off the metered runner.
DIY Cloud →Dockerfile to a URL behind your own load balancer, on your own metal.
Remote Agents →Trigger from anywhere — even a phone — while the compute stays yours.
Rent the cloud, or run your own
Managed databases, sandbox platforms, hosted CI, app hosting — each one is a fine product and a permanent line item. They add up to a cloud you rent forever for software you wrote yourself. The DIY cloud is the other path: the same primitives, running as files and pools on a box with your name on it.
Renting the cloud
- Every service is a separate bill that scales with usage
- Idle capacity is billed like peak capacity
- Agents get throwaway sandboxes priced per seat
- Your images, data, and build history live in their region
Running your own
- One box runs Postgres, agents, apps, and CI
- Scale-to-zero pools wake on demand and cost nothing idle
- A fleet of 32 agents costs the same as 1
- Images are files you keep, move, and roll back
Wondering how this stacks up next to E2B, Modal, Daytona, Northflank, or Microsandbox? See the head-to-head →
Build your cloud
First deployment behind your own load balancer in minutes. Your hardware, your network, your rules.