DIY Cloud
Everything you pay a PaaS for — build, deploy, route, scale, TLS — on hardware you already own. heyvm turns a Dockerfile into a bootable Firecracker micro-VM image; heyctl puts that image behind your own load balancer and hands you back a URL with a live, autoscaling pool behind it. No cluster. No YAML sprawl. One box, or a rack of them.
You rent a cloud to run software you wrote
App hosting, a managed database, hosted CI, a sandbox platform for your agents. Each one is a fine product and a permanent line item, and every one of them bills idle capacity like peak. Add them up and you are paying rent, forever, on a cloud whose only tenant is you.
The usual escape hatch is Kubernetes, which trades the bill for a second job. 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.
Dockerfile to URL in three commands
Build the image
heyvm builds a bootable micro-VM rootfs from the Dockerfile you already have. The result is a file you keep, push to your own artifact store, and boot anywhere in about 120ms.
Register a deployment
Give heyctl a hostname, an image, and a port. It routes the traffic, terminates TLS, and boots a pool of micro-VMs sized to the min/max band you set.
Let the pool breathe
The autoscaler watches in-flight requests, keeps warm spares ready, recycles unhealthy VMs, and drops idle pools to zero so they cost nothing until the next request.
Ship the next version
One command builds from a git ref and rolls the pool onto the result with no dropped requests. Every image lands in your store, so a rollback is a pull of the previous digest.
# 1. Build a bootable micro-VM image from your Dockerfile heyvm mvm build -f Dockerfile -n web-app ✓ Image "web-app" ready # 2. Put it behind your own load balancer heyctl create deployment web --host web.example.com \ --image web-app --port 8080 --min 1 --max 4 ✓ Deployment "web" created · warm standby # 3. Watch the pool converge heyctl rollout status web ✓ 1/1 ready · micro-VM booted in 120ms · https://web.example.com # Later: tune the policy in place, ship the next commit heyctl scale web --warm 1 --scale-to-zero-after 300 heyctl build web --ref main --wait --logs ✓ build succeeded · pool rolling · 0 dropped requests
Postgres, agents, and the app on the same metal
A deployment is anything you can put in a Dockerfile. Give it a public route or leave it private; give it a floor of one or let it sleep at zero. The database, the agent fleet, and the web tier are three specs on one load balancer — reachable by name on your private network, and nothing faces the open internet unless you route it there.
# A private Postgres that scales to zero between queries heyctl create deployment pg --no-route \ --image pg --port 5432 --min 0 --max 8 --disk-gb 50 # An agent pool with no ingress — reached only by exec and shell heyctl create deployment agents --no-route \ --image agent --size medium --min 0 --max 32 # The public tier heyctl create deployment app --host app.example.com \ --image app --port 8080 --min 1 --max 4 heyctl get deployments NAME ROUTE POOL READY STATE pg (none) 0/8 0 scale-to-zero agents (none) 0/32 0 scale-to-zero app app.example.com 1/4 1 serving # Run something inside a pool, or drop into a shell heyctl exec agents -- claude -p "triage the backlog" heyctl top
Three kinds. One control plane.
Managed pool
A micro-VM template plus a scaling policy. The load balancer boots and reaps the pool to match load — warm standby, cold start budget, drain timeout, all yours to set.
Proxy pass
A fixed set of upstreams you already run — another service, a NAS, a box down the hall. Least-in-flight balancing with failover, and health probes that let a recovered upstream rejoin.
Static site
A directory on the host, served straight
off disk. Index files, a custom 404, SPA
fallback — what nginx’s
root or a CloudFront origin
does, without either.
Secrets go in by name and never come back out.
Sign-in can sit in front of any deployment, once,
for all of them. And because the whole thing runs
on your side of the wire,
heyctl top shows exactly what the
box is doing.
Renting a PaaS vs. running your own
A hosted platform is the right answer for one app you never want to think about. It becomes the wrong answer the moment you have a database, a fleet of agents, and a build pipeline — because each of those is now its own product with its own meter.
Renting a PaaS
- Every service is a separate bill that scales with usage
- Idle capacity is billed like peak capacity
- Their runtime shapes your stack; their pipe ships it
- Your images, data, and build history live in their region
A heyo DIY cloud
- One box runs Postgres, agents, apps, and CI
- Scale-to-zero pools wake on demand and cost nothing idle
- Any Dockerfile, any stack; you own the load balancer
- Images are files you keep, move, and roll back
Same stack on a home server, a rack, or Heyo
machines — anywhere with
/dev/kvm. Wondering how this stacks
up next to Modal, Northflank, or E2B?
See the head-to-head →
Build your cloud
First deployment behind your own load balancer in minutes. Your hardware, your network, your rules.