PRprogamer2018·Oct 19, 2021
see document here
https://github.com/firecracker-microvm/firecracker/blob/main...
In Firecracker MicroVMsfirecracker-microvm
firecracker
Rust2018–2026
firecracker-microvm / firecracker
firecracker
Secure and fast microVMs for serverless computing.
84Distinct people
102Mentions
0Explicit recommenders
38KGitHub stars
What to know before exploring
What it is
Secure and fast microVMs for serverless computing.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- cloud-hypervisor/cloud-hypervisor · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year102 dated mentions
Observed mentions: 2018-11-27 05:00:35 UTC to 2026-09-30 23:40:36 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 27 | 4 | 23 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 3 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 9 | 0 | 9 |
What Hacker News says
14 sourcesThis is a great comment: instead of making generic arguments, you actually tried to show how to do it better. Thank you.
I don't find the comments in the original code distracting, but I do like your version better.
> I'm also curious why burst is consumed, then budget. I would expect _budget_ to be consumed first (with refill) with overflow into burst? My expectation is for burst and budget to have different refill schedules in auto_replenish, so using burst first would result in more failures by missing refill opportunities.
This behavior is documented in the public API [0], so whatever is the reason why it was chosen, I don't think it can ever be changed.
> I don't understand why OverConsumption is different to Failure. Both will result in throttling by the caller. The reason for the difference should be documented.
My understanding is
Read the rest
this. If the number of tokens requested is greater than the remaining budget but less than the size of the bucket, the call is rejected and the caller is blocked until it has enough tokens. But if the number of requested tokens is greater than the size of the bucket, the caller will never have enough tokens. Instead of blocking the caller forever, the rate limiter lets the call go through, but then blocks the caller for a while to compensate for the over-consumption. Here's the handling [1]. I wish it was documented better.
[0] https://github.com/firecracker-microvm/firecracker/blob/fc2e...
[1] https://github.com/firecracker-microvm/firecracker/blob/2f92...
That’s correct.
https://github.com/firecracker-microvm/firecracker
In Execute Docker Containers as QEMU MicroVMsThe site seems light on details. As a security guy, I'm particularly interested in (and a skeptic of) claims of "de-privileging" a Linux kernel. Firecracker[1] micro VMs are very fast, "feel" like containers, and don't depend on modifying the guest OS for security. Plus they're FOSS. This is what I'd measure Kwarantine against; you need to be in the ballpark on all these characteristics and knock it out of the park on manageability to interest me.
[1] https://github.com/firecracker-microvm/firecracker
In Hypervisor for multi-tenant computing, like it should beYeah and also what about projects like Firecracker?
https://github.com/firecracker-microvm/firecracker/
In OpenSearch: AWS fork of Elasticsearch and Kibana> Lambda uses containers vs. cloudflare workers use v8 isolates. v8 Isolates are much much faster and more secure for serverless functions.
You're right that v8 Isolates are blazing fast, but Lambda runs functions in a microvm spawn by Firecracker [0], which is likely to be more, not less, secure than Isolates [1].
[0] https://github.com/firecracker-microvm/firecracker/
[1] https://fly.io/blog/sandboxing-and-workload-isolation/
In The Deno CompanyHi Colin, congrats on the (re-)launch! Fellow SUS 2019 graduate here.
I know layerci's tech precedes snapshot support in Firecracker [0], but are snapshots similar to layerci's magic or there's still a significant way for snapshots to go before it can be on par with layerci's tech? I ask because I remember you mention layerci uses techniques (from how Linux hibernates PCs) which are good enough for tests and staging but not production; [1] whereas Firecracker obviously can't rely on such tech so there must be key differences? Thanks.
[0] https://github.com/firecracker-microvm/firecracker/blob/mast...
[1] https://news.ycombinator.com/item?id=23036776
In Launch HN: LayerCI (YC S20) - Staging servers that act like (and replace) CIAlso, firecracker did not merge virtio-fs [1]. So I guess it is a scope and priority decision:
> To not trade off our core use case simplifying assumptions, we'll need something like a way to build different Firecracker "specialized variants" or alternatively a plugin system. This is something worth discussing for 2021. Again this is not a guarantee, but virtio-fs could fit in such a scheme, especially if it's a rust-vmm crate we can easily import over.
[1]: https://github.com/firecracker-microvm/firecracker/pull/1351...
In Show HN: krunvm – Create and run lightweight VMs from OCI imagesThis is awesome. How does this compare with Firecracker - https://github.com/firecracker-microvm/firecracker
Why only TCP is available? Network stack needs to be implemented?
In Show HN: krunvm – Create and run lightweight VMs from OCI imagesnot currently, though there's some people working on that.
https://github.com/firecracker-microvm/firecracker/issues/11...
In Firecracker: Start a VM in less than a secondFirecracker would be better from the security isolation point of view. It can use everything that Docker has to offer in the security domain and some more.
https://github.com/firecracker-microvm/firecracker/blob/mast...
In Firecracker: Start a VM in less than a secondVMs vs containers. One uses KVM under the hood the other uses cgroups. Btw. you can run Firecracker VMs with container isolation on the top.
https://github.com/firecracker-microvm/firecracker/blob/mast...
In Firecracker: Start a VM in less than a secondhttps://github.com/firecracker-microvm/firecracker
Disclaimer: current AWS employer. My job is not related to ES or Lambda.
In AWS announces forks of Elasticsearch and Kibana> KVM and Xen have a smaller attack surface and are known to have a better isolation model, but I'm sure there are still plenty of exploits given enough resources.
KVM - the low-level kernel-level hypervisor - has a tiny attack surface and has been audited exhaustively. It's unlikely to have critical bugs in it.
When people talk about "KVM vulnerabilities", they're usually talking about vulnerabilities in QEMU, which implements the actual device emulation. QEMU has all of the attack surface, deals with low-level data shuffling, and is written in C. Even worse, most stock QEMU-KVM deployments simply run qemu as root with no extra sandboxing or MAC like SELinux/sVirt. It's very likely that a bunch of 0days exist for those environments.
This is why many cloud providers use KVM-the-kernel-module, but an in-house replacement for QEMU.
Fortunat
Read the rest
ely, there's a growing ecosystem of QEMU replacements written in Rust:
- https://github.com/cloud-hypervisor/cloud-hypervisor
- https://github.com/firecracker-microvm/firecracker
- https://chromium.googlesource.com/chromiumos/platform/crosvm... (the Chrome OS VM runtime which Firecracker was forked from)
Google's gVisor - the sandbox that App Engine and Cloud Run uses - uses KVM as well: https://gvisor.dev/docs/
With an emulation layer written in a language like Rust, the trust boundary is much better.
As for VirtualBox in particular - that one should not be considered a trust boundary. Nobody is seriously using it in production, and it's regularly featured in CTF competitions as a fun exploitation target.