Containerized Local Tools
Some development tools are useful but annoying to install directly. A container can make the tool disposable: pull an image, expose the service locally, mount the current workspace, and stop the container when done.
The command looks compact, but each flag owns a different boundary.
docker run \
-p 8080:8080 \
-p 8081:8081 \
--pull always \
-u $(id -u):$(id -g) \
-v "$(pwd):/data" \
livebook/livebook
What the Flags Mean
| Flag | Boundary it manages |
|---|---|
-p host:container |
Makes a port inside the container reachable from the host machine. |
--pull always |
Checks for a newer image before starting. |
-u $(id -u):$(id -g) |
Runs the container process as the current host user and group. |
-v "$(pwd):/data" |
Mounts the current directory into the container. |
The user mapping matters because mounted files are real host files. If the process runs as root inside the container, it may create files that are awkward to edit or delete from the host account.
The workspace mount is a bind mount: the host and container see the same files. That suits source code edited on the host. Data owned by the application may fit a named volume instead. See Docker volumes and bind mounts for the storage trade-off.
Smallest Safe Model
For a local web tool, decide four things explicitly:
- Which host ports should open?
- Which directory should the tool be allowed to read and write?
- Which user should own generated files?
- Should the image be refreshed every run or pinned for repeatability?
A one-line docker run command is easier to trust when those choices are visible.