Hyper is a distributed FirecrackerVM orchestrator written in Elixir (BEAM), with gRPC support for non-BEAM clients. Hyper is:
- Distributed -- it's designed to run across a cluster of bare metal machines, and will automatically connect to other Hyper nodes.
- Fast -- it builds COW layers to enable fast, localized COW forking. Cold boots happen within 1s. Filesystem forks take ~50ms. Forked VMs are colocated to take the fast path as much as possible.
- Interactive -- like all Elixir applications, if you can connect to the cluster, you can spawn, manage, monitor and interact with VMs live in an `iex` REPL. Or, you can use the gRPC interface if your system isn't on the BEAM.
- Yours -- although I developed this primarily for Harmont (which is paid), Hyper is an MIT-licensed project and will remain such.
- Self-contained -- all we need is a side-car Postgres instance.
- Configurable -- colocation, vmlinux options, etc. can all be customized.
- Secure -- everything runs on the BEAM; a single setuid Rust helper performs the few operations that need root, keeping the privileged surface small.
Fair warning: the software is still in active testing and I expect a couple more features to be added soon:
- Automatic cloud provisioning -- when you run out of headroom in your cluster, you should be able to fall back to Latitude/GCP/AWS to provision more compute.
- More testing -- I am currently integrating Hyper into harmont.dev and will likely run into some issues. Fuzzing is part of the roadmap.
- Better docs -- I spent _some_ time working on the docs, but they're definitely not total nor ideal.
Very open to feedback, critique, and/or contributions. Please open any issues on Github, or feel free to DM/email me.
PS. A couple people asked how this differs from firecracker-containerd and Kata containers. Both of those projects are runtimes for managing VMs on a single node. A fair mental model for Hyper is an amalgam of firecracker-containerd and k8s.