DEV Community: Docker

Docker Just Made Hardened Images Free for Everyone – Let's Check Them Out!

Anil Kumar Moka — Mon, 29 Dec 2025 02:03:18 +0000

Hey everyone! If you're like me and spend a lot of time building and deploying containers, you've probably worried about security at some point. Supply chain attacks are no joke these days, and starting with a solid, secure base can make a huge difference. That's why I'm super excited about the recent news from Docker: they've made Docker Hardened Images (DHI) completely free and open source for all developers!Back in May 2025, Docker launched these hardened images as a way to give us minimal, secure, production-ready bases. And just a couple weeks ago (December 17, 2025), they announced that the whole catalog – over 1,000 images and Helm charts – is now free, under Apache 2.0. No subscriptions needed for the basics, no restrictions, no gotchas. This feels like a game-changer for making secure containers the default instead of an afterthought.Let me break it down for you based on the official blog post and docs, and share some practical ways you can start using them today.

What Are Docker Hardened Images?

In simple terms, DHI are container images that Docker maintains with security front and center. They're built on familiar bases like Alpine and Debian, but stripped down to the essentials. No unnecessary shells, compilers, or package managers that could open up attack vectors.The result?
Images up to 95% smaller

Way fewer CVEs (they aim for near-zero)
Secure defaults, like running as non-root
Full transparency with SBOMs (software bill of materials),
SLSA Level 3 provenance, and no hidden vulnerabilities

They're inspired by distroless ideas but keep enough tools so you don't have to fight with them in real workflows. And unlike some proprietary options, these are open, compatible with what you're already using, and easy to adopt.

There's a free tier for everyone, and an Enterprise version if you need extras like FIPS compliance, customizations, or super-fast patching SLAs.

Why This Matters (And Why Now)

Supply chain attacks are exploding – projected to cost $60 billion this year alone. A lot of that risk comes from bloated base images pulling in stuff your app doesn't need. By starting with a hardened image, you're shrinking that attack surface right from the first docker build.Docker's basically saying: let's make secure-by-default the new normal. And with partnerships from folks like Google, MongoDB, and CNCF, plus companies like Adobe and Qualcomm already using them, it seems like it's catching on fast.

How to Get Started – It's Super Easy

Head over to the catalog on Docker Hub: https://hub.docker.com/hardened-images/catalog (you might need to sign in with your Docker ID).Or pull directly from dhi.io.

For example, let's try a Python one:bash

docker pull dhi.io/python:3.13
Then run something simple:bash

docker run --rm dhi.io/python:3.13 python -c "print('Hello from a hardened image!')"

In your Dockerfile, just swap the base:

FROM dhi.io/python:3.13 COPY . /app WORKDIR /app CMD ["python", "app.py"]

They work great in CI/CD too. And if you're on Kubernetes, check out the open source Hardened Helm Charts.
Pro tip from the docs: These images are minimal on purpose, so no shell by default in runtime variants. Use multi-stage builds – compile in a -dev or -sdk tag, then copy to the slim runtime one.

Some Practical Use Cases I Can See

Imagine you're building a Node.js API for a startup. Instead of starting with the regular node image (which has extra stuff), switch to a hardened one. Smaller images mean faster deploys, fewer vulnerabilities to scan, and you sleep better knowing it's locked down.

Or say you're deploying MongoDB in prod. Docker has hardened versions of popular MCP servers like Mongo, Grafana, and more. Drop one in, and you've got a secure foundation without rolling your own hardening scripts.

For teams in regulated spaces (finance, healthcare), the free versions already give huge wins on CVEs and size. Upgrade to Enterprise if you need FIPS or extended support after upstream EOL.Even for personal projects or learning, why not start secure? It costs nothing extra now.

This move by Docker feels huge, putting hardened, transparent images in everyone's hands for free. If you've been putting off tightening up your container security, now's the perfect time to jump in. Go browse the catalog, pull a couple images, and see the difference yourself. Planning to switch any of your projects over? Drop a comment if you've tried them already!

Docker Hardened Images are Free

Mohammad-Ali A'RÂBI — Wed, 17 Dec 2025 14:17:35 +0000

Docker introduced Hardened Images in 2025 as a secure-by-default base image line, designed to keep production and development images as close to zero known CVEs as realistically possible.

As supply chain attacks are on the rise, Docker made the Hardened Images open-source under the Apache 2.0 license to let the community audit and contribute to them.

From now on, you can use the hardened images for free in your projects:

# For build stage
FROM dhi.io/node:24-dev AS build

# For production stage
FROM dhi.io/node:24

To get started, visit dhi.io.

How to Pull Hardened Images Locally

To pull the images locally, you need to log into dhi.io first:

docker login dhi.io

The images are free to use, but you still need to authenticate before pulling them.

Use your Docker Hub credentials to login. You can use your personal Docker Hub account and a personal access token (PAT) as the password. No special subscription is required.

Then pull the desired image:

docker pull dhi.io/node:24

Check for CVEs

To check for CVEs in the images, you can use Docker Scout:

docker scout cves dhi.io/node:24

The image has 8 low-severity CVEs as of December 17th, 2025, as there are no fixed versions available for those packages:

8 vulnerabilities found in 2 packages
  CRITICAL  0  
  HIGH      0  
  MEDIUM    0  
  LOW       8

To check with Trivy:

trivy image --scanners vuln dhi.io/node:24

Trivy also found 7 low-severity CVEs on one package:

dhi.io/node:24 (debian 13.2)

Total: 7 (UNKNOWN: 0, LOW: 7, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

You can still use the Alpine-based hardened images to have a smaller attack surface.

Final Words

There are more than 500 different tags just for the Node.js Hardened Images available on dhi.io, including Alpine-based, Debian-based, dev and runtime, and FIPS and STIG-compliant images. And there are some 100 different repositories for other languages and runtimes, such as Python, Go, Java, .NET, Ruby, and more. And there are Helm charts to deploy DHI images on Kubernetes clusters directly.

To explore all available images, visit the DHI Catalog.

To learn more about Docker and Kubernetes security, check out my book Docker and Kubernetes Security, currently 40% off with code BLACKFOREST25.

I Just Published My Book: Docker and Kubernetes Security

Mohammad-Ali A'RÂBI — Tue, 21 Oct 2025 12:26:34 +0000

The book Docker and Kubernetes Security is finally here, after two years, 170 git commits, and countless hours of writing, editing, and reviewing. It's available on DockerSecurity.io. You can get the eBook, paperback, or a signed copy (that I'll sign and send to you). 🐳🔐

So, why did I write this book?

An Unexpected Journey

