Traditional containers use Linux namespaces to establish resource limits, but a malicious deployment could potentially breach container boundaries. Magic Containers addresses this by using gVisor as the container runtime.
gVisor intercepts application system calls and handles them in a user-space kernel, creating strong isolation between the application and the host kernel without the overhead of full virtualization.
Syscall Compatibility
gVisor implements a subset of Linux system calls. While most common applications work without modification, some workloads that rely on specialized or less common syscalls may experience compatibility issues. Applications using standard networking, file I/O, and process management typically work without issues.
For a complete list of supported syscalls, see the gVisor compatibility documentation.
Ping and ICMP
Outbound ICMP is allowed, so ping works from your containers. The sandbox does not grant the CAP_NET_RAW capability, so applications cannot open raw sockets. Instead, ping uses an unprivileged ICMP socket. This works for root and non-root users.
On Debian and Ubuntu, the iputils-ping package installs ping with the file capability cap_net_raw+ep. The sandbox cannot grant this capability, so the binary does not start, even as root:
Remove the file capability when you build the image:
Keep libcap2-bin installed. iputils-ping depends on it, so removing it also removes ping.
Alpine images need no change. Alpine’s iputils-ping and BusyBox ping both work without the capability.
Network Isolation
Magic Containers uses Virtual Extensible LAN (VXLAN) to create virtual networks over the physical infrastructure. This provides scalable connectivity between containers across different hosts while maintaining isolation and segmentation. Last modified on November 3, 2026
