{"id":27243,"date":"2026-01-15T14:26:34","date_gmt":"2026-01-15T13:26:34","guid":{"rendered":"https:\/\/contabo.com\/blog\/?p=27243"},"modified":"2026-01-19T11:19:32","modified_gmt":"2026-01-19T10:19:32","slug":"docker-commands-guide-for-developers","status":"publish","type":"post","link":"https:\/\/contabo.com\/blog\/docker-commands-guide-for-developers\/","title":{"rendered":"Master Docker Commands for Container Management"},"content":{"rendered":"\n
\"Master<\/figure>\n\n\n\n

Docker commands. You’ll need them. Every single day. The problem isn’t learning Docker. The problem is remembering which command does what when you’re three deploys deep and your production environment is burning. This guide breaks down the commands you’ll actually use, organized by what they do instead of alphabetically because that’s how your brain works under pressure.<\/p>\n\n\n\n

Commands fall into multiple categories: build & manage images, clean up the mess, start and stop containers, check what’s running. Also configure containers, push to registries, orchestrate services, set up networks. Let’s get into it.<\/p>\n\n\n\n

Docker Build Commands<\/h2>\n\n\n\n

The docker build command turns your Dockerfile into an image. That’s it. Everything else is just options.<\/p>\n\n\n\n

Build from your current directory with docker build<\/code>. Want to tag it so you can find it later? Add -t imagename\/tag<\/code>. The tag isn’t optional if you plan to push to a registry.<\/p>\n\n\n\n

You can build from remote sources too. Point at a Git repo with docker build https:\/\/github.com\/user\/repo.git#branch:folder<\/code>. Or grab a tar archive from your server with docker build https:\/\/yourserver\/file.tar.gz<\/code>.<\/p>\n\n\n\n

Need to skip the cache? Use --no-cache<\/code>. Pass build arguments with --build-arg KEY=value<\/code>. These show up in your Dockerfile as ARG variables.<\/p>\n\n\n\n

The build process reads your Dockerfile line by line. Each instruction creates a layer. Layers get cached. That’s why your first build takes forever and subsequent builds finish in seconds. Unless you change something near the top of the Dockerfile. Then everything below that line rebuilds.<\/p>\n\n\n\n

Docker Prune and Cleanup Commands<\/h2>\n\n\n\n

Docker fills your disk. Fast. Dangling images, stopped containers, unused volumes. They pile up.<\/p>\n\n\n\n

Run docker system prune<\/code> to clear stopped containers, unused networks, dangling images, and build cache. Add -a<\/code> to remove all unused images, not just dangling ones. This frees up gigabytes.<\/p>\n\n\n\n

For targeted cleanup, use docker image prune<\/code> to delete untagged images. Clear volumes with docker volume rm $(docker volume ls -f dangling=true -q)<\/code>. Remove specific images with docker image rm imagename<\/code>.<\/p>\n\n\n\n

Want to nuke everything? Stop all running containers with docker kill $(docker ps -q)<\/code>, then remove them with docker rm $(docker ps -a -q)<\/code>. Don’t do this in production.<\/p>\n\n\n\n

Schedule prune commands in your deployment pipeline. Your DevOps team will thank you when they’re not hunting down disk space at 2 AM.<\/p>\n\n\n\n

Managing Containers: Start, Stop, and Restart<\/h2>\n\n\n\n

Container lifecycle management. Start, stop, pause, restart. These commands control what’s running.<\/p>\n\n\n\n

Use docker start containername<\/code> to fire up a stopped container. Stop it with docker stop containername<\/code>. Restart with docker restart containername<\/code>. Simple.<\/p>\n\n\n\n

Need to freeze a container temporarily? docker pause containername<\/code> suspends all processes. Resume with docker unpause containername<\/code>. The container’s state persists in memory.<\/p>\n\n\n\n

Stopping all containers at once requires a command chain. docker stop $(docker ps -q)<\/code> stops everything currently running. The -q<\/code> flag outputs only container IDs.<\/p>\n\n\n\n

Set restart policies when you launch containers. Use --restart=always<\/code> for services that should survive system reboots. Or --restart=on-failure<\/code> to restart only after crashes.<\/p>\n\n\n\n

Docker Logs and Container Inspection<\/h2>\n\n\n\n

Something broke. You need logs.<\/p>\n\n\n\n

Run docker logs containername<\/code> to dump everything the container wrote to stdout and stderr. Add -f<\/code> to follow logs in real-time. Use --tail 100<\/code> to see just the last 100 lines.<\/p>\n\n\n\n

List running containers with docker ps<\/code>. See everything, including stopped containers, with docker ps -a<\/code>. The output shows container IDs, images, commands, status, and ports.<\/p>\n\n\n\n

Dig deeper with docker inspect containername<\/code>. This dumps a JSON blob containing every detail: network settings, mounts, environment variables, resource limits. Pipe it to grep <\/code>or jq <\/code>to find what you need.<\/p>\n\n\n\n

Check resource usage with docker stats<\/code>. It shows CPU percentage, memory usage, network I\/O, and block I\/O for each running container. Watch it stream live or capture a snapshot.<\/p>\n\n\n\n

See what changed in a container’s filesystem? docker diff containername<\/code> lists added, deleted, and modified files. Useful for debugging containers that modify their own filesystems.<\/p>\n\n\n\n

Docker Images Management<\/h2>\n\n\n\n

Images are templates. Containers are running instances. Managing images means keeping your local repository clean and tagged correctly.<\/p>\n\n\n\n

List all images with docker images<\/code> or docker image ls<\/code>. You’ll see repository names, tags, image IDs, creation dates, and sizes. Filter by name with docker images imagename<\/code>.<\/p>\n\n\n\n

Tag images with docker tag source target<\/code>. This creates a new reference to the same image. Common pattern: docker tag myapp:latest myapp:v1.2.3<\/code>. Now you’ve got a version-specific tag and a latest tag pointing to the same image.<\/p>\n\n\n\n

Remove images with docker image rm imagename<\/code> or docker rmi imagename<\/code>. Delete multiple images by listing them: docker rmi image1 image2 image3<\/code>.<\/p>\n\n\n\n

Check image history with docker history imagename<\/code>. Each line shows a layer: the command that created it, when it was created, and how much disk space it uses. Bloated images? This shows you where.<\/p>\n\n\n\n

Prune unused images with docker image prune<\/code>. Add -a<\/code> to remove all images not referenced by any container. This isn’t reversible, so don’t get trigger-happy on your build server.<\/p>\n\n\n\n

Docker Run Command Options<\/h2>\n\n\n\n

The docker run command creates and starts a container from an image. One command, dozens of flags.<\/p>\n\n\n\n

Basic syntax: docker run imagename<\/code>. This runs the container in the foreground and blocks your terminal. Add -d<\/code> to detach and run it in the background.<\/p>\n\n\n\n

Name your container with --name containername<\/code>. Otherwise Docker generates random names like ‘quirky_tesla’ that you’ll never remember. Map ports with -p hostport:containerport<\/code>. Example: -p 8080:80<\/code> maps container port 80 to host port 8080.<\/p>\n\n\n\n

Set environment variables with -e KEY=value<\/code>. Mount volumes using -v \/host\/path:\/container\/path<\/code>. Make the container filesystem read-only with --read-only<\/code> for security.<\/p>\n\n\n\n

Auto-remove containers when they stop with --rm<\/code>. Perfect for one-off tasks. Connect to specific networks using --network networkname<\/code>. Set resource limits with --memory<\/code> and --cpus<\/code>.<\/p>\n\n\n\n

Interactive mode requires two flags: -i<\/code> keeps stdin open and -t<\/code> allocates a pseudo-TTY. Combine them as -it<\/code> for shell access: docker run -it ubuntu bash<\/code>.<\/p>\n\n\n\n

Docker Hub and Registry Commands<\/h2>\n\n\n\n

Docker Hub hosts millions of images. Your private registry might host yours. Either way, you need to pull, push, and authenticate.<\/p>\n\n\n\n

Log in with docker login<\/code>. It prompts for username and password. For automated systems, pass credentials via stdin or use access tokens. Log out with docker logout<\/code>.<\/p>\n\n\n\n

Pull images from Docker Hub with docker pull imagename<\/code>. Specify tags like docker pull nginx:1.21<\/code>. Without a tag, it defaults to latest. That’s often not what you want in production.<\/p>\n\n\n\n

Push images with docker push username\/imagename:tag<\/code>. The image name must include your Docker Hub username or your registry URL. Tag it correctly before pushing or it’ll fail.<\/p>\n\n\n\n

Search Docker Hub from the command line using docker search searchterm<\/code>. It returns official images, automated builds, and star counts. The web interface gives you more details though.<\/p>\n\n\n\n

For private registries, prefix image names with the registry URL: registry.example.com\/imagename<\/code>. Login, pull, and push work the same way. Just point at a different registry.<\/p>\n\n\n\n

Docker Swarm Service Management<\/h2>\n\n\n\n

Docker Swarm orchestrates containers across multiple hosts. Services define how your containers should run in the swarm.<\/p>\n\n\n\n

List services with docker service ls<\/code>. This shows service names, modes, replicas, images, and ports. For detailed info about a specific service, run docker service ps servicename<\/code>.<\/p>\n\n\n\n

Create a service with docker service create<\/code>. Example: docker service create --name web --replicas 3 -p 80:80 nginx<\/code>. This deploys three nginx replicas across your swarm.<\/p>\n\n\n\n

Scale services up or down with docker service scale servicename=5<\/code>. Swarm handles distributing the replicas. Update running services using docker service update<\/code> with flags like --image<\/code> for rolling updates.<\/p>\n\n\n\n

Check service logs with docker service logs servicename<\/code>. This aggregates logs from all replicas. Deploy entire stacks using docker stack deploy<\/code> with a compose file.<\/p>\n\n\n\n

Kubernetes won the orchestration war. But Swarm’s still simpler for smaller deployments. No learning curve. Just works.<\/p>\n\n\n\n

Docker Network Configuration<\/h2>\n\n\n\n

Containers need to talk to each other and the outside world. Networks make that happen.<\/p>\n\n\n\n

List networks with docker network ls<\/code>. You’ll see bridge, host, and none by default. Create custom networks using docker network create networkname<\/code>. Specify drivers with --driver bridge<\/code> or --driver overlay<\/code> for swarm.<\/p>\n\n\n\n

Connect running containers to networks with docker network connect networkname containername<\/code>. Disconnect with docker network disconnect<\/code>. Containers can belong to multiple networks.<\/p>\n\n\n\n

The bridge network is default. Containers on the same bridge network can reach each other by name. Host network mode gives containers direct access to the host’s network stack. Use --network<\/code> host <\/code>when launching containers that need maximum network performance.<\/p>\n\n\n\n

Inspect network details with docker network inspect networkname<\/code>. This shows connected containers, IP addresses, subnet configuration, and gateway settings. Remove unused networks with docker network rm networkname<\/code>.<\/p>\n\n\n\n

Custom networks give you DNS resolution between containers. That’s why you create them instead of using the default bridge. Name resolution beats hardcoding IP addresses.<\/p>\n\n\n\n

Docker Tutorial and Best Practices<\/h2>\n\n\n\n

Commands are one thing. Using them correctly is another.<\/p>\n\n\n\n

    \n
  • Start with the basics. Install Docker. Run docker run hello-world<\/code>. If that works, you’re set. Build a simple Docker file. Create an image. Run a container. Break things. Fix them.<\/li>\n\n\n\n
  • Keep images small. Each layer adds size. Combine RUN commands. Clean up package caches in the same layer where you install them. Use multi-stage builds to separate build dependencies from runtime dependencies.<\/li>\n\n\n\n
  • Don’t run containers as root. Create a user in your Dockerfile with RUN useradd<\/code>. Switch to it with USER username<\/code>. Security matters even in containers.<\/li>\n\n\n\n
  • Tag your images properly. Use semantic versioning. Never rely on latest in production. Pin exact versions in your deployment configs. When an image updates and breaks your app, you’ll understand why.<\/li>\n\n\n\n
  • Monitor resource usage. Set memory limits with --memory<\/code>. Cap CPU with --cpus<\/code>. A container consuming all available resources takes down the entire host.<\/li>\n\n\n\n
  • Use health checks. Add HEALTHCHECK <\/code>instructions to your Dockerfile. Docker can then automatically restart unhealthy containers. Better than waiting for your monitoring system to page you.<\/li>\n\n\n\n
  • Store secrets properly. Don’t bake them into images. Don’t pass them as environment variables that show up in docker inspect<\/code>. Use Docker secrets for swarm or external secret management tools.<\/li>\n<\/ul>\n\n\n\n

    The commands in this guide cover 90% of daily Docker work. The other 10%? That’s where you read the docs, search GitHub issues, and piece together solutions from Stack Overflow. Welcome to containerization!<\/p>\n","protected":false},"excerpt":{"rendered":"

    Docker commands. You’ll need them. Every single day. The problem isn’t learning Docker. The problem is remembering which command does what when you’re three deploys deep and your production environment is burning. This guide breaks down the commands you’ll actually use, organized by what they do instead of alphabetically because that’s how your brain works […]<\/p>\n","protected":false},"author":44,"featured_media":27492,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[18],"tags":[],"ppma_author":[3402],"class_list":["post-27243","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorials"],"uagb_featured_image_src":{"full":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/01\/blog-head_guide-docker-commands-for-container-management_EN.webp",1200,630,false],"thumbnail":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/01\/blog-head_guide-docker-commands-for-container-management_EN-150x150.webp",150,150,true],"medium":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/01\/blog-head_guide-docker-commands-for-container-management_EN-600x315.webp",600,315,true],"medium_large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/01\/blog-head_guide-docker-commands-for-container-management_EN-768x403.webp",768,403,true],"large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/01\/blog-head_guide-docker-commands-for-container-management_EN.webp",1200,630,false],"1536x1536":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/01\/blog-head_guide-docker-commands-for-container-management_EN.webp",1200,630,false],"2048x2048":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/01\/blog-head_guide-docker-commands-for-container-management_EN.webp",1200,630,false]},"uagb_author_info":{"display_name":"Milan Ivanovic","author_link":"https:\/\/contabo.com\/blog\/author\/milan\/"},"uagb_comment_info":0,"uagb_excerpt":"Docker commands. You’ll need them. Every single day. The problem isn’t learning Docker. The problem is remembering which command does what when you’re three deploys deep and your production environment is burning. This guide breaks down the commands you’ll actually use, organized by what they do instead of alphabetically because that’s how your brain works…","authors":[{"term_id":3402,"user_id":0,"is_guest":1,"slug":"contabro","display_name":"ContaBro","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/27243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/users\/44"}],"replies":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/comments?post=27243"}],"version-history":[{"count":6,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/27243\/revisions"}],"predecessor-version":[{"id":27546,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/posts\/27243\/revisions\/27546"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/media\/27492"}],"wp:attachment":[{"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/media?parent=27243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/categories?post=27243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/tags?post=27243"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/contabo.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=27243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}