I became a Docker Captain in March 2023. That probably put me on this publisher's radar. Shortly after that, a major UK publisher reached out to me, asking if I would be interested in writing a book on Docker Security. At first, I was hesitant. Writing a book is a huge commitment, and I wasn't sure if I had enough expertise in Docker Security. The publisher was very persuasive, though, and I eventually agreed to write a proposal.

Here is my monthly tweet about writing a proposal in July 2023:

July 2023 goals:

👾 Practice C with Exercism

🐳 Submit a Docker talk

📝 Write a piece on Telepresence

🚘 Pass the driving theory exam

📚 Finish the book proposal

Well, I never made it to that DockerCon, because my visa is still pending. But I did finish the proposal!

I finished the book, it went through multiple rounds of editing and reviewing, and the technical reviewers gave me a green light by the end of 2024. I was waiting for the final copy-editing and typesetting to be done when I got an email from the publisher in February 2025, named "Intro Call". There was some reorganization happening at the publisher, and they assigned a new team to my book. The intro call was super nice and happy. Then I got an email in March 2025, saying that they are canceling the book project "after a thorough review". I said, "Sure, just verify that the rights are reverted to me". They wrote:

Yes, the manuscripts belong to you, and you can find an alternative publisher.

I thought, "I have found a new publisher, and that's me!"

Self-Publishing

I set a deadline for myself: October 1st, 2025. I personally love October. It's the month of Oktoberfest, Hacktoberfest, and Halloween. And people are back from Summer mood.

When I posted on LinkedIn that's publishing in October, I received overwhelming support and encouragement from my network. The post received 5,000 views, 75 reactions, and 20 comments of encouragement.

So, I started reaching out to my network for help with self-publishing. Docker Captain Vladimir Mikhalev accepted to be my technical editor. Other Docker Captains accepted to read beta copies and give feedback. I typeset the book using Markdown and LaTeX, and my friend Sima Maherani designed a beautiful cover for it.

I started using Amazon's Kindle Direct Publishing (KDP) to publish the eBook and paperback versions. I also set up a website, DockerSecurity.io, to sell signed copies and provide additional resources.

I took two copies of the book to my talk at WeAreDevelopers in Berlin, where I ran a workshop on Docker Security. There, I ran into Docker Captain Francesco Ciulla, who said he would promote the book when it comes out. I also met Liran Tal, Director of Developer Advocacy at Snyk, who later wrote a foreword for the book.

The Launch

Finally, the big day arrived: October 1st, 2025. The book was launched on Amazon and DockerSecurity.io. Amazon's KDP network mostly supported English-speaking countries, plus some European countries. Many other countries were not supported, for example, India, although Amazon has a big presence there. So, I set up a signed copy option on buy.DockerSecurity.io to ship books worldwide.

Again, after the launch, I received overwhelming support from my network. People started purchasing the book and leaving reviews on Amazon and Goodreads. Docker reshared my launch post on their official LinkedIn page, as well as on Twitter.

An Indian Docker Captain reached out and said he wants to give away copies of the book to the winners of a Hackathon he was organizing. It was a challenge to get him the book in time, but we managed to do it. More Captains reached out to congratulate me and offer help with promotion.

So far, 3 weeks after the launch, we have had a slow start, but the momentum is building up. The book had sales in Japan, although I did not promote it there. Sales are mostly in Germany, where I'm based. I have received requests from readers in Iran and India who wanted to buy the book but could not find a way to do it. The signed copy is an option, but still expensive, as it's printed in Europe and shipped internationally.

I'm currently working with an Indian printer to make the book available in Asia, Africa, and the Middle East. I'm also registering my own ISBN to make the book available in bookstores. They would usually refuse to stock books with Amazon's ISBN.

If you are interested in ordering the book, you can find it here: buy.DockerSecurity.io. You can use the following code for a 10 Euros discount: DEVTO 🏷️

If you want to order on Amazon, you can find the links here: DockerSecurity.io. The website will redirect you to the appropriate Amazon store based on your location.

Conclusion

Writing and self-publishing a technical book is a challenging but rewarding experience. It requires a lot of dedication, perseverance, and support from your network. I'm grateful for everyone who helped me along the way, and I'm excited to see where this journey takes me next.

If you want to write a book, you can reach out to me, and I can share the code base I built with Pandoc and LaTeX to help you get started.

Meet the heroes who made Docker and Kubernetes Security possible:

MCP Horror Stories - Issue 1

Ajeet Singh Raina — Fri, 01 Aug 2025 15:23:10 +0000

The Model Context Protocol (MCP) is a standardized interface that enables AI agents to interact with external tools, databases, and services. Launched by Anthropic in November 2024, MCP has achieved remarkable adoption, with thousands of MCP server repositories emerging on GitHub. Major technology giants, including Microsoft, OpenAI, Google, and Amazon, have officially integrated MCP support into their platforms, with development tools companies like Block, Replit, Sourcegraph, and Zed also adopting the protocol.

Think of MCP as the plumbing that allows ChatGPT, Claude, or any AI agent to read your emails, update databases, manage files, or interact with APIs. Instead of building custom integrations for every tool, developers can use one protocol to connect everything.

The Model Context Protocol (MCP) was supposed to be the “USB-C for AI applications” – a universal standard that would let AI agents safely connect to any tool or service. Instead, it’s become a security nightmare that’s putting organizations at risk of data breaches, system compromises, and supply chain attacks.

The promise is compelling: Write once, connect everywhere. The reality is terrifying: A protocol designed for convenience, not security.

This is issue 1 of a new series – MCP Horror Stories – where we will examine critical security issues and vulnerabilities in the Model Context Protocol (MCP) ecosystem and how Docker MCP Toolkit provides enterprise-grade protection against these threats.

Click here to Read the complete blog

Docker Deep Dive Workshop at WeAreDevelopers

Mohammad-Ali A'RÂBI — Wed, 09 Jul 2025 22:30:48 +0000

Today, I conducted a workshop at WeAreDevelopers World Congress 2025 titled:

Docker Deep Dive with a Docker Captain

The workshop covered the following topics:

Docker Init
Docker Bake
Docker SBOM
SBOM attestations
Docker Scout
Docker Debug
Docker Model Runner
Ask Gordon

This article is a step-by-step guide that walks you through the topics, allowing you to recreate the workshop for yourself on demand.

Technical Requirements

Docker Desktop latest version
Git
A Bash shell (e.g., Git Bash, WSL, or any Linux terminal)

On Windows, you can install Git Bash.

1. Docker Init

Main article: Dockerizing a Java 24 Project with Docker Init

Main article: JAVAPRO: How to Containerize a Java Application Securely

Docker Init is a command to initialize a Docker project with a Dockerfile and other necessary files:

