I’ve been trying to determine if the Fly MicroVM infra automatically wraps my VMified containers with gVisor for additional defense in depth, or if that is something I need to do explicitly, somehow? I’d love to to see more details on the anatomy of the VM itself to determine what measure I should take (if any) to provide additional protections for my requirements.
No; there’d be little benefit to using gVisor on our hosts. gVisor is a userland reimplementation of the Linux kernel, meant to insulate shared-kernel containers (classic Docker) from the host operating system. But we run our jobs in Firecracker, a full VM, giving each job its own Linux kernel.
gVisor is great. But Firecracker is a much stronger isolation technology.
You could theoretically set up gVisor and use runsc inside a Fly.io app — our apps are booted up with containers, but they’re really just full Linux systems, and they run Docker just fine. The only reason to do something like that would be if you were somehow running multiple mutually untrusting jobs inside a single Fly.io app.
2 Likes
Thank you for the fast reply and link to more literature! I suspected as much, but just wanted to double check! Also, thank you for all the blogging, lately I’ve been reading the archives and there’s so much great content there.
Our pleasure! You may be amused to know that we’ve taken some of gVisor’s code (the netstack TCP/IP stack) and embedded it in our flyctl CLI. 
2 Likes
I saw this! That was one of the reasons I wasn’t totally sure about if it was included/necessary/unnecessary, the terms pop up all over the infra
Now if only I had a simple way to configure outbound packet filtering at the platform level!