ENV, WORKDIR, and EXPOSE in Dockerfile

Direct Answer

WORKDIR sets the working directory for later Dockerfile instructions and the default container process, creating it if needed. ENV adds environment defaults to image configuration and affects later build instructions and containers unless overridden. EXPOSE documents intended listening ports; it does not publish them to the host.

Code Example

FROM eclipse-temurin:17-jre-alpine

WORKDIR /app

COPY target/payment-service-1.0.0.jar app.jar

ENV SPRING_PROFILES_ACTIVE=prod
ENV JAVA_OPTS="-Xmx512m -Xms256m"

EXPOSE 8080

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

Common Mistakes & Pitfalls

• Not using WORKDIR: Freshers skip WORKDIR and use absolute paths like COPY target/app.jar /app/app.jar, then RUN commands fail because the working directory is still /. Always set WORKDIR early so subsequent commands use relative paths.
• Thinking EXPOSE publishes the port: The biggest mistake is believing EXPOSE 8080 makes the container accessible on localhost:8080. It doesn't. EXPOSE is documentation only. You must use docker run -p 8080:8080 to actually map the port. Without -p, the container runs but the port isn't reachable from the host.
• Hardcoding secrets in ENV: Freshers write ENV DB_PASSWORD=secret123 in the Dockerfile, baking the secret into the image. Anyone who pulls the image can see it with docker history. Use ENV for non-sensitive config only, and pass secrets at runtime with docker run -e.
• Overusing ENV for build-time variables: ENV persists into the running container. If you only need a variable during the build, use ARG instead of ENV to avoid cluttering the runtime environment.