---
title: Docker & Podman Sandbox
description: Hardened container execution, resource limits, and network isolation.
sidebar:
  order: 2
  label: Docker & Podman Sandbox
---
NIKI's primary execution backend runs in rootless Podman or Docker containers.

---

## Configuration (`[docker]`)

Control memory quotas, CPU limits, capabilities, and network behavior in `niki.toml`:

```toml
[docker]
backend          = "docker"              # "docker" (container) or "worktree" (git worktree, no isolation)
base_image       = "niki-sandbox:24.04"  # base image
memory_limit     = "2g"                  # memory limit
cpu_limit        = 2.0                   # max CPU cores
pids_limit       = 512                   # max child processes (fork bomb guard)
cap_drop_all     = true                  # drops all Linux capabilities
network_disabled = true                  # blocks all outbound network traffic
readonly_rootfs  = false                 # enables read-only root filesystem
extra_packages   = ["nodejs", "npm", "python3"]
```

---

## Network Egress Control

By default, `network_disabled = true` prevents agent-generated code from sending outbound network requests or exfiltrating data.

If your tests require downloading dependencies or reaching specific staging servers, configure a strict `network_allowlist`:

```toml
[docker]
network_disabled  = false
network_allowlist = ["registry.npmjs.org", "crates.io", "pypi.org"]
```

---

## Remote Daemon (Cloud-Adjacent Execution)

NIKI honors the standard `DOCKER_HOST` environment variable when connecting
to the container runtime. Point it at a remote daemon to execute agent
containers on another machine (a cloud VM, a beefy workstation) instead of
locally — no NIKI-side changes needed:

```bash
export DOCKER_HOST="ssh://user@build-host"
niki run "Migrate the test suite to vitest" --project ./my-app
```

Requirements and honest limits:

- The remote daemon must already have the sandbox image (`niki-sandbox:24.04`
  or your configured `base_image`); NIKI pulls it on demand where the daemon
  allows, but a private registry needs its own auth setup.
- The project source is sent to the remote daemon as build/run context —
  treat the remote host with the same trust you give your own machine.
- Prefer SSH with key auth; unencrypted `tcp://` daemons expose root-equivalent
  API access to anyone on the path. NIKI never downgrades this for you.
- `niki doctor` checks the *local* toolchain; remote image presence surfaces
  as a mid-run error, not a doctor failure (yet).

A managed NIKI cloud (hosted runners, no daemon of your own) remains roadmap,
not a feature: this page documents what works today.