✦ For everyone, free.

Practical knowledge for real and everyday life

Home

4.1.1.4 Dockerfile Runtime Config

A focused guide to Dockerfile Runtime Config, connecting core concepts with practical Docker and container operations.

Dockerfile runtime configuration covers the instructions — ENV, EXPOSE, USER, WORKDIR, CMD, and ENTRYPOINT — that define how a container should behave by default once started, as distinct from the instructions that build the image's filesystem content.

Setting Environment Variables

ENV defines environment variables that will be present in every container started from the image, available as sensible defaults that can still be overridden at run time.

ENV NODE_ENV=production
ENV PORT=8080
docker run -e NODE_ENV=development myapp:1.0
Documenting Exposed Ports

EXPOSE records which ports the application is expected to listen on, serving primarily as documentation and as a hint to tools that inspect the image, since it does not, by itself, make the port reachable from outside the container.

EXPOSE 8080
docker run -p 8080:8080 myapp:1.0

Actually publishing the port to the host still requires the explicit -p flag at run time.

Setting the Default User

USER determines which user a container's main process runs as by default, an important security consideration since running as a non-root user limits what a compromised process could do.

RUN useradd --create-home appuser
USER appuser
Setting the Working Directory

WORKDIR sets the directory the container's process starts in, and also affects relative paths used by later instructions in the same Dockerfile.

WORKDIR /app
COPY . .
CMD ["python", "app.py"]
Defining the Default Process

CMD and ENTRYPOINT together define what process actually runs when a container starts, with CMD providing overridable default arguments and ENTRYPOINT providing a fixed executable.

ENTRYPOINT ["python"]
CMD ["app.py"]
Why Runtime Configuration Instructions Matter

These instructions are what turn a built filesystem into something that actually behaves correctly as a running application by default — without them, a container started from the image would have no defined default behavior at all, requiring every caller to specify everything explicitly every time.