Project summary
A distributed orchestrator for running OCI workloads in Firecracker/Cloud Hypervisor microVMs directly on bare metal.
Project description
zeish is an orchestrator for running OCI container workloads as hardware-isolated microVMs directly on bare metal, without a hypervisor-as-a-service layer or a Kubernetes dependency in the critical path. It targets teams who need VM-grade isolation with container-like density and boot times, for example multi-tenant sandbox and code-execution platforms, CI runners, and other workloads where a shared-kernel container isn't an acceptable isolation boundary.
The control plane is split into a regional service (regiond) that owns placement, auth, and networking policy, and a per-node agent (machined) that owns local VM lifecycle and talks to a pluggable VMM driver layer (Firecracker and Cloud Hypervisor today, with the driver boundary designed for others). Supporting components handle OCI rootfs preparation (flasher), guest PID 1 and lifecycle signaling (initd), TLS/SNI and SSH/WebSSH ingress (proxyd), private DNS (dnsd), and host reconciliation (guestd). Cluster state is replicated with an embedded CRDT store (Corrosion) rather than a heavyweight coordination service, and networking is built on a WireGuard mesh with per-workload IPv6 addressing.
zeish exists because most microVM tooling is either a low-level SDK (Firecracker itself, Cloud Hypervisor) that leaves placement, networking, multi-tenant isolation, and lifecycle orchestration as an exercise for the integrator, or a full hyperscaler-style platform that assumes you're building on top of an existing cloud. zeish fills the middle: a self-hostable, bare-metal-first orchestration layer for teams who want microVM isolation without operating a full IaaS.
Project vs Reference Architecture/Implementation
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/spinupdev
Project repo URL in scope of application
https://github.com/spinupdev/depot
Additional repos in scope of the application
No response
Website URL
https://zei.sh
Roadmap
https://github.com/spinupdev/zeish/blob/main/docs/rfcs/
Roadmap context
The goal is to build a production grade orchestrator and scheduler that works on any cloud or any bare metal or hybrid of both.
Contributing guide
https://github.com/spinupdev/depot/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/spinupdev/depot/blob/main/CODE_OF_CONDUCT.md
Adopters
No response
Maintainers file
https://github.com/spinupdev/depot/blob/main/MAINTAINERS.md
Security policy file
https://github.com/spinupdev/depot/blob/main/SECURITY.md
Standard or specification?
N/A. zeish is not a standard or specification.
Business product or service to project separation
zeish is the open-source orchestration engine that Spinup's own product, Edge, is built on top of. Edge is a hosted sandbox/code-execution platform (dashboard, billing, workflow orchestration) that consumes zeish's regiond API as a client. It does not modify zeish's control-plane internals, and zeish has no dependency on Edge or on Spinup's private fleet configuration. The separation is architectural today (zeish repo vs. edge repo, with zeish treated as the stable API boundary) rather than organizational: Spinup is currently zeish's only production user and sole contributor.
Why CNCF?
We want zeish to be a durable, vendor-neutral piece of infrastructure rather than a single company's internal tool that happens to be visible on GitHub. The CNCF gives us a neutral governance home so zeish's roadmap isn't perceived as steered by Spinup's product needs alone, access to the TAG Runtime community whose members have deep experience with exactly the problem zeish addresses (secure multi-tenant compute isolation), a path to real external contributors and adopters who would be reluctant to build on a single-vendor repo, and the credibility and process discipline (security review, license compliance, structured governance) that lets other organizations trust zeish enough to run it in production.
Benefit to the landscape
Most cloud native isolation options sit at two extremes: shared-kernel containers (fast, dense, weaker isolation boundary) or full VM-per-workload on top of a hyperscaler or a heavyweight hypervisor platform (strong isolation, higher overhead, often cloud-locked). microVM technology (Firecracker, Cloud Hypervisor) closes that gap at the VMM layer, but there's a shortage of open, self-hostable orchestration above the VMM. Most existing options are either single-cloud-vendor internal tools (not generally available) or thin wrappers that don't solve placement, multi-tenant networking, or lifecycle management at fleet scale. zeish provides that missing orchestration layer: bare-metal-first, VMM-pluggable, and designed for multi-tenant density with real isolation guarantees. It's useful anywhere teams need to run untrusted or semi-trusted code (CI, sandboxed agents/code execution, PaaS-style multi-tenant hosting) without either the security risk of shared-kernel containers or the operational cost of a full VM platform.
Cloud native 'fit'
zeish is cloud native in the sense the CNCF defines: workloads are ephemeral, densely packed, and dynamically placed across a fleet; the control plane is built from independently scalable, loosely coupled services (regiond/machined/flasher/proxyd/dnsd) communicating over defined APIs; state is replicated rather than centralized in a single point of failure; and the system is designed for automation-first operation (declarative machine lifecycle via a finite-state machine with idempotent, replayable transitions) rather than manual VM administration.
It also embraces container-native workflows directly: zeish runs OCI images as its unit of deployment, so existing container images work unmodified as hardware-isolated microVMs.
Cloud native 'integration'
- OCI: zeish's unit of deployment is an OCI image; flasher converts OCI images into microVM root filesystems.
Cloud native overlap
zeish overlaps partially with:
Kata Containers: also runs container workloads in VM-level isolation via a VMM (including Firecracker). Kata integrates as a Kubernetes/containerd runtime class, meaning it's a sandboxed runtime plugged into an existing container orchestrator's scheduler. zeish is a standalone fleet orchestrator: it owns placement, networking, and lifecycle itself rather than delegating to Kubernetes, and targets bare-metal deployment without a Kubernetes dependency
Similar projects
Kata Containers (CNCF Incubating): VM-isolated container runtime, Kubernetes-integrated. See overlap note above.
Landscape
Not yet listed
Insights
Not yet listed on LFX Insights
Trademark and accounts
IP policy
Will the project require a license exception?
N/A
Project "Domain Technical Review"
No response
Application contact email(s)
aaqaishtyaq@gmail.com
Contributing or sponsoring entity signatory information
If an organization:
| Name |
Address |
Type (e.g., Delaware corporation) |
Signatory name and title |
Email address |
|
|
|
|
|
Or, if an individual or individual(s):
CNCF contacts
No response
Additional information
No response
Project summary
A distributed orchestrator for running OCI workloads in Firecracker/Cloud Hypervisor microVMs directly on bare metal.
Project description
zeish is an orchestrator for running OCI container workloads as hardware-isolated microVMs directly on bare metal, without a hypervisor-as-a-service layer or a Kubernetes dependency in the critical path. It targets teams who need VM-grade isolation with container-like density and boot times, for example multi-tenant sandbox and code-execution platforms, CI runners, and other workloads where a shared-kernel container isn't an acceptable isolation boundary.
The control plane is split into a regional service (regiond) that owns placement, auth, and networking policy, and a per-node agent (machined) that owns local VM lifecycle and talks to a pluggable VMM driver layer (Firecracker and Cloud Hypervisor today, with the driver boundary designed for others). Supporting components handle OCI rootfs preparation (flasher), guest PID 1 and lifecycle signaling (initd), TLS/SNI and SSH/WebSSH ingress (proxyd), private DNS (dnsd), and host reconciliation (guestd). Cluster state is replicated with an embedded CRDT store (Corrosion) rather than a heavyweight coordination service, and networking is built on a WireGuard mesh with per-workload IPv6 addressing.
zeish exists because most microVM tooling is either a low-level SDK (Firecracker itself, Cloud Hypervisor) that leaves placement, networking, multi-tenant isolation, and lifecycle orchestration as an exercise for the integrator, or a full hyperscaler-style platform that assumes you're building on top of an existing cloud. zeish fills the middle: a self-hostable, bare-metal-first orchestration layer for teams who want microVM isolation without operating a full IaaS.
Project vs Reference Architecture/Implementation
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/spinupdev
Project repo URL in scope of application
https://github.com/spinupdev/depot
Additional repos in scope of the application
No response
Website URL
https://zei.sh
Roadmap
https://github.com/spinupdev/zeish/blob/main/docs/rfcs/
Roadmap context
The goal is to build a production grade orchestrator and scheduler that works on any cloud or any bare metal or hybrid of both.
Contributing guide
https://github.com/spinupdev/depot/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/spinupdev/depot/blob/main/CODE_OF_CONDUCT.md
Adopters
No response
Maintainers file
https://github.com/spinupdev/depot/blob/main/MAINTAINERS.md
Security policy file
https://github.com/spinupdev/depot/blob/main/SECURITY.md
Standard or specification?
N/A. zeish is not a standard or specification.
Business product or service to project separation
zeish is the open-source orchestration engine that Spinup's own product, Edge, is built on top of. Edge is a hosted sandbox/code-execution platform (dashboard, billing, workflow orchestration) that consumes zeish's regiond API as a client. It does not modify zeish's control-plane internals, and zeish has no dependency on Edge or on Spinup's private fleet configuration. The separation is architectural today (zeish repo vs. edge repo, with zeish treated as the stable API boundary) rather than organizational: Spinup is currently zeish's only production user and sole contributor.
Why CNCF?
We want zeish to be a durable, vendor-neutral piece of infrastructure rather than a single company's internal tool that happens to be visible on GitHub. The CNCF gives us a neutral governance home so zeish's roadmap isn't perceived as steered by Spinup's product needs alone, access to the TAG Runtime community whose members have deep experience with exactly the problem zeish addresses (secure multi-tenant compute isolation), a path to real external contributors and adopters who would be reluctant to build on a single-vendor repo, and the credibility and process discipline (security review, license compliance, structured governance) that lets other organizations trust zeish enough to run it in production.
Benefit to the landscape
Most cloud native isolation options sit at two extremes: shared-kernel containers (fast, dense, weaker isolation boundary) or full VM-per-workload on top of a hyperscaler or a heavyweight hypervisor platform (strong isolation, higher overhead, often cloud-locked). microVM technology (Firecracker, Cloud Hypervisor) closes that gap at the VMM layer, but there's a shortage of open, self-hostable orchestration above the VMM. Most existing options are either single-cloud-vendor internal tools (not generally available) or thin wrappers that don't solve placement, multi-tenant networking, or lifecycle management at fleet scale. zeish provides that missing orchestration layer: bare-metal-first, VMM-pluggable, and designed for multi-tenant density with real isolation guarantees. It's useful anywhere teams need to run untrusted or semi-trusted code (CI, sandboxed agents/code execution, PaaS-style multi-tenant hosting) without either the security risk of shared-kernel containers or the operational cost of a full VM platform.
Cloud native 'fit'
zeish is cloud native in the sense the CNCF defines: workloads are ephemeral, densely packed, and dynamically placed across a fleet; the control plane is built from independently scalable, loosely coupled services (regiond/machined/flasher/proxyd/dnsd) communicating over defined APIs; state is replicated rather than centralized in a single point of failure; and the system is designed for automation-first operation (declarative machine lifecycle via a finite-state machine with idempotent, replayable transitions) rather than manual VM administration.
It also embraces container-native workflows directly: zeish runs OCI images as its unit of deployment, so existing container images work unmodified as hardware-isolated microVMs.
Cloud native 'integration'
Cloud native overlap
zeish overlaps partially with:
Kata Containers: also runs container workloads in VM-level isolation via a VMM (including Firecracker). Kata integrates as a Kubernetes/containerd runtime class, meaning it's a sandboxed runtime plugged into an existing container orchestrator's scheduler. zeish is a standalone fleet orchestrator: it owns placement, networking, and lifecycle itself rather than delegating to Kubernetes, and targets bare-metal deployment without a Kubernetes dependency
Similar projects
Kata Containers (CNCF Incubating): VM-isolated container runtime, Kubernetes-integrated. See overlap note above.
Landscape
Not yet listed
Insights
Not yet listed on LFX Insights
Trademark and accounts
IP policy
Will the project require a license exception?
N/A
Project "Domain Technical Review"
No response
Application contact email(s)
aaqaishtyaq@gmail.com
Contributing or sponsoring entity signatory information
If an organization:
Or, if an individual or individual(s):
CNCF contacts
No response
Additional information
No response