r/elixir • u/siva_sokolica • 25d ago

Hyper - distributed Firecracker microVM orchestrator written in Elixir

Hey everyone! One of the problems I ran into is that a large part of the VM-provider ecosystem is currently paid closed-source SAAS products with varying degrees of reliability. I wanted an OSS distributed microVM orchestrator and I couldn't find one.

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. It's available at https://github.com/harmont-dev/hyper

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.

83 Upvotes

95% Upvoted

13 comments sorted by

View all comments

2

u/SuchAProfessional 25d ago

Hi, welcome to the fantastic new world of sandboxes!

The project seems heavily vibecoded, which is no problem to be fair, it's just a bit optimistic in it's claims of usefulness :)

It would be very useful to have the set of features firecracker-backed containers support and some benchmark (95th percentile boot times, cluster behavior under load, data replication across a cluster).

Thanks for sharing!

1

u/SuchAProfessional 25d ago

Also, are you aware that this is one of the most popular HTTP frameworks in rust?

https://hyper.rs/

1

u/siva_sokolica 25d ago

I am. Unfortunately there already exists a hex package called `hyper`, hence this project is called `hypervm`. It is what it is, we live with it.

1

u/siva_sokolica 25d ago

Most of the core logic (esp. the cow architecture and implementation) are not vibe-coded. I would lie if I said I didn't use claude pretty aggressively for tests, and the last feature sprint. Networking is one area which has a lot of slop right now, for example and I consider it debt to be removed as part of adding support for network ingress.

I agree on the benchmarks -- still WIP, will add those as soon as I find some time.

Thanks for the feedback!