Docker setup

Requirements

• Docker Engine on Linux, WSL2, or macOS. That's the only dependency.
• Enough headroom for your workload — agent turns, dev servers, and builds run on your hardware, so a sandbox uses what your work uses. There are no imposed CPU or memory caps.

Installing Docker

The connect one-liner installs Docker for you if it's missing — but it asks first. In an unattended setup, set INSTALL_DOCKER=1 to skip the prompt, or install Docker yourself beforehand and the script will just use it.

What runs

Connecting starts two containers and opens no inbound ports:

• The sandbox — the published image (registry.gitlab.com/radarsu/intentic/sandbox), running unprivileged by default. Your workspace lives at /work; snapshots live on a separate /history volume mounted outside /work, so an agent rm -rf can't reach your history.
• cloudflared — a sidecar that dials out to serve the sandbox over its private tunnel.

The isolated Docker engine

Some work needs Docker inside the sandbox — pnpm db:up, docker compose, a local database. The image bakes its own Docker Engine, dormant until you add the docker capability, which flips a single privileged directive and wakes it. The agent's containers then live entirely inside the sandbox's own engine — the host's Docker socket is never mounted, so nothing the agent runs can touch the machine outside the sandbox.

Environment overlays

A sandbox's tools aren't described in a prompt — they're installed in the image. When a job needs a library or CLI, the agent proposes a Dockerfile layer (RUN/ENV only, on a pinned base); nothing changes until you approve it, and the rebuild runs outside the container against the approved hash. So an agent can never rebuild its own environment without your sign-off. Typical additions: a database client like psql, a headless browser, or your language toolchain.

Update, rebuild, cleanup

The same vanity host that serves the connect script serves the lifecycle helpers:

# Remove a sandbox — lists yours, asks before deleting its /work + /history
curl -fsSL https://intentic.dev/cleanup | sh

# Update (pull latest :stable, recreate in place) and rebuild (apply an approved
# overlay) take your sandbox's slug — the platform hands you the exact command:
curl -fsSL https://intentic.dev/update  | sh -s -- <SLUG>
curl -fsSL https://intentic.dev/rebuild | sh -s -- <SLUG> <SHA256>

Update pulls the latest :stable image and recreates the container in place, preserving /work and /history; rebuild applies an owner-approved environment overlay, with the hash as the trust anchor; cleanup removes a sandbox's containers, named volumes, and networks. The platform surfaces the exact update and rebuild commands on your Sandbox and Environment cards when they apply. connect and cleanup also have PowerShell twins (add .ps1) for Windows. Removing a sandbox never requires Pro.