gVisor implements a large portion of the Linux surface and while we strive to make it broadly compatible, there are (and always will be) unimplemented features and bugs. The only real way to know if it will work is to try. If you find a container that doesn’t work and there is no known issue, please file a bug indicating the full command you used to run the image. You can view open issues related to compatibility here.
If you’re able to provide the debug logs, the problem likely to be fixed much faster.
gVisor is widely used as a container runtime supporting arbitrary user-provided workloads in Cloud products such as DigitalOcean’s App Platform or Google’s Cloud Run. See the Users page for more. The decision to use gVisor for these products means that compatibility issues are not a common problem for most workloads in practice.
While gVisor only implements a subset of the Linux syscall ABI, the
unimplemented part of the ABI is mostly comprised of alternatives to existing
syscalls that gVisor does support. For example, gVisor does not fully support
io_uring-related syscalls, but does support other I/O-related syscalls. Most
language runtimes and libraries will automatically determine which syscall
variant they should use, so they will work in gVisor. For this reason, looking
through the list of supported syscalls is not necessarily a good
measure of how widely compatible gVisor is in practice.
gVisor releases go through the regression tests of popular language runtimes (Python, Java, Node.js, PHP, Go) to ensure continued compatibility with the base libraries of these languages. This means most programs written in these languages will work.