IMP

Appearance

IMPFirecracker microVMs as first-class Kubernetes resources

Run Firecracker microVMs on Kubernetes with CRDs for networking, snapshots, migration, and warm pools.

Quickstart
Read Architecture
IMP mascot on server hardware

Kubernetes-Native VM API

Manage VM lifecycle through CRDs like ImpVM, ImpNetwork, ImpVMSnapshot, ImpVMMigration, and ImpWarmPool.

Performance + Isolation

Run Firecracker VMs with operator lifecycle, metrics, and health checks.

Networking that Fits Reality

Cilium-first networking with practical fallback paths for non-Cilium CNIs.

Built for Platform Teams

Operator and node agent split keeps control logic and node operations cleanly scoped, with optional imp-sandbox add-on for isolated tenants.

Alpha v0.10.1 — APIs may break; see Troubleshooting

v0.10.1 is the current Imp release. The runner-pool documentation now covers the GitHub App and just-in-time (JIT) runner path, immutable runner image layers, and the boundary between source-backed behaviour and live evidence.

imp quickstart // shell
bash
helm upgrade --install imp ./charts/imp -n imp-system --create-namespace
kubectl get impvm -n default
kubectl describe impvm quick-vm -n default

Why IMP ​

Declare VM lifecycle

Use manifests for VM lifecycle. Avoid per-host scripts.

Inspect runtime state

Use metrics and status fields to check lifecycle state, latency, and health.

Use the same API across environments

Use the same CRDs in local Kind clusters and production, including migration and warm-pool workflows.

Optional Sandbox

Add imp-sandbox for multi-tenant isolation with standard or hard tenancy and gateway controls. Read the sandbox docs →

Use cases ​

Firecracker microVMs fit workloads that need a separate Linux kernel while remaining Kubernetes resources. A VM boundary is one layer of defence: network policy and credential controls still matter.

AI agent sandboxes preview

Give each generated-code task a disposable Linux environment. The optional ImpSandbox add-on is an internal preview, not a production execution API.

Customer-defined code

Run customer scripts and extensions in separate microVMs, managed through Kubernetes. Dispatch, authentication, billing, and function scaling remain application work.

Disposable development environments

Create short-lived environments for experimental branches, dependency installs, and application previews without placing package hooks directly on the node.

Data-processing sandboxes

Run customer-supplied analysis scripts in isolated CPU-based guests and collect their results. Network and data-access policies still define the actual data boundary.

Agent evaluations and test environments

Run each evaluation in a fresh environment so commands and filesystem changes remain separate between trials. Scheduling, scoring, and reproducibility guarantees are outside Imp.

Use-case precedent: Firecracker design, E2B, and Fly Machines. Read Imp Sandbox before relying on the preview integration.