Heyo Web Services

Everything above the VM, as binaries you run

HWS is shaped like the platforms agents already know — deployments, replicas, routes, secrets, namespaces, tokens — but every piece is a single binary on hosts you control, configured by environment variables. The source is on GitHub.

Dockerfile in, microVM out

Every workload is a Firecracker or KVM microVM (or an Incus container) whose image you build from the Dockerfile you already have, with heyvm. HWS adds everything above the VM.

Images live in art, a content-addressed blob store built for ext4. A blob’s only name is the sha256 of its bytes, so a tag is something you move and a digest is something you roll back to.

# Build a bootable rootfs from your Dockerfile
heyvm mvm build --local-only -f Dockerfile -n web-v2

# Push it to your artifact store
heyctl artifact push --image web-v2

# Point a deployment at the store and roll the pool
heyctl set artifact web --store /srv/artifacts --ref web-v2
heyctl pull web --wait

# Roll back: pin exact bytes by digest
heyctl pull web --ref <digest>

Read the artifacts docs →

The edge, the autoscaler, and the control plane

app-lb is one Rust process built on Pingora. It terminates HTTP and HTTPS, routes each request by host and path, and boots, health-checks, drains, and reaps microVMs to match the traffic each deployment is getting. Its admin API and dashboard run deployments, secrets, builds, artifact pulls, and certificates.

A pool can sleep at zero. When a request arrives at an empty pool, app-lb boots a VM and holds the request until it is healthy.

• Automatic TLS — set an ACME email and every exact host route gets a Let’s Encrypt certificate, renewed 30 days before expiry. Wildcards over DNS-01.
• Builds from git — a build block runs heyvm mvm build on the host and rolls the pool onto the result.
• Candidate-first rollouts — new replicas boot unrouted, cut over only when healthy, and the old ones drain.
• Private by default — a deployment with no routes is still autoscaled and reachable with exec and shell. The normal shape for an agent sandbox.

# A public pool that sleeps at zero
heyctl create deployment web --host web.example.com \
    --image web-v2 --port 8080 --min 0 --max 4

# Tune the policy in place; the pool keeps running
heyctl scale web --warm 1 --scale-to-zero-after 600
heyctl rollout status web

# Ship the next commit
heyctl build web --ref main --logs

Read the app-lb docs →

A SIEM in the load balancer

Security monitoring is on by default. app-lb analyzes every request off the request path, so detection never slows traffic, and raises alerts with ECS field names. Alerts ship to app-obs; the /siem console shows each finding with a runbook and a pre-filled block rule.

Block and allow rules are enforced on the data plane and persist across restarts. Match on client address or CIDR, host, deployment, path, method, or user agent; give a rule an expiry; and try a broad one in dry-run mode first, where it counts hits but refuses nothing.

# Block a source for an hour
curl -XPOST localhost:9090/security/rules -H 'content-type: application/json' \
  -d '{"action":"block","match":{"client":"203.0.113.9"},"expires_in_secs":3600}'

Read the security monitoring docs →

CI on your own metal, a fresh microVM per job

Agents push dozens of times an hour. Paying a metered runner to cold-start for each one, while your source and secrets take a trip through someone else’s datacenter, is the slow way. ci runs the pipeline on runner hosts you own: any machine running heyvmd in a heyvm network, with no agent to install.

# Check workflows offline, no database or broker needed
ci --check-workflows .ci/workflows/build.yml

# Submit HEAD, or include uncommitted tracked changes
git submit
git submit --dirty

# Run just one workflow
git submit --only app-lb

Read the ci docs →

Logs, latency, and errors with no code changes

app-obs runs next to app-lb and follows every managed VM’s console and start output straight from the heyvm daemon — no shipper or agent inside the guest. It polls app-lb’s metrics for request counts, errors, p50/p90/p99 latency, pool state, and CPU and memory, and it is never part of the data plane: if it goes down, traffic keeps flowing.

# Webhook when "web" logs more than 5 errors in a minute
curl -XPOST localhost:9600/api/alerts \
  -H 'content-type: application/json' \
  -d '{"deployment": "web", "threshold": 5, "webhook_url": "https://hooks.example.com/obs"}'

Read the app-obs docs →

Sign-in in front of anything, no auth code behind it

Add an auth block to any deployment — a VM pool, a static upstream, or a site — and app-lb runs the gate in the proxy before a backend is chosen. Turning a gate on or off never restarts the pool, and the application gets the signed-in user as forwarded identity headers.

# Put a deployment behind Google sign-in
heyctl create secret google --from-stdin client_secret < ~/.google-oauth-secret
heyctl set auth web \
  --client-id 1234-abc.apps.googleusercontent.com \
  --secret google/client_secret \
  --allow-domain example.com

Read the auth docs →  ·  Read the HeyoSecret docs →

Run the whole cloud from your agent

heyo-mcp gives coding agents such as Claude Code 65 tools across sandboxes, app-lb deployments, app-obs logs and metrics, ci runs, and the artifact store. Run it locally over stdio, or host it over HTTP as an app-lb deployment behind a sign-in gate, acting as each caller with their own token.

# Add HWS to Claude Code
claude mcp add heyo \
  -e HEYO_API_KEY=heyo_api_… \
  -- node /path/to/hws/mcp/dist/index.js

Read the MCP server docs →

kubectl verbs, without the cluster

heyctl drives the app-lb admin API: apply declarative specs, use create, scale, and set to write them for you, and read them back with get, describe, and top. Named contexts switch between fleets, and exec and shell get you inside any VM.

heyctl ships in the hws crate, which is also a Rust client library. Depend on it with default-features = false for the typed client without the CLI — the foundation for building your own sandbox platform.

# Install the heyctl CLI
cargo install hws

# Copy a deployment from one load balancer to another
heyctl get deployment web -o json | heyctl --context staging apply -f -

# Cargo.toml: the typed client, no CLI
hws = { version = "0.1", default-features = false }

Read the heyctl docs →

Rent the cloud, or run your own

HWS runs anywhere with Linux and /dev/kvm: a desktop under your desk, servers you rent, or Heyo’s bare metal. One bootstrap script turns a fresh Debian or Ubuntu machine into an app-lb host in one step.

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. HWS is the other path: the same primitives, running as files and pools on machines with your name on them.

Wondering how this stacks up next to E2B, Modal, Daytona, Northflank, or Microsandbox? See the head-to-head →  ·  Read the installation docs →