Exploratory project plan
Project Plan: Lightweight Lampyr Services on Hyperlight
Status
Draft project direction based on the working Hyperlight and Unikraft, Knative, snapshot, Fiberd home, and standalone protocol-consumer prototypes.
This document is exploratory. It includes target-state ideas and should not be read as a list of currently implemented product behavior. See Product design for the confirmed baseline and the walkthrough for the implemented workflow.
Executive summary
Build a small, focused execution platform for lightweight services that gives developers a serverless-like experience on disposable, single-purpose Kubernetes clusters without forcing a proprietary programming model.
The platform should make common workloads easy to deploy while retaining escape hatches for teams that need direct control. Hyperlight microVMs and Unikraft provide fast, hardware-isolated execution. Kubernetes provides the admitted capacity and operational boundary. A node-local activation layer avoids creating a new Pod for every short-lived instance.
The intended product is not “Hyperlight as a Kubernetes runtime” exposed directly to users. Hyperlight, Unikraft, OCI artifacts, snapshots, and Knative are implementation building blocks behind a simpler product experience.
Vision
Make small Lampyr Services feel nearly serverless to operate:
- Start with a minimal, disposable Kubernetes cluster.
- Run many small services efficiently on a small number of VMs.
- Autoscale without requiring developers to understand most Kubernetes machinery.
- Support familiar languages such as Go, Rust, Python, JavaScript, and .NET.
- Avoid a required service-specific programming model.
- Provide opinionated defaults with clear escape hatches.
- Make multi-region deployment straightforward.
- Minimize persistent node state by streaming and reaping OCI artifacts.
- Reduce platform and programming-model lock-in.
Target users
Teams that:
- Build small HTTP, event-driven, agent, or Lampyr Services.
- Care about efficient execution and predictable infrastructure cost.
- Do not want to pay a large per-request platform premium.
- Already know standard languages and container-oriented workflows.
- Want less operational overhead than general-purpose Kubernetes.
- Need stronger isolation than running arbitrary code as a normal process.
- Want portability across local, edge, and cloud environments.
Initial scenarios
Edge HTTP services
Deploy small APIs close to users without maintaining a large regional platform footprint.
Secure agent execution
Run agent-generated or untrusted code inside a hardware-isolated, default-deny Hyperlight microVM.
Event handlers
Start isolated handlers quickly for queues, webhooks, scheduled work, and automation.
Multi-tenant code execution
Provide short-lived sandboxes for CI tasks, developer tools, notebooks, and code interpreters.
Product principles
Developer experience first
The common path should look like:
initialize projectchoose runtimedeployobservescaleDevelopers should not need to understand snapshot layouts, queue-proxy behavior, or containerd configuration.
Do not require a new programming model, but provide one
Provide supported paths for common languages, but preserve lower-level integration options:
Easy path: supported runtime template (not implemented yet)Provide: ability to use common runtimes as isEscape hatch: custom OCI rootfs and entrypointLower level: direct Hyperlight/Unikraft integrationDisposable and immutable infrastructure
Clusters and worker nodes should be replaceable. Persistent state should live outside the execution cluster.