Docker CLI Cheat Sheet: The Commands Every AI Coder Actually Uses

Why AI Coders Need This

Here's what happens when you ask Claude or ChatGPT to build something real — like a web app with a database. The AI doesn't just write your app code. It generates a Dockerfile, a docker-compose.yml, and then tells you to run commands in your terminal that look like this:

docker compose up --build -d

If you don't know what that means, you're stuck. You can't debug it. You can't tell if it's working. And when something breaks (it will), you don't know where to look.

You don't need to become a Docker expert. You need to know what each command does, when you'd use it, and what to check when things go sideways. That's what this page is for.

If you haven't read our guide on what Docker actually is and why it exists, start there. This page assumes you know the basic concept and want the practical commands.

Real Scenario: AI Just Generated Docker Files

Claude generates your app code, then drops a Dockerfile and a docker-compose.yml into your project, and says:

# Build and start everything
docker compose up --build

# Your app is running at http://localhost:3000

Looks simple enough. But what's actually happening? What if port 3000 is already in use? What if the database doesn't start? What if you need to see error logs?

Let's break down every command you'll need.

The Commands You'll Actually Use

docker build — Turn Code Into a Container Image

What it does: Reads your Dockerfile (a recipe for your app's environment) and creates an image — a snapshot of your app with everything it needs to run.

When you use it: When AI gives you a Dockerfile and you need to create the image before running it.

# Basic build (run from the folder with your Dockerfile)
docker build -t my-app .

# What the flags mean:
# -t my-app    → Give this image a name ("tag") so you can refer to it later
# .            → Look for the Dockerfile in the current directory

Plain English: Think of it like compiling a recipe into a frozen meal. The Dockerfile is the recipe, docker build does the cooking, and the image is the frozen meal ready to heat up whenever you want.

💡 Tip: If you're using docker compose up --build, it runs docker build automatically. You usually don't need to run docker build separately unless you're testing the image on its own.

docker run — Start a Container

What it does: Takes an image and starts a running container from it. A container is a live instance of your app.

When you use it: When AI tells you to run a single service, like a database or a standalone app.

# Run a PostgreSQL database
docker run -d --name my-db -p 5432:5432 -e POSTGRES_PASSWORD=secret postgres:16

# What the flags mean:
# -d                        → Run in the background ("detached")
# --name my-db              → Name this container "my-db"
# -p 5432:5432              → Map port 5432 on your machine to 5432 in the container
# -e POSTGRES_PASSWORD=...  → Set an environment variable inside the container
# postgres:16               → Use the official PostgreSQL 16 image

Plain English: If docker build creates the frozen meal, docker run puts it in the microwave and hits start. The -d flag means "run in the background so I get my terminal back."

Understanding environment variables (the -e flags) is essential here — they're how you pass configuration like passwords and API keys into containers without hardcoding them.

docker compose up — Start Everything at Once

What it does: Reads your docker-compose.yml file and starts all the services defined in it — your app, your database, your cache, whatever AI put in there.

When you use it: This is the command you'll run most often. Any time AI generates a multi-service project, this is how you start it.

# Start everything
docker compose up

# Start everything and rebuild images first
docker compose up --build

# Start in the background
docker compose up -d

# Start and rebuild in the background
docker compose up --build -d

Plain English: Instead of running docker run separately for your app, your database, and your cache, docker compose up starts them all at once and wires them together so they can talk to each other.

⚠️ Common gotcha: If you run docker compose up without -d, it takes over your terminal. You'll see all the logs streaming live, which is great for debugging but means you can't type other commands. Press Ctrl+C to stop everything. Use -d to run in the background.

docker compose down — Stop and Clean Up Everything

What it does: Stops all running containers from your compose file and removes them. Clean slate.

When you use it: When you're done working, when something is broken and you want a fresh start, or before rebuilding.

# Stop everything
docker compose down

# Stop everything AND delete the database data
docker compose down -v

# ⚠️ The -v flag deletes volumes (your data). Only use this for a true reset.

Plain English: This is the "turn it all off and clean up" button. Without -v, your database data survives so you can start back up where you left off. With -v, everything is wiped — like reinstalling the app from scratch.

docker ps — See What's Running

What it does: Lists all currently running containers. Think of it as "Task Manager for Docker."

When you use it: When you need to know what's running, what ports they're on, or grab a container name for another command.

# Show running containers
docker ps

# Show ALL containers (including stopped ones)
docker ps -a

What you'll see:

CONTAINER ID   IMAGE        STATUS         PORTS                    NAMES
a1b2c3d4e5f6   my-app       Up 2 minutes   0.0.0.0:3000->3000/tcp   my-app-web-1
f6e5d4c3b2a1   postgres:16  Up 2 minutes   0.0.0.0:5432->5432/tcp   my-app-db-1

Plain English: This tells you "yes, your app is running on port 3000 and your database is running on port 5432." If a container shows Exited instead of Up, something crashed — check the logs.

docker logs — See What Went Wrong

What it does: Shows the output (logs) from a container. This is where error messages live.

When you use it: When something isn't working and you need to know why. This is your first debugging step.

# See logs for a container
docker logs my-app-web-1

# Follow logs in real-time (like a live feed)
docker logs -f my-app-web-1

# Show only the last 50 lines
docker logs --tail 50 my-app-web-1

Plain English: Imagine every container has a diary where it writes down everything that happens. docker logs lets you read that diary. When your app crashes, the reason is almost always in here.

💡 Pro tip: Copy the error from docker logs and paste it back to your AI. "My container is showing this error: [paste]. What's wrong and how do I fix it?" This is the most effective way to debug Docker issues as a vibe coder. Check out our terminal commands guide for more debugging techniques.

docker exec — Run Commands Inside a Container

What it does: Opens a connection to a running container so you can run commands inside it — like opening a terminal directly into the container's world.

When you use it: When you need to peek inside a container, check files, connect to a database directly, or debug something hands-on.

# Open a shell inside a container
docker exec -it my-app-web-1 /bin/sh

# Run a single command inside a container
docker exec my-app-db-1 psql -U postgres -d myapp

# What the flags mean:
# -it  → "interactive terminal" — gives you a live command prompt inside the container

Plain English: If a container is a sealed box running your app, docker exec opens a window into that box so you can look around and poke at things. When you're done, type exit to leave.

docker stop — Stop a Single Container

What it does: Stops one specific running container (without tearing down everything like docker compose down).

# Stop a specific container
docker stop my-app-web-1

# Stop all running containers at once
docker stop $(docker ps -q)

Docker Compose Explained Simply

When AI generates a project with Docker support, it almost always creates a file called docker-compose.yml (or compose.yml). This file is the blueprint that tells Docker which services to run and how to connect them.

Here's a real example AI might generate:

# docker-compose.yml — AI generated this for your task manager app
version: '3.8'

services:
  web:                          # Your app
    build: .                    # Build from the Dockerfile in this folder
    ports:
      - "3000:3000"             # Make it available at localhost:3000
    environment:
      - DATABASE_URL=postgresql://postgres:secret@db:5432/taskmanager
    depends_on:
      - db                      # Start the database first

  db:                           # Your database
    image: postgres:16          # Use official PostgreSQL
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=taskmanager
    volumes:
      - pgdata:/var/lib/postgresql/data   # Keep data between restarts

volumes:
  pgdata:                       # Named volume for database persistence

What each section means:

• services: — Each indented block is one container. This example has two: web (your app) and db (PostgreSQL).
• build: . — "Build this service from the Dockerfile in the current directory."
• image: postgres:16 — "Don't build anything, just download and use this pre-made image."
• ports: — Maps container ports to your machine. "3000:3000" means localhost:3000 reaches the container's port 3000.
• environment: — Sets environment variables inside the container.
• depends_on: — "Start db before starting web."
• volumes: — Persistent storage. Without this, your database data disappears when the container stops.

The key insight: Your web service connects to the database using db as the hostname (not localhost). Docker Compose creates a private network where services find each other by their service name. This catches a lot of people off guard.

What AI Gets Wrong About Docker

AI is great at generating Docker configurations. It's also consistently wrong about a few things. Here are the three mistakes you'll see most often:

Mistake 1: Exposing Ports That Shouldn't Be Public

AI loves to map every port to your host machine. You'll see this in the compose file:

# ❌ AI often does this
db:
  image: postgres:16
  ports:
    - "5432:5432"    # This makes your database accessible from outside!

For local development, this is fine. But if you deploy this to a server, you've just made your database accessible to the entire internet. Your web service can talk to db through Docker's internal network — it doesn't need the port exposed publicly.

# ✅ Better: only expose what users need
web:
  ports:
    - "3000:3000"    # Users need to access the web app

db:
  # No ports section — only accessible from other containers
  expose:
    - "5432"         # Available internally, not from outside

Mistake 2: Missing .dockerignore

AI generates a Dockerfile but almost never creates a .dockerignore file. Without it, Docker copies everything into the image — including node_modules/ (which can be 500MB+), .env files with your secrets, and Git history.

# .dockerignore — create this file yourself
node_modules
.env
.env.local
.git
.gitignore
*.md
dist
.next

This makes your builds faster and your images smaller. Always ask AI: "Generate a .dockerignore file for this project."

Mistake 3: Hardcoding Environment Variables in the Dockerfile

Sometimes AI puts sensitive values directly into the Dockerfile:

# ❌ Don't do this — secrets baked into the image
ENV DATABASE_PASSWORD=supersecretpassword123
ENV API_KEY=sk-1234567890abcdef

Anyone with access to the image can see these. Instead, pass them at runtime via your compose file or a .env file:

# ✅ Use a .env file
# docker-compose.yml
services:
  web:
    env_file:
      - .env          # Reads variables from .env file

# .env file (never commit this to Git!)
DATABASE_PASSWORD=supersecretpassword123
API_KEY=sk-1234567890abcdef

Read our full guide on environment variables for more on keeping secrets safe.

Quick Reference Table

What to Learn Next

Now that you know the Docker commands, here's where to go deeper:

Frequently Asked Questions