Dockerfile
compose.yaml
.dockerignore
README.Docker.md

The command doesn't use GenAI, so is deterministic, and employs best practices for Dockerfile creation.

Docker Init is available on Docker Desktop 4.27 or later and is generally available.

Usage

On the repo, go to the Flask example directory:

cd flask

Then, run the Docker Init command:

docker init

The command will ask you 4 questions, accept the defaults:

? What application platform does your project use? Python
? What version of Python do you want to use? 3.13.2
? What port do you want your app to listen on? 8000
? What is the command you use to run your app? gunicorn 'hello:app' --bind=0.0.0.0:8000

Then, start Docker Compose with build:

docker compose up --build

The application will be available at http://localhost:8000.

Exercises

1.1. If you want a more tricky example, try Dockerizing a Java 24 application using Docker Init. You can follow the instructions in the JAVAPRO article that I published last week.
1.2. Compare the Dockerfile created for the Java application with the one created for the Python application. What are the differences?

2. Docker Bake

Requirement: This step requires the Docker Init step to be completed first.

Docker Bake is to Docker Build, what Docker Compose is to Docker Run. It allows you to build multiple images at once, using a single command.

Docker Bake is available on Docker CE and Docker Desktop, and is generally available.

Usage

In the repo, go to the Flask example directory:

cd flask

Then, try to build the image using Docker Bake:

docker buildx bake

The command will build the image using the docker-bake.hcl file in the current directory. At the end, there is a Docker Desktop link shown in the output, with which you can see the build progress in the Docker Desktop UI.

Also, there are probably some warnings about the Dockerfile.

Exercises

2.1. Try to fix the warnings in the Dockerfile.
2.2. By changing the docker-bake.hcl file, try building for multiple platforms, e.g., linux/amd64 and linux/arm64.
2.3. Try to build the image with a different Python version, e.g., 3.13.1 (the Python version is defined in the Dockerfile as a build argument, PYTHON_VERSION).

3. Docker SBOM

Requirement: This step requires the Docker Init step to be completed first.

In Docker Init step, we built an image with tag flask-server:latest when running docker compose up --build. Let's check the SBOM for this image.

Docker SBOM is integrated into Docker Desktop, but is also available for Docker CE as a CLI plugin that you need to install separately.

Usage

To check the SBOM for the image, run:

docker sbom flask-server:latest

The output will show the SBOM in a table format. Try to export it to a SPDX file:

docker sbom --format spdx-json flask-server:latest > sbom.spdx.json

If you investigate the file, you will see that it contains a list of all the packages used in the image, their versions, and the licenses. It's especially useful for compliance and security purposes.

A more interesting example will be a C++ application.

Go to the C++ example directory:

cd cpp

Then, build the image:

docker build -t cpp-hello .

Now, check the SBOM for the image:

docker sbom cpp-hello

It will say there are no packages in the image, because the image is built from a FROM scratch base image. But, in the build stage, we installed many packages, and a vulnerability in those packages can affect the final image.

We'll get back to this later.

Exercises

3.1. Try to create a Docker Bake file for the C++ example, and build the image using Docker Bake.
3.2. Use docker sbom --help to check available formats for the SBOM output.

4. SBOM Attestations

Requirement: This step requires the Docker SBOM step to be completed first.

Main article: DockerDocs: Supply-Chain Security for C++ Images

SBOM attestations are SBOMs generated for Docker images and uploaded with them to the registry.

Usage

SBOM attestations are generated during the build and pushed to the registry automatically:

docker buildx build --sbom=true --push -t aerabi/cpp-hello .

Now, let's check the CVEs with Docker Scout (we will cover it in the next section):

docker scout cves aerabi/cpp-hello

It will say:

SBOM obtained from attestation, 0 packages found

The SBOM has no packages, because we built the image from a FROM scratch base image, and the build stage packages are not included in the SBOM. We can fix this by including the build stage packages in the SBOM.

To do that, we need to add the following line to the beginning of the Dockerfile:

ARG BUILDKIT_SBOM_SCAN_STAGE=true

This line goes before the FROM line, and it tells Docker to include the build stage packages in the SBOM.

Now, rebuild the image with the new Dockerfile:

docker buildx build --sbom=true --push -t aerabi/cpp-hello:with-build-stage .

Now, check the SBOM attestations for the image again:

docker scout cves aerabi/cpp-hello:with-build-stage

It will say:

SBOM of image already cached, 208 packages indexed

Exercises

4.1. Here, the build command was super long. Try to create a Docker Bake file for the C++ example, and build the image using Docker Bake with SBOM attestations.

5. Docker Scout

Requirement: This step requires the SBOM Attestations step to be completed first.

Docker Scout is a tool to analyze Docker images and check for vulnerabilities, misconfigurations, and other issues. It uses the SBOM attestations, when available, to provide more accurate results.

Docker Scout is available on Docker Desktop, and as a CLI plugin for Docker CE.

Usage

To check the vulnerabilities in the image, run:

docker scout cves aerabi/cpp-hello:with-build-stage

You can also check the vulnerabilities in the image using the Docker Desktop UI. Just go to the "Images" tab, select the image, and click on "Scout".

There are also recommendations for the image, which you can check by running:

docker scout recommendations flask-server

Exercises

5.1. Try to fix the vulnerabilities in the Flask image using the recommendations from Docker Scout.

6. Docker Debug

Requirement: This step requires the Docker SBOM step to be completed first.

Docker Debug is a tool to debug Docker images and containers. It allows you to run a container with a debug shell, and inspect the image and the container.

Docker Debug is a paid feature available on Docker Desktop.

Usage

Docker Debug can be used to investigate images or containers, when docker exec is not enough. For example, you can use it to inspect a scratch image:

docker debug aerabi/cpp-hello:with-build-stage

Exercises

6.1. Use Docker Debug to inspect the C++ image.
6.2. Use Docker Debug to inspect the Flask image.
6.3. Run the Flask image and inspect it with Docker Debug.
6.4. Install a tool like Vim using Docker Debug. The tools persist between different inspections. Try to inspect another container and check if the tool is still there.

7. Docker Model Runner

Main article: Run GenAI Models Locally with Docker Model Runner

Docker Model Runner is a tool to run GenAI models locally using Docker. The feature is still in beta, but is available on Linux, macOS, and Windows.

Linux: Docker CE
macOS: Docker Desktop 4.40 or later
Windows: Docker Desktop 4.41 or later

On Docker CE, you need to install the Docker Model Runner plugin:

sudo apt-get install docker-model-plugin

Usage

docker model run ai/gemma3

To use Docker Model Runner for developing GenAI applications, you can pull the models, and they will become available locally. Whenever an application needs to use a model, it can use the local models.

