Setting up the sandbox runtime
Install and register the gVisor sandbox runtime so each SonarQube Server agentic job runs in its own isolated container. This page is for SonarQube Server 2026.5.
Every agentic job runs in its own container, and that container is sandboxed. The sandbox is not optional: it's the control that keeps code influenced by a large language model away from your host.
SonarQube Server uses gVisor as the sandbox runtime, in the form of its runsc runtime handler. gVisor intercepts system calls in user space instead of passing them to the host kernel, so a job that tries something destructive affects only its own sandbox.
gVisor uses its Systrap platform by default, which needs no hardware virtualization. That means you don't need /dev/kvm, so the sandbox runs on standard cloud instances and on hardened nodes where nested virtualization is disabled.
Why per-job isolation
A job runs a destructive command
The damage is contained in the sandbox. The root filesystem is read-only, and only the project and output folders are writable
A job tries to exfiltrate source code or credentials
Restricts outbound access to an explicit list of destinations, and blocks everything else
A job consumes unbounded resources
Applies CPU, memory, and process limits per container. The Orchestrator fails a job that exceeds its time limit
A job attempts to escape onto the host
Handles system calls in user space, behind a second restrictive system call filter
Because each job gets its own container, container isolation is job isolation. There's no sharing between concurrent jobs to reason about.
Fail-closed behavior
Sandbox selection is enforced, not advisory. There's no silent fallback to an unsandboxed container.
The sandbox runtime is not registered
The container refuses to start, reporting an unknown runtime
The runtime is registered but the image architecture doesn't match the host
The container crashes on start with exec format error
If jobs won't start, this is the first thing to check. See Troubleshooting.
On Kubernetes
On Kubernetes, gVisor is installed on the nodes and selected per pod through a RuntimeClass. The Helm chart creates the RuntimeClass and sets it on the agent runtime pods for you.
You have two ways to get runsc onto the nodes.
Provisioning the nodes yourself
This is the recommended approach for production. Install runsc on the nodes that run agentic jobs, configure containerd with the runsc runtime handler, then deploy with the chart's installer turned off:
Use this approach when your platform team manages node configuration, when your cluster policy doesn't allow privileged workloads, or in air-gapped environments where you supply runsc yourself.
On managed Kubernetes services, use the provider's own mechanism instead of installing gVisor by hand. On Google Kubernetes Engine, GKE Sandbox provides gVisor natively and exposes the same RuntimeClass.
Using the chart installer
The chart can install gVisor for you with a DaemonSet. This is convenient for self-managed clusters and for evaluation.
The installer downloads and verifies runsc, writes the sandbox configuration, registers the runtime handler with containerd, and validates the configuration before restarting containerd. If any step fails, it restores the previous containerd configuration. It labels a node as ready for sandboxed workloads only after it confirms runsc is working there.
The installer is only for self-managed nodes. Don't use it on a managed service that provides its own mechanism.
Choosing which nodes run jobs
By default, the chart schedules agentic jobs onto nodes labeled for gVisor, and the installer targets all nodes. To confine jobs to a subset of your cluster, label those nodes and set a node selector. To install on every node, leave the installer's node selector empty.
For the full list of values, see Deploying with the Helm chart.
On a Docker host
On a Linux host running Docker Engine, install gVisor on the host and register runsc as a Docker runtime. The agent runtime containers then request it by name.
Two sandbox settings are worth knowing about, because they affect how jobs behave:
The sandbox uses the host network stack, which avoids the sandbox network layer interfering with name resolution. Isolation between the job and your network still comes from the outbound restrictions described in Before you start
The sandbox provides a bounded writable overlay, which caps how much disk a job can use. Docker's own controls cannot cap it
Keep the gVisor version consistent across your hosts and your cluster nodes. When you update it in one place, update it everywhere in the same change.
Next step
With the sandbox runtime registered, provision shared storage. See Setting up shared storage.
Related pages
Last updated
Was this helpful?