Short answer with a wink

If you want a reproducible image that you can push to a registry and brag about in your CI logs use a Dockerfile. If you want to start three containers that pretend to be an application for local testing use docker compose. One is a recipe for an image. The other is a party planner for containers.

Build versus run explained

Dockerfile defines how to build images. It lists base image layers copies configuration and sets the default process. This is the place to pin versions optimize layers and use multi stage builds to keep images tiny. Docker compose uses a yaml file to declare services networks and volumes so multiple containers can start together with one command. Compose handles environment variables port mapping and simple scaling for development or small deployments.

Typical workflow

• Write a Dockerfile that builds a reproducible image
• Create a docker compose yaml that wires services networks and volumes
• Use docker build then docker compose up to run the full stack locally

Example commands and files

Build an image from a Dockerfile with a simple command

docker build -t myapp .

Start services with docker compose

docker compose up

Minimal docker compose yaml example

version: '3.8'
services:
  web:
    image: myapp:latest
    ports:
      - "8080:80"
    environment:
      - DATABASE_URL=postgres://db:5432/mydb
  db:
    image: postgres:14
    volumes:
      - db_data:/var/lib/postgresql/data
volumes:
  db_data:

When to pick Dockerfile

• You need a reproducible image for CI pipelines or registry deployment
• You want to optimize layers pin dependencies or do multi stage builds
• You must keep build concerns out of runtime wiring

When to pick Docker Compose

• You are running multiple containers together for development or testing
• Your orchestration needs are light and you want easy local networking
• You want to declare services networks and volumes in a single yaml file

Practical devops tips

• Keep secrets out of images and out of compose files. Use env files or a secret manager for sensitive values.
• Use multi stage builds in Dockerfile to reduce image size and remove build tools from final image.
• Let Dockerfile own build details and let docker compose handle runtime wiring and scaling for local stacks.
• Push built images to a registry then reference those images in your compose file for consistent deployments.

Gotchas worth your eye roll

Compose is not a full production orchestrator. If you need advanced scheduling high availability or complex service discovery look at Kubernetes or a managed orchestration service. Also remember that docker compose networks are convenient but different from cloud networking so test in an environment that resembles production.

Final takeaway

Use Dockerfile to build and Docker Compose to run. Keep build logic in the Dockerfile and runtime wiring in compose. Treat images as immutable artifacts and use compose for local development stacks and simple deployments. Now go build something and try not to commit a secret to the image like it is still 2015.