And example application is available here:

git clone https://github.com/aerabi/genai-app-demo
cd genai-app-demo

Edit the file backend.env and make it match the following content:

BASE_URL: http://model-runner.docker.internal/engines/llama.cpp/v1/
MODEL: ai/gemma3
API_KEY: ${API_KEY:-dockermodelrunner}

Then, run the application:

docker compose up -d

Exercises

7.1. Docker Compose now supports the model service type (learn more). Try to adapt the Compose file in the repo to declare the model as a service.

From Zero to Kubernetes: A Beginner's Guide to Orchestrating Docker Containers

Karan Verma — Sat, 31 May 2025 12:30:28 +0000

Introduction

If you've ever built or deployed applications using Docker, you've likely hit a point where running containers on your laptop just isn’t enough. You need scaling, automation, recovery, and networking across machines. Enter Kubernetes, the container orchestrator trusted by startups and tech giants alike. In this beginner-friendly guide, we’ll walk you through what Kubernetes is, why it matters, and how Docker developers can start leveraging its power.

What is Kubernetes?

Kubernetes (also called K8s) is an open-source platform that automates deploying, scaling, and managing containerized applications. While Docker helps package your app into a container, Kubernetes helps run and scale it across many machines.

Kubernetes architecture explained: The Control Plane manages the cluster while Nodes run Pods, which host your Docker containers.

Why Use Kubernetes?

- Self-Healing: Restarts failed containers automatically.
- Scalability: Scale apps up or down automatically with a single command.
- Declarative Management: Define your infrastructure and app needs using YAML files.
- Portability: Run anywhere from your laptop with Minikube to cloud providers like AWS, GCP, or Azure.

How Kubernetes Works (for Docker Devs)

Kubernetes works on a cluster model. A cluster has:

- Master Node (Control Plane): Handles scheduling, scaling, and communication.
- Worker Nodes: Run your Docker containers inside Pods.

Pods and Deployments

A Pod is the smallest deployable unit in Kubernetes. It wraps your container(s) and runs on a node. You usually don’t run Pods directly, you use Deployments to manage them.

Exposing Your App with Services

Pods can come and go. You need a stable way to expose them; that’s where Services come in. A Service routes traffic to the right Pods and load-balances across them.

Kubernetes Service: Traffic from users is routed through a Service to reach the right Pods, ensuring balanced and reliable access to your app.

Step-by-Step: Try It Yourself with Minikube

Let’s get hands-on!

1. Install Minikube & kubectl

brew install minikube
minikube start
kubectl get nodes

2. Create a Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

3. Deploy it to Kubernetes

kubectl apply -f deployment.yaml
kubectl get pods

4. Expose Your Deployment as a Service

kubectl expose deployment my-web-app --type=NodePort --port=80

5. Access Your App

minikube service my-web-app

Bonus: Access a Pod Directly (Port Forwarding)

kubectl port-forward pod/my-web-app-xxxx 8080:80

📚 Further Reading

Here are some trusted, beginner-friendly resources to deepen your Kubernetes knowledge, especially curated for developers coming from Docker:

Kubernetes Official Documentation: The canonical source for Kubernetes knowledge, straight from the maintainers.
Docker + Kubernetes (Docker Docs): Docker’s own guide on moving from Docker CLI to Kubernetes orchestration.
Minikube Official Docs: Run Kubernetes locally in minutes, perfect for testing and dev environments.
kubectl Cheat Sheet: Bookmark this as your go-to for common Kubernetes CLI commands.
Build and Deploy Your First Image on DigitalOcean Kubernetes: A hands-on tutorial that ties together Docker image creation and Kubernetes deployment.
Kubernetes for Beginners (YouTube - TechWorld with Nana): A visual, practical walkthrough of key Kubernetes concepts is great for Docker users.

Conclusion

Kubernetes might seem complex at first, but if you’re already familiar with Docker, you’re well on your way to mastering it. In this guide, you took important first steps by deploying your app, scaling it, and exposing it with a service, all using tools on your own machine. With a bit of practice and curiosity, you’ll soon unlock the full power of Kubernetes to manage containers at scale, whether locally or in the cloud.

Keep experimenting, and enjoy the journey from zero to Kubernetes pro!🚀

Docker MCP Catalog & Toolkit: Building Smarter AI Agents with Ease

Karan Verma — Tue, 20 May 2025 11:43:38 +0000

Introduction: What Is Docker MCP and Why It Matters

The rise of agent-based AI applications, powered by ChatGPT, Claude, and custom LLMs, has created a demand for modular, secure, and standardized integrations with real-world tools. Docker’s Model Context Protocol (MCP), along with its Catalog and Toolkit, addresses this need.

Docker is positioning itself not just as a container platform but as the infrastructure backbone for intelligent agents. In this post, we’ll explore the MCP architecture, Catalog, and Toolkit, and demonstrate how to build your own MCP server.

Section 1: Understanding MCP: The Model Context Protocol

What it is:

MCP is an open protocol that allows AI clients (like agents) to call real-world services securely and predictably.
It's designed for tool interoperability, secure credential management (handling API keys and tokens), and container-based execution.

Why it matters:

Without standards like MCP, agents rely on brittle APIs or unsafe plugins.
Docker provides a secure, isolated runtime to host these services in containers.

Visual overview:

How an AI client communicates with containerized services via MCP

Section 2: MCP Catalog: Prebuilt, Secure MCP Servers

What it includes:

A growing library of 100+ Docker-verified MCP servers, including:

Stripe
LangChain
Elastic
Pinecone
Hugging Face

Key features:

Each MCP server runs inside a container and includes:

OpenAPI spec
Secure default config
Docker Desktop integration

Why developers care:

Plug-and-play tools for AI agents.
Consistent dev experience across services.

Visual overview:

MCP Catalog integration with Docker Desktop

Section 3: MCP Toolkit: Build Your Own Secure MCP Server

Toolkit CLI Features:

mcp init → Scaffolds new MCP server
mcp run → Runs local dev version
mcp deploy → Deploy to Docker Desktop

Security features:

Container isolation
OAuth support for credentials
Optional rate limiting and tracing

Demo walkthrough:

npm install -g @docker/mcp-toolkit
mcp init my-weather-api
cd my-weather-api
mcp run

Visual walkthrough:

MCP Toolkit Workflow: From CLI to Container

Section 4: Connecting MCP Servers to AI Clients

Supported clients:

Claude (Anthropic)
GPT Agents (OpenAI)
Docker AI (beta)
VS Code Extensions

How it works:

Agents call /invoke endpoint defined in MCP spec.
Secure token exchange handles identity.
Response returned to model for reasoning/action.

