Table of Contents
Comprehensive, real-world Docker cheat sheet.
As a developer, you will use these commands daily during local development (to spin up databases, run microservices, and clean up your machine) and when setting up CI/CD pipelines (to automatically build and test code before deploying it to production cloud servers).
Creating & Building Images
Use these commands when you are writing code and need to package your app into a reusable Docker Image.
| Command | Description | Realistic Example |
docker build -t <name> . |
Builds a Docker Image from the Dockerfile in your current directory and tags it with a friendly name. |
docker build -t my-web-app . |
docker images |
Lists all the Docker Images currently saved and cached on your machine. | docker images |
docker rmi <image-id> |
Removes (deletes) a specific image from your computer to free up disk space. | docker rmi a1b2c3d4e5f6 |
Running & Managing Containers
Use these commands to turn your images into live, running containers (isolated processes) on your machine.
| Command | Description | Realistic Example |
docker run -d -p <host>:<container> --name <name> <image> |
Runs a container in the background (detached mode -d), maps a network port, and assigns it a custom name. |
docker run -d -p 3000:3000 --name running-app my-web-app |
docker run -e <KEY>=<VAL> |
Passes an environment variable directly into the container at startup (great for secrets or configurations). | docker run -d -e MONGO_URI="mongodb://localhost" my-web-app |
docker ps |
Lists all currently running containers on your machine. | docker ps |
docker ps -a |
Lists all containers (both actively running and stopped/crashed ones). | docker ps -a |
docker stop <name> |
Gracefully stops a running container without deleting it. | docker stop running-app |
docker start <name> |
Restarts a previously stopped container. | docker start running-app |
docker rm <name> |
Deletes a stopped container permanently from your machine. | docker rm running-app |
Multi-Container Orchestration (Docker Compose)
Use these commands when your application isn't working correctly and you need to look inside the container to debug it.
| Command | Description | Realistic Example |
docker logs <name> |
Fetches and prints the console outputs (console.log, prints, or errors) of a container. |
docker logs running-app |
docker logs -f <name> |
Streams the logs in real-time (follows -f) so you can watch errors pop up as you click around your app. |
docker logs -f running-app |
docker exec -it <name> sh |
Drops you into an interactive terminal (-it) inside the running container. (Use bash if sh isn't available). |
docker exec -it running-app sh |
Multi-Container Orchestration (Docker Compose)
Use these commands when your web application relies on other services (like a PostgreSQL database or a Redis cache) and you want to manage them all simultaneously.
| Command | Description | Realistic Example |
docker-compose up |
Reads your docker-compose.yml blueprint, downloads necessary images, and boots up all services at once. |
docker-compose up |
docker-compose up -d --build |
Re-builds your custom code changes and launches the entire multi-container stack safely in the background. | docker-compose up -d --build |
docker-compose down |
Stops and safely deletes all running containers, networks, and configurations created by that specific compose stack. | docker-compose down |
System Cleanup (The "Save My Disk Space" Commands)
Docker caches layers heavily. Over a few months of development, it will swallow up gigabytes of your hard drive. Use these to clean it up.
| Command | Description | Realistic Example |
docker system prune |
Deletes all stopped containers, unused networks, and dangling build caches in one sweep. | docker system prune |
docker system prune -a --volumes |
The Nuclear Option: Completely wipes out all cached images, stopped containers, and volume data. Resets your Docker app to zero. | docker system prune -a --volumes |
Where Exactly Do We Use This? (A Day in the Life)
The Instant Local Database Setup
Imagine you need a local MongoDB database for a new project. Instead of downloading a heavy installer, configuring background system services on your computer, and messing up your registry, you run one clean command:
Bash: docker run -d -p 27017:27017 --name dev-mongo mongo:latest
You instantly have an isolated database running on your computer. When you finish working on the project, you just type docker stop dev-mongo && docker rm dev-mongo, and your machine remains completely pristine.
Onboarding a New Team Member
When a new software engineer joins your project, instead of giving them a 5-page document detailing how to configure their laptop, install tools, and set environment paths, you give them a Git repository containing a Dockerfile and a docker-compose.yml file.
They open their terminal and type:
docker-compose upWithin minutes, their machine automatically builds the code, connects to the database, hooks up the backend API, and launches the application exactly how it runs in production.
No matter what language or framework you use—whether it is a Java (Spring Boot) backend, a C# (.NET) API, an Angular/React web app, or even a Flutter desktop/web build—the Docker CLI commands themselves are exactly the same.
You will still use docker build, docker run, docker ps, and docker-compose up for all of them. Docker does not care about your code syntax; it only cares about executing container actions.
However, the Dockerfile recipe inside the container changes dramatically because different languages require different compilers, runtimes, and build steps.
Here is how the underlying configurations differ between a heavy backend and a frontend framework using realistic production-ready examples.
Backend: C# (.NET) or Java (Spring Boot)
Backend frameworks require a two-step process called a Multi-Stage Build.
We use a heavy SDK image to compile/build the source code into a binary file.
We throw away the heavy SDK and copy only the compiled binary into a tiny runtime image. This keeps your production containers small and secure.
C# (.NET) Example Dockerfile
# --- STAGE 1: Build the binary ---
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build-env
WORKDIR /app
# Copy project files and restore dependencies
COPY *.csproj ./
RUN dotnet restore
# Copy remaining source code and publish compilation
COPY . ./
RUN dotnet publish -c Release -o out
# --- STAGE 2: Run the binary ---
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build-env /app/out .
EXPOSE 80
ENTRYPOINT ["dotnet", "YourApp.dll"]
The Cheat Sheet Command to Run It: docker run -d -p 8080:80 --name backend-api my-csharp-app
Frontend: Angular or React
Frontend apps are unique because browsers cannot run TypeScript or JSX directly.
We use a Node.js image to compile your Angular/React code into static HTML, CSS, and production JavaScript files.
We discard Node.js entirely and copy those static files into an ultra-fast web server like Nginx to serve them to users.
Angular/React Example
# --- STAGE 1: Compile the frontend assets ---
FROM node:20-alpine AS build-stage
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build -- --configuration=production # (or npm run build for React)
# --- STAGE 2: Serve using an ultra-fast web server ---
FROM nginx:alpine
# Copy the compiled static folder from Stage 1 directly into Nginx's public folder
COPY --from=build-stage /app/dist/your-app-name /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
The Cheat Sheet Command to Run It: docker run -d -p 3000:80 --name frontend-ui my-angular-app
Cross-Platform Mobile: Flutter
Flutter is an interesting exception.
For iOS and Android Mobile Apps: You do not put Flutter inside Docker for production. Mobile apps must be packaged into .apk or .ipa files and uploaded directly to the Google Play Store or Apple App Store. Docker cannot run inside a smartphone user's device.
For Flutter Web / Desktop Cloud Builds: You use Docker identically to the Angular/React method above. You pull a Flutter SDK image to compile your Dart code into standard static web assets, then pass those assets to an Nginx container to serve it as a website.
Putting It All Together: The Multi-Stack docker-compose.yml
This is where the magic happens. If you are building a full-stack system with a C# backend and an Angular frontend, you orchestrate them together using a single compose file. They share the exact same commands you already learned:
version: '3.8'
services:
# The Angular App
frontend:
build:
context: ./frontend-angular-folder
ports:
- "4200:80"
depends_on:
- backend
# The C# Web API
backend:
build:
context: ./backend-csharp-folder
ports:
- "5000:80"
To boot your entire ecosystem (Angular UI talking directly to a C# API), your command remains universally unchanged:
docker-compose up -d --build
Recent Comments