OpenClaw in a rootless Podman container

Podman is the container path for people who do not want Docker, and the docs give it a model of its own: Podman runs the Gateway container rootless as your current user, the host CLI is the control plane, persistent state lives on the host under the OpenClaw directory, and day-to-day management goes through a container flag rather than a service user or exec commands. Here is the setup, the launcher and onboarding, Quadlet for boot persistence, the Tailscale notes, and the point the docs separate carefully: the Gateway in Podman is not the same thing as agent sandboxing in Podman.

Your host openclaw CLI is the control plane.

The setup

• One-time setup from the repository root: the script builds a local image in your rootless store, or pulls one named in an environment variable, creates the config with local Gateway mode if missing, and creates an environment file with a generated Gateway token if missing; build-time variables can add apt or pinned Python packages, compile selected plugins, or pre-install Chromium for browser automation.
• Launch: the run script starts the container as your uid and gid with the keep-id user namespace and bind-mounts your OpenClaw state into it.
• Onboarding inside the container through the launcher’s setup mode, then the dashboard on loopback with the token from the environment file; model auth stays in the mounted state, because the launcher does not mount host CLI credential homes into the container.
• Management: export the container name once and ordinary commands, dashboard, deep Gateway status, doctor, channel login, run inside it automatically; the launcher passes only an allowlist of Podman-related keys from the environment file, never the whole file.

Quadlet and Tailscale

On Linux with systemd user services, the setup script’s Quadlet flag installs a container unit so the Gateway starts, stops and restarts as a user service and can survive boot with lingering enabled. For HTTPS or remote browser access the docs point at the main Tailscale guidance with Podman-specific notes: keep the publish host on loopback, prefer host-managed Serve over the Gateway’s own Tailscale flag, and on macOS, where the Podman machine can make the browser look non-local and trip device auth, use Tailscale access rather than ad hoc tunnels.

The sandbox backend

• Running the Gateway in Podman is one thing; agent sandboxing is another, selected by the sandbox backend setting.
• The Podman backend reuses the same container settings as the Docker sandbox but executes them through the native Podman CLI; the default backend is Docker-only.
• Browser sandboxes remain Docker-only for now.

OpenClaw on Docker is the sibling page most people read first, and OpenClaw sandboxing explained explains the backend setting this page separates from the Gateway container.

Why rootless matters

A rootless container as your own user means no service account, no sudo in daily use, and state that is plainly yours under your home directory, which is why the docs can route every command through the host CLI. OpenClaw and Tailscale covers the access side once the container is up.

On Diali

On Diali the container is an isolated instance we run, and the control plane is the dashboard rather than a CLI with a container flag; the sandbox question is answered per assistant, not per host. Hosted OpenClaw on Diali is the assistant.

• Rootless, your user, state on the host.
• The host CLI drives the container through one variable.
• Gateway in Podman and sandbox in Podman are two settings.