fabrica

Fabrica (“fabricA”) gives AI coding agents dedicated, ephemeral compute environments it calls Agent Computers — each one a full microVM rather than a shared container. Agent clients talk to a REST API, which hands off to a sandbox manager and Kubernetes control plane; containerd and Kata Containers then launch a Cloud Hypervisor microVM per agent, so every agent gets its own kernel instead of sharing namespaces with neighbors on the same node.

Each sandbox ships with a TTL-based lifecycle with automatic garbage collection when idle, configurable network policies (isolated, restricted, or open), an OCI image-based Ubuntu 24.04 userspace with dev tools preinstalled, remote command execution through the Kubernetes exec API, filesystem snapshotting, and copy-on-write workspace cloning via overlayfs — so forking an agent’s exact working state is cheap rather than a full re-provision. Multi-tenant quota enforcement caps concurrent sandboxes, CPU, and memory per tenant at admission time, and every request path emits Prometheus metrics and OpenTelemetry traces.

The project is candid about its maturity: the control plane (REST API, SQLite persistence, reconciliation controller, quota enforcement, observability) is described by the maintainer as production-ready and backed by 291 tests including concurrency stress tests, but the runtime layer that actually launches microVMs requires a real Linux host with KVM support and Kata Containers installed — it will not run on a laptop or a managed Kubernetes cluster without that hardware and software prerequisite. A make helm-deploy-dev path exists for a quick, Kata-free test deployment using the plain runc runtime on kind/k3d/minikube, useful for exploring the API surface without the full isolation stack in place.

What You Get

• A REST API with 14 endpoints for creating, execing into, uploading/downloading files, snapshotting, cloning, stopping, starting, and deleting agent sandboxes
• Kata Containers + Cloud Hypervisor microVM isolation per agent, scheduled through a custom Kubernetes RuntimeClass (kata-clh)
• Multi-tenant quota enforcement (max sandboxes, CPU, memory) checked at admission time before a sandbox is created
• A TTL-based lifecycle with an automatic reconciliation controller that garbage-collects expired sandboxes on a 30-second interval
• Copy-on-write workspace cloning via overlayfs for instant forking of an agent’s filesystem state
• Prometheus metrics and OpenTelemetry tracing wired into every request path, plus a bundled Grafana dashboard
• A production Helm chart with separate dev and production profiles, including helm-test smoke tests for a live release

Common Use Cases

• Running AI coding agents in fully isolated, disposable compute so a misbehaving or compromised agent can’t affect the host or other tenants
• Multi-tenant AI agent platforms that need hard quota limits per customer on concurrent sandboxes, CPU, and memory
• Forking an agent’s exact workspace mid-task to try two different approaches in parallel via the copy-on-write clone endpoint
• Benchmarking and load-testing agent infrastructure at scale (100+ concurrent agent sandboxes) using the bundled load generator and demo scripts
• General untrusted-code sandboxing on Kubernetes for any short-lived, semi-trusted workload that needs VM-level isolation, not just AI agents

Under The Hood

Architecture The control plane wires together a small set of narrowly-scoped internal packages behind interfaces rather than concrete types: cmd/sandbox-manager/main.go constructs a database.DB, a k8s.Runtime (implementing a package-level runtime.Runtime interface so Kata/Cloud Hypervisor could later be swapped for Firecracker, gVisor, or runc), a quota.QuotaManager, and a metrics.Metrics collector, then injects all of them into an api.Handler and a controller.Controller via constructor functions. The controller depends on a narrow Database interface (not the concrete *database.DB), an explicit dependency-inversion choice that keeps it independently testable. Requests flow REST API to quota admission check to a SQLite insert of desired state (internal/database), while a separate reconciliation loop (internal/controller) polls the database on a fixed interval, calls into the Kubernetes runtime to create/start/stop microVMs, and writes status back — effectively a userspace Kubernetes-operator pattern implemented against SQLite instead of CRDs and etcd. If the core Runtime interface changed, only the Kubernetes implementation and the controller’s call sites would need to change; the API and database layers stay insulated because they depend on interfaces, not concrete runtime types.

Tech Stack The service is written in Go and built with a single Makefile (make build, make test, make docker-image). HTTP routing uses gorilla/mux; persistence uses mattn/go-sqlite3 (SQLite in WAL mode, explicitly designed to be swappable for PostgreSQL later); Kubernetes access goes through k8s.io/client-go and k8s.io/api; observability is Prometheus client_golang plus OpenTelemetry’s otel/otel-trace; logging is structured JSON via uber-go/zap; and IDs come from google/uuid. Deployment targets containerd with a custom Kata Containers RuntimeClass backed by Cloud Hypervisor for microVM isolation, distributed via a multi-stage Dockerfile, a docker-compose file for local development (with Prometheus and Grafana), full raw Kubernetes manifests, and a Helm chart offering both a Kata-free “dev” profile (runc, no KVM required) and a hardened “production” profile (HA replica count, HorizontalPodAutoscaler, PodDisruptionBudget, network policies).

Code Quality Every internal package ships with its own test file, and several ship with dedicated stress or integration tests on top (api_test.go plus integration_test.go, database_test.go plus stress_test.go, quota_test.go plus its own stress test, controller_test.go plus reconcile_test.go), using the standard library testing package with no external assertion framework. The README states this totals 291 tests run with Go’s race detector, including concurrency stress tests (e.g. 1000-goroutine quota exhaustion, 50-goroutine concurrent database inserts) and a security-focused storage test suite covering overlayfs path-traversal protection. Error handling follows idiomatic Go: errors are checked and wrapped with fmt.Errorf throughout rather than swallowed, and logger.Fatal is reserved for unrecoverable startup failures. No .golangci.yml linter configuration or .github/workflows CI pipeline is present in this snapshot, so go vet and the full test suite are currently run manually via make rather than enforced automatically on every push.

What Makes It Unique Fabrica’s central technical bet is running each AI agent inside a dedicated Kata Containers plus Cloud Hypervisor microVM — giving every agent its own kernel — while still scheduling everything through standard Kubernetes via a custom RuntimeClass, rather than building a bespoke VM orchestrator from scratch. It layers a lightweight userspace reconciliation controller against SQLite instead of CRDs/etcd to keep the control plane self-contained, and implements copy-on-write workspace cloning through overlayfs (a golden image as the lowerdir, per-agent changes in the upperdir) so forking an agent’s exact working state is cheap. None of the individual building blocks — Kata, CoW overlayfs, Kubernetes reconciliation loops — are novel in isolation, but recombining them specifically for ephemeral, VM-isolated AI agent compute is a genuine and currently uncommon architectural choice in the emerging “agent sandbox” space.

Self-Hosting

Licensing Model Apache License 2.0 — a permissive open-source license. All functionality in this repository, including the control plane, REST API, Kubernetes/Kata runtime integration, and Helm charts, is available to self-hosters with no license keys or paid tiers involved.

Self-Hosting Restrictions None found. There are no ee/, enterprise/, pro/, or cloud/ directories in the repository, and no license-check, feature-flag, or isPro/isEnterprise gating logic anywhere in the source.

Enterprise Features Not applicable — there is no separate paid or enterprise tier. The Helm chart’s “production” profile (HA replicas, HPA, PodDisruptionBudgets, durable storage, network policies) is part of the same open-source chart as the “dev” profile, not a gated add-on.

License Key Required No. No component in this project requires a license key to run.