Use case example:

Claude uses a Docker MCP server to call a Stripe payment processing container during an e-commerce interaction.

Visual flow:

Shows how Claude securely calls a Stripe service via Docker MCP.

Section 5: Best Practices for MCP Server Developers

Security:

Never use root containers
Use docker scan and trivy for image vulnerability scanning
Store secrets with Docker's secret manager (or Vault)

Performance:

Keep containers lightweight (use Alpine or Distroless)
Use streaming responses for LLM interaction

Testing tips:

Use Postman + curl to test /invoke endpoint
Lint OpenAPI specs with swagger-cli

Section 6: The Future of MCP: What Comes Next?

Predictions:

Docker AI Dashboard integration
MCP orchestration (multiple services per agent)
AI-native DevOps (agents building infra with MCP servers)

Opportunities for devs:

Contribute to open MCP servers
Submit to Docker Catalog
Build agent tools for internal or public use

Closing Thoughts

Docker’s MCP Catalog and Toolkit are still in beta, but the path forward is clear: AI apps need real-world tool access, and Docker is building a secure, open ecosystem to power it.

Whether you’re building agent frameworks or just experimenting with tool-using LLMs, now’s the perfect time to get involved.

Got ideas for MCP servers you want to see? Or thinking about contributing your own? I’d love to hear from you! 😊

From Beginner to Pro: Docker + Terraform for Scalable AI Agents

Karan Verma — Sat, 03 May 2025 10:49:32 +0000

Introduction

As AI and machine learning workloads grow more complex, developers and DevOps engineers are looking for reliable, reproducible, and scalable ways to deploy them. While tools like Docker and Terraform are widely known, many developers haven’t yet fully unlocked their combined potential, especially when it comes to deploying AI agents or LLMs across cloud or hybrid environments.

This guide walks you through the journey from Docker and Terraform basics to building scalable infrastructure for modern AI/ML systems.

Whether you’re a beginner trying to get your first container up and running or an expert deploying multi-agent LLM setups with GPU-backed infrastructure, this article is for you.

Docker 101: Containerizing Your First AI Model

Let’s start with Docker. Containers make it easier to package and ship your applications. Here’s a quick example of containerizing a PyTorch-based inference model.

Dockerfile:

FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "inference.py"]

Build & Run:

docker build -t ai-agent .
docker run -p 5000:5000 ai-agent

You now have a reproducible and portable AI model running in a container!

Terraform 101: Your Infrastructure as Code

Now let’s set up the infrastructure to run this container in the cloud using Terraform.

Basic Terraform Script:

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "agent" {
  ami           = "ami-0abcdef1234567890"  # Choose a GPU-compatible AMI
  instance_type = "g4dn.xlarge"

  provisioner "remote-exec" {
    inline = [
      "sudo docker run -d -p 5000:5000 ai-agent"
    ]
  }
}

Deploy:

terraform init
terraform apply

Boom your container is live on an EC2 instance!

Integrating Docker + Terraform: Scalable AI Agent Setup

Now, we combine both tools to:

Auto-provision compute with Terraform
Pull and run your Docker images automatically
Scale agents dynamically by changing Terraform variables

Example:

variable "agent_count" {
  default = 3
}

resource "aws_instance" "agent" {
  count         = var.agent_count
  ami           = "ami-0abc123456"
  instance_type = "g4dn.xlarge"
  ...
}

This lets you spin up multiple Dockerized AI agents across your cloud fleet—perfect for inference APIs or retrieval-augmented generation (RAG) systems.

Advanced Use Case: AI Agents with Multi-GPU, CI/CD & Terraform

Imagine this setup:

Each agent runs an OpenAI-compatible LLM locally (e.g., Mistral, Ollama, LLaMA.cpp)
Terraform provisions GPU instances and networking
Docker builds include prompt routers and memory systems
GitHub Actions auto-triggers Terraform for deployments

Benefits:

Reproducibility across dev, staging, and prod
Cost savings via spot instances
Seamless rollback via Terraform state

This is modern MLOps, containerized.

☁️ Hybrid Multi-Cloud AI with Docker + Terraform

You can even expand this setup to support:

Azure or GCP compute targets
Multi-region failover
Local LLM agents in Docker Swarm clusters (home lab, edge)

Pro Tip: Use Terraform Cloud or Atlantis for remote state and team workflows.

Visual Overview: How Docker and Terraform Work Together to Deploy AI Agents

This diagram maps the full lifecycle from writing infrastructure-as-code, containerizing models, and deploying everything automatically.

Simulated Real-World Project: Structure, README & CLI

This structure outlines a robust setup designed for deploying and testing Docker + Terraform AI agents in hybrid cloud environments. It’s a scalable, reliable framework that can be leveraged for complex AI deployments.

📁 Project Structure

.
├── Dockerfile
├── terraform/
│   ├── main.tf
│   ├── variables.tf
│   └── outputs.tf
├── cloud-init/
│   └── init.sh
├── ai-model/
│   ├── inference.py
│   └── requirements.txt
└── README.md

Sample README.md (Private/Internal Repo Summary)

Title: Scalable AI Agent Deployment with Docker & Terraform

This project sets up a fully Dockerized AI inference agent that is deployed via Terraform on GPU-enabled EC2 instances. It demonstrates:

Docker container for model inference (PyTorch/Transformers)
Terraform to provision compute infra + networking
Cloud-init for auto-starting containers post-launch
Multi-agent scaling logic with variable interpolation

Basic Usage:

terraform init terraform apply

Run Docker Locally:

docker build -t ai-agent .
docker run -p 5000:5000 ai-agent

CLI Output Snapshot

Terraform:

> terraform apply

Apply complete! Resources:
 - aws_instance.agent[0]
 - aws_security_group.main

Public IP: 34.201.12.77

Docker:

> docker ps

CONTAINER ID   IMAGE       COMMAND                STATUS       PORTS
ae34c2f1c11b   ai-agent    "python inference.py"  Up 2 mins    5000/tcp

⚙️ Note: This setup has been tested with both local GPUs and AWS EC2 g4dn instances. The Docker + Terraform pipeline helped me cut down deployment effort by over 60% and simplified environment consistency across dev and test runs.

Simulated Real-World Project: Structure, README & CLI

For more information on Docker, you can refer to the official Docker documentation and explore relevant open-source projects on Docker's GitHub. Additionally, for Terraform-related resources, check out the official Terraform documentation and Terraform GitHub.

Final Takeaways

✅ Docker simplifies packaging AI/ML models
✅ Terraform provisions scalable infrastructure in minutes
✅ Together, they form a powerful pattern for reliable AI deployment

