← All use cases

Build your own Lovable

The vibe-coding app platform, but with your agent and your hardware. Describe the app to your coding agent, let it write the code, and have it ship the result to a URL on your own Heyo Web Services through the heyo MCP server. Build, deploy, TLS, autoscaling, security monitoring and observability come with every deployment.

GET STARTED READ THE MCP DOCS

THE PROBLEM

The app took an afternoon. Hosting it is forever.

Agents made writing software cheap. A dashboard for the team, a tool for one customer, a weekend experiment: each one now needs a build, a route, a certificate, somewhere to log, and a pool that scales. Rent that per app and every one becomes a permanent line item that bills idle capacity like peak.

Heyo Web Services (HWS) is an open-source stack for running your own cloud on your own hardware: microVM workloads behind a load balancer and autoscaler, plus the secrets, observability, artifact and CI services an application needs around them. It is shaped like the platforms agents already know — deployments, replicas, routes, secrets — but every piece is a single binary on hosts you control. Your PaaS, run by your agent.

HOW IT WORKS

From prompt to URL over MCP

Add the MCP server

Register heyo-mcp with Claude Code or any MCP host. One heyo_api_… key covers deployments on managed HWS; a self-hosted fleet points it at your own app-lb.

The agent reads the schema

It calls applb_spec_schema, picks the closest example, and writes a deployment spec: a route, a Firecracker VM, and a build block that points at your repo’s Dockerfile.

applb_deploy ships it

One tool call validates the spec, creates or updates the deployment, starts the build job, waits, and reports TLS. The agent follows the job with applb_job.

A URL with a certificate

An exact host route gets a certificate automatically within seconds. Next change? The agent runs applb_build with a git ref and the pool rolls onto the new image.

# Give Claude Code the heyo MCP server
claude mcp add heyo \
  -e HEYO_API_KEY=heyo_api_… \
  -- node /path/to/hws/mcp/dist/index.js

# After connecting, the agent calls heyo_status first:
# which services it can reach, and what each says about itself

The spec your agent sends is plain JSON. A minimal vm deployment that builds from a Dockerfile:

{
  "id": "hello",
  "namespace": "team-a",
  "routes": [{ "host": "hello.example.com" }],
  "vm": {
    "driver": "firecracker",
    "image": "hello",
    "port": 8080,
    "size_class": "micro",
    "start_command": "setsid nohup /usr/local/bin/hello </dev/null >/var/log/hello.log 2>&1 &"
  },
  "build": {
    "repo": "https://github.com/example/hello.git",
    "ref": "main",
    "dockerfile": "Dockerfile"
  },
  "scaling": { "min_replicas": 1, "max_replicas": 3 },
  "health": { "path": "/health", "timeout_secs": 2 }
}

WHAT YOU GET

The platform comes with the deploy

Scale to zero, wake on request

app-lb sizes the pool to in-flight demand and tears an idle pool down; a request to an empty pool is held while a VM boots. app-lb →

SIEM

Security monitoring built in

app-lb’s built-in SIEM watches traffic for auth failures, scans and spikes, with block rules, and ships alerts to app-obs. SIEM →

OBS

Logs and metrics, no shipper

app-obs tails every VM’s console and scrapes app-lb’s metrics, so logs, latency and errors are queryable without changing the app. app-obs →

Builds in fresh microVMs

ci runs GitHub-Actions-shaped workflows, one fresh microVM per job, on your own runner hosts. ci →

Your agent can read all of it back through the same server: deployment_logs and diagnose_deployment for a misbehaving app, diagnose_empty_pool when a pool won’t fill, applb_security_events for alerts. Secrets are injected by name with env_from, and an optional sign-in gate — Google, app-token or JWT/OIDC — can sit in front of any deployment.

WITHOUT MCP

The same deploy from the CLI

The MCP server and heyctl drive the same admin API. If you’d rather type it yourself, heyctl is a kubectl-style CLI for it.

# Register the deployment behind your own load balancer
heyctl create deployment web --host web.example.com --image nginx-fc --port 80 \
  --size mini --min 1 --max 4 --health-path /healthz

# Point it at your repo's Dockerfile, then build and roll the pool
heyctl create secret github --from-stdin token < ~/.github-pat
heyctl set build web --repo https://github.com/acme/web.git --ref main --secret github
heyctl build web --logs
heyctl rollout status web

# Tune the policy in place
heyctl scale web --min 1 --max 8 --warm 2 --target-concurrency 20
heyctl top

Every image lands as a file you keep. A rollback is heyctl pull web --ref <digest>, which pins exact bytes without changing the stored spec.

THE DIFFERENCE

Renting a PaaS vs. running your own

Renting a PaaS

Every app 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, logs, and build history live in their region

Your own HWS

Your agent deploys over MCP, or you do with heyctl
Scale-to-zero pools wake on demand
Any Dockerfile, any stack; you own the load balancer
Open source, every piece a single binary on hosts you control

Build your own cloud

Your agent writes the app and ships it. Your hardware, your network, your rules.

GET STARTED READ THE MCP DOCS