SaaSHub helps you find the best software and product alternatives Learn more →
Gvisor Alternatives
Similar projects and alternatives to gvisor
-
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
-
-
-
-
-
Clippy
A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
TinyGo
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
-
-
-
-
-
-
garden
Automation for Kubernetes development and testing. Spin up production-like environments for development, testing, and CI on demand. Use the same configuration and workflows at every step of the process. Speed up your builds and test runs via shared result caching
-
-
-
kata-containers
Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/
-
cloud-hypervisor
A Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.
-
firecracker-containerd
firecracker-containerd enables containerd to manage containers as Firecracker microVMs
-
sysbox
An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
gvisor discussion
gvisor reviews and mentions
-
Kubernetes Without Docker: Why Container Runtimes Are Changing the Game in 2025
gVisor: Sandboxed Container Runtime by Google For when your security team actually audits things.
-
Reverse Engineering OpenAI Code Execution to make it run C and JavaScript
> why would they be running such an old Linux?
They didn't.
OP misunderstood what gVisor is, and thought gVisor's uname() return [1] was from the actual kernel. It's not. That's the whole point of gVisor. You don't get to talk to the real kernel.
[1] https://github.com/google/gvisor/blob/c68fb3199281d6f8fe02c7...
-
WASM Will Replace Containers
You can use something like https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container.
E.g. here's I can read host filesystem even though uname says weird things about the kernel container is running in:
$ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash
-
Lies we tell ourselves to keep using Golang
To be pedantic for a moment...
> You can't use Go to write a kernel ...
Not a production kernel, but MIT did use Go to "study the performance trade-offs of using a high-level language with garbage collection to implement a kernel" [1]
There is also gVisor [2] which implements, as best as I can describe, a kernel in user space. It's intent is to intercept syscalls made in containers and to redirect its execution in a sandbox.
> ... program a microcontroller ...
I'm not sure if one would classify this as a microcontroller, but USB Armory did write a, iirc, Go compliant runtime for bare metal ARM and RISC-V [3]
[1] https://github.com/mit-pdos/biscuit
[2] https://gvisor.dev/
[3] https://github.com/usbarmory/tamago
-
Comparing 3 Docker container runtimes - Runc, gVisor and Kata Containers
Although the documentation also mentions "youki", that is mentioned as a "drop-in replacement" of the default runtime basically doing the same, so let's stick with runc. The second runtime will be Kata runtime from Kata containers, since it runs small virtual machines which is good for showing how differently it uses the CPU and memory. This also adds a higher level of isolation with some downsides as well. And the third runtime will be runsc from gVisor which is a perfect third runtime to see how we can run containers and still have a little more secure isolation. I will show how we can recognize the differences by running commands from the isolated environments and from the host.
-
GVisor: Linux-Compatible Sandbox
I find the README of the repo much better to quickly understand what this software is and isn't.
https://github.com/google/gvisor
-
Unfashionably secure: why we use isolated VMs
If you think about it virtualization is just a narrowing of the application-kernel interface. In a standard setting the application has a wide kernel interface available to it with dozens (ex. seccomp) to 100's of syscalls. A vulnerablility in any one of which could result in complete system compromise.
With virtualization the attack surface is narrowed to pretty much just the virtualization interface.
The problem with current virtualization (or more specifically, the VMM's) is that it can be cumbersome, for example memory management is a serious annoyance. The kernel is built to hog memory for cache and etc. but you don't want the guest to be doing that - since you want to overcommit memory as guests will rarely use 100% of what is given to them (especially when the guest is just a jailed singular application), workarounds such as free page reporting and drop_caches hacks exist.
I would expect eventually to see high performance custom kernels for a application jails - for example: gVisor[1] acts as a syscall interceptor (and can use KVM too!) and a custom kernel. Or a modified linux kernel with patched pain points for the guest.
[1] <https://gvisor.dev/>
- Syd the perhaps most sophisticated sandbox for Linux
-
Hacking Alibaba Cloud's Kubernetes Cluster
Hillai: Following our research, Alibaba took several steps to address the vulnerabilities we discovered. They limited image pull secret permissions to read-only access, preventing unauthorized uploads. Additionally, they implemented a secure container technology similar to Google's gVisor project. This technology hardens containers and makes them more difficult to escape from, adding another layer of security.
-
We Improved the Performance of a Userspace TCP Stack in Go by 5X
If you want to use netstack without Bazel, just use the go branch:
https://github.com/google/gvisor/tree/go
go get gvisor.dev/gvisor/pkg/tcpip@go
The go branch is auto generated with all of the generated code checked in.
-
A note from our sponsor - SaaSHub
www.saashub.com | 23 Jun 2025
Stats
google/gvisor is an open source project licensed under Apache License 2.0 which is an OSI approved license.
The primary programming language of gvisor is Go.