Whether you’re running LLMs locally, deploying agents in the cloud, or scaling across multi-cloud environments, this stack is your launchpad.

👋 Call to Action

If this guide helped you, share it with your team or community!

Thanks for reading. Happy hacking and may your containers always build clean! 🚀

From Zero to GenAI Cluster: Scalable Local LLMs with Docker, Kubernetes, and GPU Scheduling

Karan Verma — Sat, 03 May 2025 08:11:44 +0000

A practical guide to deploying fast, private, and production-ready large language models with vLLM, Ollama, and Kubernetes-native orchestration. Build your own scalable GenAI cluster with Docker, Kubernetes, and GPU scheduling for a fully private, production-ready LLM setup.

Prerequisites

Before we begin, ensure your system meets the following requirements:

A Kubernetes cluster with GPU-enabled nodes (e.g., via GKE, AKS, or bare-metal)
The NVIDIA device plugin installed on the cluster
Helm CLI installed and configured
Docker CLI and access to a GPU-compatible runtime (e.g., nvidia-docker2)

Introduction

Local LLMs are no longer a research luxury, they're a production need. But deploying them at scale, with GPU access, container orchestration, and real-time monitoring? That’s still murky territory for many.

In this article, I’ll walk you through how I built a fully operational GenAI cluster using Docker, Kubernetes, and GPU scheduling. It serves powerful language models like vLLM, Ollama, or HuggingFace TGI. We’ll make it observable with Prometheus and Grafana, and ready to scale when the real load hits.

This isn’t just another tutorial. It’s a battle-tested, experience-backed blueprint for real-world AI infrastructure, written for developers and DevOps engineers pushing the boundaries of what GenAI can do.

Why Local/Private LLMs Matter

Many teams today are realizing that hosted APIs like OpenAI and Anthropic, while convenient, come with serious trade-offs:

Cost grows fast when usage scales
Sensitive data can't always be sent to third-party clouds
Customization is limited to what the API provider allows
Latency becomes a bottleneck in low-connectivity environments

Self-hosting LLMs means freedom, control, and flexibility. But only if you know how to do it right.

What We'll Build

We’ll deploy a production-grade Kubernetes cluster featuring:

vLLM / Ollama / TGI model server containers
GPU scheduling and node affinity
Ingress with HTTPS via NGINX
Autoscaling using HPA or KEDA
Prometheus + Grafana for real-time insights
Declarative infrastructure using Helm or plain YAML

Architecture Overview

Figure: High-level architecture of a scalable GenAI Cluster using Docker, Kubernetes, and GPU scheduling.

This modular, observable cluster gives you full control over your LLM infrastructure, without vendor lock-in.

Step 1: Dockerizing the Model Server

Let’s start small: a single Docker container that wraps a model server like vLLM.

# Dockerfile.vllm
FROM nvidia/cuda:12.2.0-base-ubuntu20.04

RUN apt update && apt install -y git python3 python3-pip

RUN pip install vllm torch transformers

WORKDIR /app
COPY start.sh ./
CMD ["bash", "start.sh"]

start.sh:

#!/bin/bash
python3 -m vllm.entrypoints.openai.api_server --model facebook/opt-1.3b --port 8000

Then, build your container:

docker build -f Dockerfile.vllm -t vllm-server:v0.1 .

You can also use Ollama if you prefer pre-packaged models and a lower barrier to entry. vLLM is recommended for higher throughput and OpenAI-compatible APIs.

This is your first step toward building a modular, GPU-ready inference system.

Step 2: Kubernetes Deployment with GPU Scheduling

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
        - name: vllm
          image: vllm-server:v0.1
          resources:
            limits:
              nvidia.com/gpu: 1
          ports:
            - containerPort: 8000
      nodeSelector:
        kubernetes.io/role: gpu
      tolerations:
        - key: "nvidia.com/gpu"
          operator: "Exists"
          effect: "NoSchedule"

And here’s the corresponding Service definition:

apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
    - protocol: TCP
      port: 8000
      targetPort: 8000

This exposes your model server inside the cluster.

Step 3: Ingress and Load Balancing

Install NGINX Ingress Controller:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install nginx ingress-nginx/ingress-nginx

Then configure ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vllm-ingress
spec:
  rules:
    - host: vllm.local
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: vllm-service
              port:
                number: 8000

Update your DNS or /etc/hosts to route vllm.local to your cluster.

Step 4: Autoscaling with KEDA (Optional)

helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda

With KEDA, you can scale your LLM pods based on GPU utilization, HTTP traffic, or even Kafka topic lag.

Step 5: Monitoring with Prometheus + Grafana

Install full-stack observability:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack

Expose a /metrics endpoint from your container.

from prometheus_client import start_http_server, Summary
import time

REQUEST_TIME = Summary('request_processing_seconds', 'Time spent processing request')

@REQUEST_TIME.time()
def process_request():
    time.sleep(1)

if __name__ == '__main__':
    start_http_server(8001)
    while True:
        process_request()

Or use GPU exporters like dcgm-exporter. Grafana will pull all this into beautiful dashboards.

Step 6: Optional Components

Vector DB: Qdrant, Weaviate, or Chroma
Auth Gateway: Add OAuth2 Proxy or Istio
LangServe or FastAPI: Wrap your model with an API server or LangChain interface
Persistent Volumes / Object Store: Save fine-tuned models using PVCs or MinIO

Final Thoughts

This isn’t just code. It’s the story of how I learned to stitch together powerful AI infrastructure from open-source tools and make it reliable enough for real-world teams to trust.

Docker gave me modularity. Kubernetes gave me orchestration. GPUs gave me the muscle.

Put together, they gave me something every AI builder wants: freedom.

If you're tired of vendor lock-in and ready to roll up your sleeves, this cluster is your launchpad.

This is just the beginning. Start building your GenAI infrastructure today and take control of your AI stack. Share your progress, contribute to the community, and let’s push the boundaries of what’s possible together.

See you at the edge! 🌍

From Zero to Local LLM: A Developer's Guide to Docker Model Runner

Karan Verma — Fri, 11 Apr 2025 16:29:17 +0000

Why Local LLMs Matter

Large language models have completely changed how we build apps, but most of them live in the cloud. That means you’re often stuck dealing with slow responses, expensive API calls, and worries about privacy or needing an internet connection. Running models locally on your own machine avoids all that, and you get faster, private, and offline-ready AI right at your fingertips.

Docker Model Runner changes that it brings the power of container-native development to local AI workflows so you can focus on building, not battling toolchains.

The Developer Pain Points:

