Create Docker Image
in Seconds

1Choose a Base Image

Every Dockerfile starts with a FROM instruction that specifies the base image. Choose an image that matches your application's runtime requirements. For production, prefer official images and specific version tags over latest to ensure reproducibility.

FROM node:20-alpine

2Set the Working Directory

Use WORKDIR to set the working directory for subsequent instructions. This creates the directory if it does not exist and sets it as the current directory for RUN, COPY, CMD, and other instructions.

WORKDIR /app

3Copy Dependencies First

Copy dependency files separately before copying application code. This leverages Docker's layer caching — if dependencies have not changed, Docker reuses the cached layer, significantly speeding up rebuilds.

COPY package.json package-lock.json ./
RUN npm ci --only=production

4Copy Application Code

After installing dependencies, copy the rest of your application code. Use a .dockerignore file to exclude unnecessary files like node_modules, .git, and local configuration files.

COPY . .

5Expose Ports and Set the Command

Use EXPOSE to document which ports your application listens on. Finally, use CMD to specify the default command that runs when the container starts.

EXPOSE 3000
CMD ["node", "server.js"]

What is the difference between CMD and ENTRYPOINT?

Both CMD and ENTRYPOINT define what command runs when a container starts, but they serve different purposes. ENTRYPOINT defines the main executable and is harder to override (requires --entrypoint flag). CMD provides default arguments that can be easily overridden by passing arguments to docker run. Best practice: use ENTRYPOINT for the main command and CMD for default arguments. For example: ENTRYPOINT ["python"] and CMD ["app.py"] allows users to easily run python other.py instead.

How do I reduce Docker image size?

Several strategies help minimize image size: (1) Use multi-stage builds to separate build dependencies from runtime. (2) Choose minimal base images like Alpine or distroless. (3) Combine RUN commands to reduce layers. (4) Remove package manager caches (apt-get clean, rm -rf /var/lib/apt/lists/*). (5) Use .dockerignore to exclude unnecessary files. (6) For compiled languages like Go, use scratch as the final base image. A typical Node.js image can go from 1GB+ to under 100MB with these techniques.

Should I use Alpine or Debian base image?

Alpine Linux produces much smaller images (5MB vs 120MB for Debian slim) but uses musl libc instead of glibc, which can cause compatibility issues with some software. Use Alpine when: image size is critical, your dependencies are compatible, or you are using interpreted languages like Node.js or Python. Use Debian when: you need glibc compatibility, require specific system packages, or encounter strange runtime errors with Alpine. For production, Debian slim is often a good balance.

What is a multi-stage build?

Multi-stage builds use multiple FROM statements in a single Dockerfile. Each FROM starts a new build stage that can copy artifacts from previous stages. This allows you to use a full SDK image for building (with compilers, dev tools) and a minimal runtime image for production. The final image only contains what you explicitly copy into it, dramatically reducing size. Example: build a Go app in golang:1.22 stage, copy only the compiled binary to a scratch or alpine final stage.

How do I handle environment variables in Docker?

Docker supports environment variables through multiple mechanisms: (1) ENV instruction in Dockerfile sets permanent defaults baked into the image. (2) ARG instruction defines build-time variables that are not present in the final image. (3) docker run -e or --env-file passes runtime variables. (4) Docker Compose environment or env_file in docker-compose.yml. Best practice: use ENV for non-sensitive defaults, ARG for build-time config like version numbers, and runtime injection for secrets and environment-specific settings.

How do I debug a failing Docker build?

When a Docker build fails: (1) Read the error message carefully — it usually indicates the exact line and command that failed. (2) Run the failing command manually in an interactive container: docker run -it <base-image> sh. (3) Use docker build --progress=plain for more verbose output. (4) Add temporary RUN commands to inspect the filesystem state. (5) For complex builds, build up to a specific stage with --target flag. (6) Check that all files referenced in COPY exist and are not in .dockerignore.