Why run a CLI tool as a throwaway `docker run --rm` container instead of installing it on the host?

### The idiom Most discussion of Docker assumes long-running services, but a large share of everyday use is the opposite: start a published image, have it do one job against your files, and throw the container away. The shape is always the same — bind the current directory into the container, set the working directory to the same path, add `--rm` so the stopped container is disposed of instead of accumulating, and put the command and its arguments after the image name: ```bash docker run --rm -v "$PWD":/work -w /work sometool:2.4 validate ./billing ``` ### Why do it at all **Version pinning without installation.** The tool version is a tag in a script in the repository, so every engineer and the CI runner execute the identical build. Nobody's machine drifts, and two projects needing different versions of the same tool do not fight. **No host pollution.** Linters, formatters, protocol compilers, database clients and one-off converters arrive and leave without a package manager, which matters most on machines where you cannot install software freely. **Local/CI parity.** The command in the CI job and the command a developer types are the same string, so 'works on my machine' has one fewer cause. **Trying something once.** Running an unfamiliar tool inside a container that gets deleted, with only one directory visible to it, is a considerably smaller commitment than installing it. ### The ownership trap The failure everyone hits first: on a Linux host, a bind mount is the host's own filesystem, and the process inside the container usually runs as root. Files it creates are therefore owned by root on the host, and the next ordinary command that touches them fails with a permission error — commonly discovered when a subscription-billing service's generated output cannot be deleted by the engineer who generated it. There is no translation layer: the UID inside is the UID recorded on disk. The fix is to tell the container which identity to run as, `--user "$(id -u):$(id -g)"`, so the output belongs to you. Two caveats. Some images need to do privileged work at startup and break when you override the user, in which case fixing ownership afterwards, or writing output to a location you can chown, is the pragmatic route. And Docker Desktop's file-sharing layer on macOS and Windows presents host files as owned by the container's user, so the problem is largely invisible there and then appears the moment the same command runs on a Linux CI runner — which is exactly the kind of environment difference this idiom was supposed to eliminate. ### What the container cannot see A tool container is not a shell on your machine. It sees the paths you mounted and nothing else, so a tool that follows a relative path out of the project, resolves a symlink to elsewhere on the host, or expects a configuration file in your home directory will fail in ways that look like tool bugs. It also has its own network view: a tool that must reach a service running on the host, or another container, needs that arranged explicitly rather than assuming `localhost` means what it means outside. And each invocation pays container startup, which is small but not free — in a loop that runs the tool once per file, it dominates. ### Making it usable Nobody remembers a four-flag command, so the idiom lives in a checked-in wrapper: a small shell script, a task-runner target, or a Makefile rule that fixes the image tag, the mount, the working directory and the user in one place. That is what turns it from a party trick into a real toolchain choice — the repository now declares its tools the way it declares its dependencies, and onboarding a new engineer requires nothing but a container engine. ### When not to Do not do this for tools you use constantly and interactively where startup latency and lost shell integration (completion, history, editor plugins) hurt more than version drift does; and do not do it for a tool that needs broad access to the host anyway, because you will end up mounting so much that the isolation you were buying is gone. The idiom is at its best for build-time, check-time and one-off tools with a narrow, file-shaped job.