Skip to main content
The Agent Sandbox is where Noxus runs code it did not write: Run Code nodes and all plugin execution. It is a separate service with its own isolation model, and it is not deployed by default.
Plugins require the sandbox. The plugin system is switched on by the presence of SANDBOX_MANAGER_URL, which is only injected into the Noxus Backend and Workers when the sandbox is deployed. Without it, plugin nodes and triggers do not load — and nothing raises an error. They are simply absent from the platform.If you are upgrading from a release that ran a standalone plugin server, you must enable the sandbox or you will lose your plugins.

When you need it

You need it

You use plugins, or your workflows contain Run Code nodes that should be properly isolated.

You may not need it

No plugins and no Run Code nodes. The rest of the platform is unaffected by leaving it off.

Isolation modes

The sandbox runs jailed processes. Which jail it can use depends on what your platform lets a container request.
minimal constrains the filesystem and the network but not syscalls. It is meaningfully weaker than syd. Treat it as a compatibility fallback, not an equivalent option.

Platform compatibility

The network jail in minimal mode is enforced by a Kubernetes NetworkPolicy, which requires a CNI that implements policy. The azure-aks stack in noxus-infra sets network_policy = "cilium" for this reason; the default CNIs on EKS and GKE already enforce policy. Without an enforcing CNI the NetworkPolicy object exists and does nothing.

Configuration

The local fallback matters

LOCAL_SANDBOX_BACKEND is what a Worker uses when the remote sandbox is off or unhealthy:
  • none — no local execution. The safest setting when a remote sandbox is present, and the default the Helm chart selects when sandbox.enabled=true.
  • deno — a worker-local Deno/Pyodide runtime. Reasonable isolation, limited capability.
  • subprocess — runs user code as a plain subprocess in the Worker’s own process tree. Much weaker isolation. Do not use this in a multi-tenant deployment.
Setting LOCAL_SANDBOX_BACKEND=subprocess as a way to “make Run Code work without deploying the sandbox” gives untrusted code the Worker’s filesystem, network, and environment — including its database credentials.

Deployment

The sandbox is a Deployment in the Noxus Helm chart, off by default:
Enabling it also injects SANDBOX_MANAGER_URL into the Backend and Workers, and applies the sandbox NetworkPolicy.In the Terraform stacks the equivalent is sandbox_enabled = true, which is the default there.

Filesystem and state

The sandbox uses a copy-on-write filesystem whose state is periodically synced to object storage, so the pod itself can run on ephemeral disk. It reuses the platform’s existing storage configuration — BUCKET_CLIENT, SPOTFLOW_STORAGE_BUCKET, and whatever credentials or workload identity the Backend and Workers already use. No separate bucket is required.

Sizing

The sandbox’s own resource requests cover the manager, not the code it runs. Jailed processes draw from the same container limits, so a deployment running heavy Run Code workloads needs headroom above the defaults. Start at 1 vCPU / 2 GiB requests with 2 vCPU / 4 GiB limits, and raise the limits if you see sandbox restarts under load.

Health and troubleshooting

The sandbox manager exposes /health, used for all three probes.

Plugin Development

Build plugins that run inside the sandbox.

Environment Configuration

The full platform variable reference.