Privacy concerns - It’s tough to test safely when your data has to be sent to cloud APIs.
High costs - Running prompts through paid APIs adds up fast, especially during early development and testing.
Complicated setup - Getting a local model up and running usually means dealing with complex installs and hardware dependencies.
Limited hardware - Many laptops just aren’t built to run large models, especially without a GPU.
Hard to test different models - Switching between models or versions often means reconfiguring your entire setup.

Docker Model Runner solves these by:

Standardizing model access with a simple CLI that pulls models from Docker Hub
Running fast with llama.cpp under the hood
Providing OpenAI-compatible APIs out of the box
Integrating directly with Docker Desktop
Using GPU acceleration when available supports Apple Silicon (Metal) and NVIDIA GPUs on Windows for faster inference

🐳 What Is Docker Model Runner?

It’s a lightweight local model runtime integrated with Docker Desktop. It allows you to run quantized models (GGUF format) locally, via a familiar CLI and an OpenAI-compatible API. It’s powered by llama.cpp and designed to be:

- Developer-friendly: Pull and run models in seconds
- Offline-first: Perfect for privacy and edge use cases
- Composable: Works with LangChain, LlamaIndex, etc.

Key Features:

OpenAI-style API served at:

http://localhost:12434/engines/llama.cpp/v1/chat/completions

GPU-free: works even on MacBooks with Apple Silicon and Windows 11 + NVIDIA GPUs
Easily swap between models with the UX and CLI
Integrated with Docker Desktop

Getting Started in 5 Minutes

1. Enable Model Runner (Docker Desktop)

docker desktop enable model-runner --port 12434

2. Pull Your First Model

docker model pull ai/smollm2:360M-Q4_K_M

3. Run a Model with a Prompt

docker model run ai/smollm2:360M-Q4_K_M "Explain the Doppler effect like I’m five."

4. Use the API (OpenAI-compatible)

curl http://localhost:12434/v1/completions \
-H "Content-Type: application/json" \
-d '{"model": "smollm2", "prompt": "Hello, who are you?", "max_tokens": 100}'

⚙️ Building Your Local GenAI Stack

Here's a simple architecture using Docker Model Runner as your inference backend:

- LangChain: For prompt templating and chaining
- Docker Model Runner: Runs the actual LLMs locally
- LlamaIndex: For document indexing and retrieval (RAG)
- React Frontend: Clean chat UI to interface with the model
- Docker Compose: One command to run them all

Sample Compose Example
Here’s a sample docker-compose.yml showing how Docker Model Runner could fit into a local GenAI stack:

services:
  chat:
    build: ./chat  # Replace with your frontend app path or Git repo
    depends_on:
      - ai_runner
    environment:
      - MODEL_URL=${AI_RUNNER_URL}
      - MODEL_NAME=${AI_RUNNER_MODEL}
    ports:
      - "5000:5000"

  ai_runner:    # Even if a service of type `model` is specified,
                # It doesn't run as a container — it runs directly on 
                  the host system via Docker Model Runner.

    provider:
      type: model
      options:
        model: ai/smollm2 # Specifies the local LLM to be used

Features:

Offline use with local model caching
Dynamic model loading/unloading to save resources
OpenAI-compatible API for seamless integration
GPU acceleration support on compatible systems

💡 Bonus: Add a Frontend Chat UI

Use any frontend framework (React/Next.js/Vue) to build a chat interface that talks to your local model via REST API.

Simple example fetch:

#!/bin/sh

curl http://localhost:12434/engines/llama.cpp/v1/chat/completions \
-H "Content-Type: application/json" \
-d ' {
"model": "ai/smollm2",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "Please write 500 words about the fall of Rome."
}
]
}'

This gives you a fully local LLM setup that runs straight on your machine whether you're on a MacBook with Apple Silicon or a Windows PC with an NVIDIA GPU. No cloud APIs, no internet needed. Just local models running natively.

🚀 Advanced Use Cases

- RAG pipelines: Combine PDFs + local vector search + Model Runner
- Multiple models: Run phi2, mistral, and more in separate services
- Model comparison: Build A/B testing interfaces using Compose
- Whisper.cpp integration: Speech-to-text container add-ons (coming soon)
- Edge AI setups: Deploy on airgapped systems or dev boards

The Vision: Where This Is Headed

Docker Model Runner Roadmap (Beta Stage):

Potential for a searchable, taggable ModelHub or Docker Hub registry
Plans to support Compose-native GenAI templates
Exploration of Whisper + LLM hybrid runners
Development of a dashboard for monitoring model performance
IDE integrations, such as VSCode extensions for prompt engineering and testing, are still under discussion and not yet available

Note: Docker Model Runner is currently in Beta. Some features and integrations are in early stages or planning phases and may evolve over time.

As a developer, I see this as a huge opportunity to lower the barrier for AI experimentation and help bring container-native AI to everyone.

Building a Scalable Event-Driven Pipeline with MongoDB, Docker, and Kafka

Karan Verma — Fri, 04 Apr 2025 16:35:24 +0000

In modern DevOps workflows, handling real-time data streams efficiently is crucial for building scalable applications. In this guide, we'll explore how to set up an event-driven pipeline using MongoDB, Docker, and Kafka to handle high-throughput data processing with ease.

Imagine an e-commerce platform processing millions of orders in real time. Our setup ensures seamless, fault-tolerant data streaming between services.

1. Why Event-Driven Architectures?

Traditional architectures struggle with real-time processing, batch jobs, and scalability. Event-driven systems address these problems by:

Decoupling components for greater scalability.
Processing data in real-time instead of batch operations.
Enhancing fault tolerance through asynchronous messaging.

Kafka serves as the central message broker, while MongoDB acts as a persistent data store for event logs and structured data.

2. Setting Up MongoDB with Docker

To run MongoDB in a containerized environment, use the following Docker Compose setup:

version: '3.8'
services:
  mongodb:
    image: mongo:latest
    container_name: mongodb
    restart: always
    ports:
      - "27017:27017"
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: example
    volumes:
      - mongodb_data:/data/db
volumes:
  mongodb_data:

Run MongoDB with:

docker-compose up -d

Now, MongoDB is up and running on port 27017.

3. Deploying Kafka in Docker

Kafka requires Zookeeper for coordination. We'll deploy both using Docker Compose:

services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    container_name: zookeeper
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
    ports:
      - "2181:2181"

  kafka:
    image: confluentinc/cp-kafka:latest
    container_name: kafka
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092

Start Kafka with:

docker-compose up -d

Check Kafka logs to confirm it's running:

docker logs -f kafka

4. Connecting Kafka & MongoDB

Kafka Connect enables data streaming between Kafka and MongoDB.

Step 1: Install MongoDB Kafka Connector

