#Brew on linux
1 messages · Page 1 of 1 (latest)
For a Linux Docker container running OpenClaw, I’d generally avoid Homebrew.
Why:
- The Docker setup is meant to be reproducible + minimal (security-first, runs as the
nodeuser). - Homebrew inside containers adds a lot of extra moving parts (size, build deps, PATH/env headaches).
- Most “I need X binary for a skill” things are easier via apt during image build.
What to do instead (recommended):
- Follow the Docker guide: https://docs.openclaw.ai/install/docker
- Install system deps via the supported knob:
OPENCLAW_DOCKER_APT_PACKAGES="ffmpeg …"(bakes packages into the image)
When Brew does make sense:
- Only if you absolutely need a formula that’s annoying/unavailable via apt. In that case, it can work on Linux (FAQ: https://docs.openclaw.ai/help/faq#does-homebrew-work-on-linux) — but I’d treat it as the “last resort” path for containers.
If you tell me what you’re trying to install via brew (which tool / which skill), I can suggest the cleanest apt/package alternative for the Docker image.
I'm primarily thinking about it because I want my agent to be able to install packages by itself. And for apt it needs sudo permission I think
Homebrew won’t really solve the “agent can install stuff” problem in Docker — it just swaps one package manager for another (and adds a bunch of weight/complexity).
On the sudo/apt part: inside a container, apt only “needs sudo” if you’re running as a non-root user. The OpenClaw Docker image is intentionally run as node (non-root), so apt-get install … will fail unless you change that.
Recommended pattern (Docker-friendly + reproducible)
Bake packages into the image at build time, instead of letting the agent mutate the container at runtime:
- Use the Docker guide flow: https://docs.openclaw.ai/install/docker
- Set
OPENCLAW_DOCKER_APT_PACKAGESbefore running./docker-setup.sh, e.g.OPENCLAW_DOCKER_APT_PACKAGES="ffmpeg jq ripgrep"
This makes installs repeatable and survives container restarts.
If you really want the agent to install packages at runtime
You’d need to accept the security tradeoff and run the container as root (so apt-get works without sudo), e.g. via a Compose user: "0:0" override for the gateway/cli containers.
That works, but it’s basically giving the agent “root + network + package manager”, which is a big hammer (and makes debugging/rebuilds less deterministic).