Set PATH in a Dockerfile

For a Linux image, use ENV to persist an updated executable search path:

ENV PATH="/opt/app/bin:${PATH}"

The directory goes before the existing value, so its commands take priority. The image supplies this environment to subsequent build steps in that stage and to containers created from the image, unless runtime configuration overrides it.

A concrete example

This example assumes your build context contains an executable shell script named hello with a valid #!/bin/sh interpreter line:

FROM debian:bookworm-slim
COPY --chmod=755 hello /opt/app/bin/hello
ENV PATH="/opt/app/bin:${PATH}"
CMD ["hello"]

If you install Python tools into a nonstandard prefix instead, changing PATH locates their executables but does not automatically add their modules to Python's import path. A virtual environment often provides a clearer arrangement:

FROM python:3.12-slim-bookworm
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:${PATH}"
COPY requirements.txt /tmp/requirements.txt
RUN python -m pip install -r /tmp/requirements.txt
CMD ["python", "-V"]

Replace the final command with the installed application's entry point. The example prints the interpreter version rather than assuming a fictional package supplies a particular command.

Why a RUN export disappears

RUN export PATH="/opt/tool/bin:$PATH" && tool --version

That export affects the shell and processes launched in this one step. A later RUN starts from the image configuration, not the previous shell's process environment. Files written by a build step can persist, but an exported shell variable alone does not.

Use ENV for an image-wide default, or an explicit absolute executable path when only one command needs it. An entrypoint script can also set and export PATH before executing the application; it affects that process tree rather than rewriting the image.

Build arguments and precedence

ARG INSTALL_DIR=/opt/tool
ENV PATH="${INSTALL_DIR}/bin:${PATH}"

This assumes the tool is installed at that location. Build arguments can parameterize the value, but secrets do not belong in either ordinary build arguments or image environment metadata.

Linux search paths are colon-separated and searched in order. Prepending a writable or untrusted directory can make it override expected system tools. Appending a directory makes it a fallback. Windows container path and shell rules differ; these examples are for Linux images.

FAQ

Does docker run -e override ENV? Yes, an explicit runtime value replaces the image's value for the configured container. Be careful not to substitute the host machine's PATH accidentally in your shell command.

Can I change PATH after startup? A process can change its own environment and pass it to children. An interactive shell export does not rewrite an unrelated main process. docker exec -e PATH=... changes only that exec process and its descendants.

Does an entrypoint export help? Yes, when the script exports the value and launches the application from that environment, typically with exec. It will not affect a separate later exec process unless that value also exists in the container's configured environment.

See Dockerfile reference, Docker exec reference, Python virtual environments.