Skip to main content

vibeD v0.3.1: A Two-Lane microVM Rewrite

· 5 min read
vibeD Team
vibeD Team
Core Maintainers

v0.3.1 has some larger architectural changes and let me rethink the approach. I had to rebuilt the engine. The old build-and-deploy model (build a container image with Buildah, hand it to Knative) is gone, replaced by an architecture designed around a single goal: get an AI-generated app to a live URL in seconds, with hardware-grade isolation, and never build a container on the deploy path.

Why the rewrite?​

The original vibeD proved the idea: an MCP server an AI agent can call to deploy what it just wrote. But the deploy path went through a container build. So, Buildah generating a Dockerfile, building an image, pushing it, then Knative pulling and starting it. That's takes minutes and it's a lot of moving parts for what's usually a tiny app. Besides, Models tend to build their own container too (tested in the not published v0.2.0), which increased unreliability of the deployables.

But, the target user hasn't changed: an enterprise employee who vibe-coded a small tool and wants it captured into a (governed) sandbox instead of living on their laptop. What changed is our answer to "how do you make that fast and safely isolated at the same time?"

Two lanes, one API​

You never pick a runtime. A deterministic classifier reads the source (file names + package.json keys) and routes each app to one of two lanes:

  • fast lane: V8 isolates (workerd) and static sites. Sub-second.
  • general lane: Kata + Firecracker microVMs for arbitrary code (Node, Python, Go, or any image), with hardware-grade isolation.

The HTTP API is uniform across both. You can override the lane or template, but it's the exception, not the workflow.

Warm pools, not builds​

vibeD keeps warm pools of pre-booted sandboxes for every runtime template. A deploy claims one and injects your source tarball into it. No docker build, no buildah, no image push between POST /v1/deploy and your URL.

POST /v1/deploy  (source tarball + metadata)
   │  classify → (lane, template)
   ▼
VibedApp  ──claim──▶  warm sandbox  ──inject source──▶  Ready  →  https://<id>.<domain>

New dependency combinations are handled by an async template builder that refreshes the pool out of band, it never blocks a user-visible deploy.

Built on agent-sandbox​

vibeD now owns exactly one CRD, VibedApp, and reuses kubernetes-sigs/agent-sandbox for the rest (Sandbox, SandboxTemplate, SandboxClaim, SandboxWarmPool). The control plane is split into four stateless pieces:

  • vibed: the API server, dashboard, and MCP server.
  • vibed-controller: reconciles each VibedApp to Ready.
  • vibed-router: programs Caddy routes (wildcard DNS-01 TLS in production).
  • Caddy: the reverse proxy that fronts every app.

See the architecture overview for the full picture.

What's new​

  • Per-app Service routing. Caddy proxies to a per-app Service that follows the sandbox pod across restarts, so no more stale-pod-IP 502s. And when a pod is recreated, the controller re-injects source, so apps self-heal.
  • Five runtime templates: node-24, python-313, go-123, base-al2023, static-nginx.
  • Pluggable source store: pre-signed S3/MinIO in production, an in-cluster served store for dev.
  • Configurable app URLs: https://<id>.<domain> in production; http://<id>.localhost:18080 on a Kind dev cluster.
  • Dashboard rebuilt on the new /v1/apps API.
  • Docs rewritten end-to-end for the new architecture.

What's changed (breaking)​

v0.3.1 is not a drop-in upgrade from the v0.1.x line:

  • The Buildah/Knative deploy path is removed. Deploys create a VibedApp on agent-sandbox.
  • New requirements: agent-sandbox, a Kata RuntimeClass, and a sandbox node pool with KVM.
  • Helm values are substantially reworked.
  • The dashboard/API moved from /api/artifacts to /v1/apps. The MCP tools keep their *_artifact names but now create VibedApps.
  • CRD upgrades aren't automatic. Helm installs CRDs only on first install, so after upgrading you must kubectl apply the updated VibedApp CRD.

Honest limitations​

A few endpoints are scaffolded but not yet wired and return 501: live log streaming, redeploy, and idle-suspend / snapshot-restore. GET /v1/templates returns an empty list for now. The served source backend is dev-only; production needs s3 once a restrictive sandbox NetworkPolicy is in place.

Try it​

helm install vibed oci://ghcr.io/vibed-project/charts/vibed \
  --version 0.3.1 -n vibed-system --create-namespace

Local Kind setup and the full prerequisites (agent-sandbox, Kata, a sandbox node pool) are in the installation guide and local development docs.

What's next​

  • A load-test harness to hold the line on the latency SLOs (p99 < 10s).
  • Wiring up suspend-to-snapshot and snapshot-restore for instant redeploys.
  • Live log streaming over the /v1/apps/{id}/logs SSE endpoint.

If you're building on top of an AI agent and want its output to land somewhere governed and fast, give it a spin and tell us what breaks. The code is on GitHub.