docker exec -it kafka bash
confluent-hub install mongodb/kafka-connect-mongodb:latest

Step 2: Configure Kafka Connector

Create a mongo-sink.json file:

{
  "name": "mongo-sink-connector",
  "config": {
    "connector.class": "com.mongodb.kafka.connect.MongoSinkConnector",
    "topics": "events",
    "connection.uri": "mongodb://root:example@mongodb:27017",
    "database": "eventDB",
    "collection": "eventLogs"
  }
}

Apply the configuration:

curl -X POST -H "Content-Type: application/json" --data @mongo-sink.json http://localhost:8083/connectors

Now, Kafka will stream events directly into MongoDB! 🚀

5. Scaling with Docker Swarm and Kubernetes

Deploying with Docker Swarm

To deploy MongoDB and Kafka as a Swarm service, initialize Swarm:

docker swarm init

Deploy services:

docker stack deploy -c docker-compose.yml event-pipeline
Now, the services are running as a scalable stack!

Deploying with Kubernetes and Helm

To deploy Kafka and MongoDB on Kubernetes, use Helm charts:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install kafka bitnami/kafka
helm install mongodb bitnami/mongodb

This ensures high availability and fault tolerance.

6. Optimizing Docker Images for Performance

To build efficient and secure containers:

Use small base images like Alpine: FROM alpine:latest
Minimize layers with multi-stage builds.
Use .dockerignore to exclude unnecessary files.
Enable Docker BuildKit for faster builds:

DOCKER_BUILDKIT=1 docker build .

7. Automating with DevOps Tools

CI/CD Pipelines: Automate deployment with Jenkins/GitHub Actions.
Infrastructure as Code (IaC): Use Terraform or Kubernetes for scalable deployments.
Monitoring & Logging: Leverage Prometheus and Grafana for system health.

Final Thoughts

By integrating MongoDB, Kafka, and Docker, we've built a scalable event-driven pipeline. This setup is perfect for real-time analytics, log processing, and microservices architectures.

💡 “How have you tackled event-driven architectures? Let’s discuss in the comments!”

Optimizing Docker Image Builds for Speed & Efficiency

Karan Verma — Fri, 04 Apr 2025 15:56:39 +0000

The Problem: Slow Docker Builds are a Bottleneck

Docker images form the backbone of modern containerized applications, but slow image builds can significantly impact developer productivity. Every second wasted waiting for a build to complete adds up, slowing down CI/CD pipelines and delaying deployments.

Common reasons for slow builds include:

Large base images bloating the final image size
Unoptimized Dockerfile instructions leading to inefficient caching
Unnecessary dependencies increasing build times
Frequent rebuilds due to changes in lower Dockerfile layers

The Solution: Optimize Your Dockerfile for Performance

By applying a few best practices, we can dramatically speed up Docker builds while keeping images lightweight and efficient.

1. Use a Minimal Base Image

Large base images slow down builds and increase attack surfaces. Instead, opt for lightweight images like Alpine Linux:

# Avoid large images like ubuntu:latest FROM alpine:latest

Why? Alpine is only ~5MB compared to Ubuntu (~29MB) or Debian (~22MB). This means smaller download sizes and faster builds.

2. Leverage Docker Build Caching

Docker caches layers from top to bottom. To maximize cache efficiency:

# BAD: Installing dependencies AFTER copying source code invalidates cache
FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install  # ❌ Re-runs on every change
CMD ["node", "index.js"]

**Fix: **Move unchanging layers before copying source files:

# GOOD: Dependencies installed first, source copied later
FROM node:18-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install  # ✅ Cached until package.json changes
COPY . .
CMD ["node", "index.js"]

Now, unless package.json changes, npm install is cached, reducing rebuild time.

3. Use Multi-Stage Builds

Multi-stage builds keep final images clean by discarding unnecessary build dependencies.

# Stage 1: Build dependencies
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Stage 2: Use a minimal runtime image
FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/myapp .
CMD ["./myapp"]

Benefit: The final image only contains the Go binary, making it smaller & faster.

4. Reduce Unnecessary Layers

Each RUN instruction creates a new layer. Minimize layers by chaining commands:

# BAD: Multiple RUN commands create extra layers
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*

Fix: Combine them into a single RUN command:

# GOOD: Reduces layer count
RUN apt-get update && \
    apt-get install -y curl && \
    rm -rf /var/lib/apt/lists/*

This minimizes image size and speeds up builds.

Use .dockerignore to Exclude Unnecessary Files

Docker builds everything in the build context. Exclude unnecessary files like logs, node_modules, and build artifacts:

.dockerignore:

node_modules/
.git/
*.log
.env

This reduces the build context size, leading to faster builds and reduced resource usage.

Final Thoughts

By following these best practices, you can significantly reduce Docker image size, improve build speed, and enhance CI/CD efficiency. Small optimizations can have big productivity gains!

DEV Community: Docker

Docker Just Made Hardened Images Free for Everyone – Let's Check Them Out!

What Are Docker Hardened Images?

Why This Matters (And Why Now)

How to Get Started – It's Super Easy

Some Practical Use Cases I Can See

Docker Hardened Images are Free

How to Pull Hardened Images Locally

Check for CVEs

Final Words

I Just Published My Book: Docker and Kubernetes Security

An Unexpected Journey

Self-Publishing

The Launch

Conclusion

MCP Horror Stories - Issue 1

Docker Deep Dive Workshop at WeAreDevelopers

Links

Technical Requirements

1. Docker Init

Usage

Exercises

2. Docker Bake

Usage

Exercises

3. Docker SBOM

Usage

Exercises

4. SBOM Attestations

Usage

Exercises

5. Docker Scout

Usage

Exercises

6. Docker Debug

Usage

Exercises

7. Docker Model Runner

Usage

Exercises

From Zero to Kubernetes: A Beginner's Guide to Orchestrating Docker Containers

Docker MCP Catalog & Toolkit: Building Smarter AI Agents with Ease

Section 1: Understanding MCP: The Model Context Protocol

Section 2: MCP Catalog: Prebuilt, Secure MCP Servers

Section 3: MCP Toolkit: Build Your Own Secure MCP Server

Section 4: Connecting MCP Servers to AI Clients

Section 5: Best Practices for MCP Server Developers

Section 6: The Future of MCP: What Comes Next?

From Beginner to Pro: Docker + Terraform for Scalable AI Agents

From Zero to GenAI Cluster: Scalable Local LLMs with Docker, Kubernetes, and GPU Scheduling

From Zero to Local LLM: A Developer's Guide to Docker Model Runner

Building a Scalable Event-Driven Pipeline with MongoDB, Docker, and Kafka

Optimizing Docker Image Builds for Speed & Efficiency