Secure and fast microVMs for serverless computing. (by firecracker-microvm)

Firecracker Alternatives

Similar projects and alternatives to firecracker

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better firecracker alternative or higher similarity.

firecracker reviews and mentions

Posts with mentions or reviews of firecracker. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-11-18.
  • Blazing fast CI with MicroVMs
    3 projects | | 18 Nov 2022
    You can checkpoint and restore, but only once for security reasons, so it doesn't help much.

    The VMs launch super quick in < 1s they are actually running a job.

  • Podman Desktop: A Free OSS Alternative to Docker Desktop
    13 projects | | 9 Nov 2022
    systemd-nspawn, LXC, and podman should all be able to do that (though doing recursive containers can be kind of weird). In theory should as well, it runs very lightweight VMs.
  • Planning to make a video on cool Rust apps focused on the end user. Make recommendations!
    38 projects | | 2 Nov 2022
    Virtualization: Firecracker
  • The FreeBSD/Firecracker Platform
    2 projects | | 18 Oct 2022
    Firecracker trades run-time performance in favor of faster boot-time latency. It is something that is being addressed but afaik still exists. This of course doesn't mean anything if you want firecracker to boot a multi-gig JVM installation (the larger the filesystem generally, expect a longer boot time).

    Security wise there are some minor differences. For instance bhyve supports virtio-rng but firecracker doesn't want to: .

    I think if your app requires fast boot time and your app supports that than it's fine (so services that spin up and down on demand) but apps that daemonize for extended periods of time or take forever to initialize probably not a great fit.

  • Deploying Firecracker VMs
    5 projects | | 5 Oct 2022
    , "should represent the path to a file that contains a JSON which stores the entire configuration for all of the microVM's resources" (okay this is fair enough). Also, they stipulate, "**The JSON must contain the configuration for the guest kernel and rootfs, as these are mandatory, but all of the other resources are optional, so it's your choice if you want to configure them or not. Because using this configuration method will also start the microVM, you need to specify all desired pre-boot configurable resources in that JSON.**" **File Names for the Pre-Boot Resources** (included within the greater repo here): 1. **firecracker.yaml** - Names of resources are contained here ; 'file nad the names of their fields are the same that are used in API requests' (cool) 2. **tests/framework/vm_config.json** (boilerplate config file to guide us - great) > *"After the machine is booted, you can still use the socket to send API requests for post-boot operations."* (this honestly feels clunky as a mf) ### Conclusion Somewhat of a pain in the ass (just looking through the directions); the fact that we'd have to go grab a uncompressed kernel image + file system image (ext4) is kind of a fucking hassle / burden. Was hoping for a solution more akin to Docker where it can just be spun up real quick & then deployed. But they claim that this 'jailer' feature (that they keep hyping) will **ensure** (I guess?) that whatever is done within the container will remain within the container (and not escape). I haven't seen anything that sticks out about this project that leads me to believe that it possesses that capability, but I definitely don't want to rule it out. ### Extra Documentation + Information 1. **OSv Running on 'Firecracker'** (yay more work though) - 2. **Building OSv Images Using Docker** - 3. **firecracker containerd** (this is something that's probably important for the overall mission of what we want to accomplish here) - ### Firecracker Containerd **Description** - "*firecracker-containerd enables containerd to manage containers as Firecracker microVMs*" - "This repository enables the use of a container runtime, containerd, to manage Firecracker microVMs. Like traditional containers, Firecracker microVMs offer fast start-up and shut-down and minimal overhead. Unlike traditional containers, however, they can provide an additional layer of isolation via the KVM hypervisor." **They Also Identify Potential Use-Cases in the Repo Such as** 1. "*Sandbox a partially or fully untrusted third party container in its own microVM. This would reduce the likelihood of leaking secrets via the third party container, for example.*" 2. "*Bin-pack disparate container workloads on the same host, while maintaining a high level of isolation between containers. Because the overhead of Firecracker is low, the achievable container density per host should be comparable to running containers using kernel-based container runtimes, without the isolation compromise of such solutions. Multi-tenant hosts would particularly benefit from this use case.*" Really interesting feature of this repo here is: "*A root file filesystem image builder that constructs a firecracker microVM root filesystem containing runc and the firecracker-containerd agent.*" (that could save a lot of time on that whole filesystem image thing that they were mentioning prior) **Additional Links of Importance** 1. **Getting Started Guide** - 2. **Quickstart Guide** - 3. **A Root Filesystem Image Builder** - 4. **Runtime Linking Containerd** - **Documentation All Located Here** - (definitely fucking needed because there's a lot here to wrap one's head around) - **Design Approaches Doc** - - **Shim Architecture** - - **Launching 4k VMs Using Firecracker** - - **firectl** (CLI options for manipulating this tool from terminal ; this is important as well) - [damn, there's a lot that came with this here!]
  • Ignite – Use Firecracker VMs with Docker-Like UX
    6 projects | | 26 Sep 2022
    > All serverside cloud-style VMs get tap devices

    Unless you want to PCI pass-through an SRIOV VF into a guest?

    Again, I don't remember the specifics, but depending on the underlying networking (on the host etc), there may be some issues. From some random searching:

    > SANs work fine from within VMs. The point of a SAN is that the disk isn't attached. Firecracker talks to host block devices the same way other virtualizers do.

    But you may want to talk to an attached HBA? Firecracker's docs ( say: "Firecracker emulated block devices are backed by files on the host. To be able to mount block devices in the guest, the backing files need to be pre-formatted with a filesystem that the guest kernel supports."

    Based on everything else in the Firecracker docs, I don't see any vHBA support provided, so the guest cannot access an HBA on the host. And a virtual device backed by a file is going to have crap performance.

    6 projects | | 26 Sep 2022
    I don't have direct experience for examples, but just to hypothesize:

    - Firecracker/KVM can introduce some CPU overhead, for which there are some workarounds (

    - Firecracker networking uses a tap device. Want any kind of advanced networking hardware, say, to offload packet processing, do network inspection, etc, and access it from the containerized app? Not gonna work... Have some advanced network controller that transparently handles mesh networks, or some other fancy shmancy system designed to manage complex interactions between containers and networks? Probably not gonna work due to assumptions about what lies between the layers, what components use what tricks to handle advanced routing (Netfilter, eBGP, sidecars, etc). To say nothing of link-level differences (what if your network isn't Ethernet?). And all traffic is copies from an I/O thread of an emulated network device to a host TAP device; my guess is network latency and maximum PPS were not a consideration.

    - The exposed CPU is based on what KVM supports exposing to guests; presumably QEMU supports a much wider selection. Clocksources, of which I know absolutely nothing (:D), are only allowed as kvm-clock.

    - All I/O is rate-limited by a custom scheme built by the Firecracker authors. I'm sure this is fine for most use-cases, but some weird high-performance outlier is gonna hit some sort of bottleneck with this thing I'm sure.

    - Firecracker emulated block devices are backed by files on the host. Ergo, any app that wants to control a disk directly, or use some fancy shmancy SAN directly, etc is out of luck.

    - The guest requires a balloon driver to use balloon support, which means the guest needs this special software, and compromising it could be a serious issue. I don't know if Kata does this differently.

    - Aarch64 support has a bunch of errata currently, so x86_64 is the only fully-supported platform; I dunno if Kata does any better, but this is a real hardware limitation, esp. if you're trying to buy a shit-ton of cheap powerful machines.

    - This is not hardware-specific, but Firecracker seems limited to specific kernel releases; right now the latest it supports is 5.10, according to

    I would add that containers are used in far more settings than server-side, and would be great to have on the edge, in IoT, and on desktops, if they were a little less... funky. In general, containers requires a lot of extra steps to be "usable" as general purpose applications, and access to hardware will absolutely be a barrier we need to cross in order for "general purpose containerized apps" to become commonplace.

    6 projects | | 26 Sep 2022
    > If it's not hard to name a thing that Firecracker makes difficult for a serverside workload, could you... name one?

    I already did that with live migration. But ok.

    Encrypted storage: WONTFIX

    The answer given is appropriate for firecracker use cases but insufficient otherwise. I'm not anti-firecracker; it's the right choice for many things. Just not all things.

    The sort of VM I want orchestrated has encrypted (by contract) multi-pathed network block devices to encrypted storage volumes. 3-10 per tenant. This is trivial for a full-featured kernel; multi-path just works, encryption just works.

    VLAN: Open. Maybe one day.

    Again, trivial for a full-featured Linux kernel.

    I think you're missing the point. It's not about what hypothetical thing firecracker can or can't do. It's about elevating VM orchestration to some degree of parity with what has been created for container orchestration. These VMs and their complex storage and networking requirements should be modeled as we model containers now; through an orchestration system that makes management easy and as foolproof as possible. The fact that firecracker isn't sufficient to be the Micro-VM of choice for this isn't relevant.

  • Rust is eating into our systems, and it's a good thing (and it's time for me to retire)
    3 projects | | 26 Sep 2022
    about scale and importance, I think Firecracker is a must-mention.
  • Next Steps for Rust in the Kernel
    8 projects | | 21 Sep 2022
    AWS wrote Firecracker which powers AWS Lamba -
  • A note from our sponsor - SonarQube | 1 Dec 2022
    Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free. Learn more →


Basic firecracker repo stats
7 days ago
Static code analysis for 29 languages.
Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.