vibeD v0.4.x a Governance, a Build-Free Core and Extension Points

v0.3.1 was about speed, to bring an AI-generated app to a live URL in seconds, never building a container on the deploy path. The whole v0.4 line has been about everything around that hot path: making vibeD defensible, lean and extensible, without ever slowing the "the model wrote it, it's live" loop.

Here's what actually landed across v0.4.0 → v0.4.3.

v0.4.0 a governance release

v0.3.1 made deploys fast; v0.4.0 made them defensible. This is the release where vibeD stopped being "a fast way to run AI code" and started being "a fast way to run AI code you can hand to a security team."

• Per-app egress control. Every app declares its outbound allow-list at deploy time (allowed_hosts: ["api.openweathermap.org", "*.example.com"]) and vibeD enforces it at the network: a Squid forward proxy on the egress path, a vibed-egress-authz sidecar authorizing each connection by source-pod IP, and a NetworkPolicy that makes the proxy the only way out. Default-deny, wildcards anchored to real subdomains (evil-example.com doesn't match *.example.com).
• Deploy quotas. Per-owner and per-department concurrent-app ceilings, hard-gated at the deploy path (429 when you hit the limit). Redeploys of an existing app are never blocked.
• An append-only audit trail of who deployed, changed, rolled back, or deleted what.
• Bring-your-own base images. The five built-in templates are a default, but not a requirement. Register your own hardened image for any slot as long as it meets the BYO contract; a controller-side validator boots-checks every warm-pool image and fails deploys fast with a clear reason instead of breaking apps silently. templateValidation.strict also rejects deploys when a warm pod's image digest drifts from the validated one.
• A real suspend / resume lifecycle, the last 501 API gaps closed (log streaming, redeploy), and SBOMs for every image.

v0.4.1 is a build-free core

v0.3.1 added the warm-sandbox path; v0.4.1 deleted the old one. The Buildah / buildpacks image-builder is gone — internal/builder/ and all its scaffolding removed. Tarball + warm-sandbox injection is now the only deploy path. The orchestrator was gutted to a thin static-only fallback, Knative was dropped as a target, and builder-related config was stripped out.

The result is a much smaller, simpler control plane with one deploy story and every image ships an SPDX SBOM plus an in-registry attestation you can inspect with docker buildx imagetools inspect.

v0.4.2 comes with extension points

Under the hood, the control plane became a set of registries. Storage, authentication, tenancy, deploy-time policy, usage metering, and secret schemes are all looked up by name, so you can supply your own implementation of any of them from a separate Go module; no fork, no patch:

• pluggable store backends (store.backend) and auth providers (auth.mode),
• a Tenant / TenantResolver seam (ships a single implicit tenant, so single-tenant behavior is unchanged),
• a deploy-time PolicyGate and a usage MeterSink,
• a pluggable secret-scheme resolver (env: / file: built in; add your own),
• the public pkg/plugin façade + reusable pkg/server builder, so a custom binary is just blank-import your provider, call server.Main(),
• enriched audit events (tenant, source hash, policy decision) and a CI import-boundary check.

This is all documented in the new Extending vibeD section. Every seam ships a no-op default, so a stock install behaves exactly as before.

v0.4.3 secure by default

The extension points made it easy to tighten the defaults. v0.4.3 closes the highest-severity findings from a security review of the core:

• No identity spoofing in proxy mode. The oauth passthrough now trusts the X-Forwarded-User header only when the request comes from a configured trusted-proxy CIDR (auth.trustedProxies); otherwise it maps to a generic identity. A direct caller that learns the shared secret can no longer impersonate a user.
• The in-sandbox agent control API is authenticated. The agent token is now wired end-to-end (controller → warm-pool pods via a shared Secret), with an opt-in fail-closed mode and a constant-time token compare — so the untrusted workload sharing a pod can't drive the agent.
• values-production.yaml ships hardened. Sandbox NetworkPolicy, per-app egress allow-list, HTTP rate limiting, and agent-API auth are all on, with the S3 source backend and its endpoint auto-added to the egress allow-list so the locked-down policy still lets deploys through.

Try it

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

Full prerequisites (agent-sandbox, a Kata RuntimeClass, a sandbox node pool) are in the installation guide. One upgrade caveat carries over from the v0.4 line: Helm doesn't upgrade CRDs, so after bumping you must kubectl apply the current VibedApp CRD.

What's next

More extension points, continued security hardening down the finding list, and per-tenant isolation options, all without touching the thing that makes vibeD vibeD: the model writes it, and it's live, governed, in seconds. The code is on GitHub — tell us what breaks.