DEV Community: Ashutosh Shukla

Why your Docker Build time is more than it should ?

Ashutosh Shukla — Sat, 10 Oct 2026 16:40:50 +0000

If you have ever worked with Docker & written any Dockerfile for any backend service that includes some language & its packages & an image. chances are you have faced this problem of high Dockerfile build time already.

You might not have noticed it because for a self-paced project, these delays are in seconds which don't matter much to us. But when our hands are messing with 100s of containers using kubernets pods. These delay becomes the reason of large containers which takes more time to rebuild.

Hence it becomes necessary to grab the depth of this Idea early stage.

Today we will see with live example from one of my production style project where I tried to containerize a Go service. & understand ->

why certain steps come in top & why some in bottom of the Dockerfile
Difference between a Good Order & Bad Order Dockerfile
Thumb Rule of Writing efficient Dockerfiles.

Setup

1) go service from otel-demo (an open source project)

2) Two Dockerfiles that differ by three moved lines

Dockerfile_v1(Good Order)

In this Docker file, {1,2,3} lines are important libraries & checksum files needed to run any go file. This step of downloading the library into the working directory of our image is slow step & takes longer time than the rest of the layers.

Therefore, we have something called Layer caching in Docker. In the first cold build, every step runs one time, but in the next run, every step or layer that is unchanged gets cached, & docker uses that cached data instead of rebuilding the whole layer.

If that layer is changed, then every layer following that layer gets rebuilt, including itself.

FROM golang:1.27.1-bookworm AS builder
WORKDIR /app

COPY go.mod go.mod   (1)
COPY go.sum go.sum   (2)
RUN go mod download  (3)
 # ~ 30 sec build time, slow step:downloads-libraries

COPY genproto/oteldemo genproto/oteldemo  (4)
 # source code comes AFTER the download
COPY flags flags                          (5)    
COPY *.go ./                              (6)

RUN CGO_ENABLED=0 GOOS=linux go build -o /plain-linux-binary
EXPOSE 3550
CMD ["/plain-linux-binary"]

If you don't have any Idea what this code block is about, Don't worry - today we are not here to understand what these statement means but to understand what do we get to see if we change the order of these Instructions.

Are you ready :)

The Experiment

In this experiment we would change the order of good order dockerfile & will see what change we get to see in our build time. Using those numbers we would discern & find out how should we optimize our Dockerfile for minimum build time.

we are going to swap lines {4,5,6} which copy and downloads the source code and put them just above the {3} & will Observe the changes

Dockerfile__v2(Bad Order):
FROM golang:1.27.1-bookworm AS builder
WORKDIR /app

COPY go.mod go.mod   (1)
COPY go.sum go.sum   (2)
COPY genproto/oteldemo genproto/oteldemo  (4)
 # source code comes Before the download
COPY flags flags                          (5)    
COPY *.go ./                              (6)
RUN go mod download  (3)
 # slow step:downloads-libraries

RUN CGO_ENABLED=0 GOOS=linux go build -o /plain-linux-binary
EXPOSE 3550
CMD ["/plain-linux-binary"]

what's happening under the hood:

In Good order ->

go.mod is copied and stored in /app work directory of an image by named as go.mod

go.sum is copied and stored in /app work directory of an image by named as go.sum

run go mod download downloads library into the image.

Then {4,5,6} steps are there to copy & download the source code.

Time it took for the Good Order build:

1) Cold : 102.6 seconds ; as everything ran for the first time.

time docker build --no-cache --progress=plain -f docker/product-catalog/Dockerfile -t fincomm/product-catalog:dev application/product-catalog

2) Unchange: 3.8 seconds; as nothing in the code changed, so every layer is cached and got reused.

time docker build --progress=plain -f docker/product-catalog/Dockerfile -t fincomm/product-catalog:dev application/product-catalog

3) Change: 28 seconds; Now we change the source code a little by adding a comment in a main.go file in the last . so for the good order, the only step which re-ran were {4,,5,6} because they were copying & downloading source code into our image work directory.

echo "// cache test" >> application/product-catalog/main.go

time docker build --progress=plain -f docker/product-catalog/Dockerfile -t fincomm/product-catalog:dev application/product-catalog

Time it took for the Bad Order build:

Swapped: 55 second.

Noticed, How swapped version of bad order took more time than changed version of good order ? Any Idea why is that ? Try to build your own hypothesis & that way you can see if we match :)

Apparently that happened because of just one mistake we did - shifted the run go mod download after source code build.

There is a Thumb rule of a Dockerfile. It says something like

Any layer which is changed, all layers following it including itself will get rebuilt. Docker would cached invalidate every layer after it including that layer itself. And that's why we place layers that rarely change (e.g., downloading dependencies/libraries) near the top (beginning) of the Dockerfile, and layers that change frequently (e.g., application source code) near the bottom (end) of the Dockerfile.

Now what happened in our bad order dockerfile:

Docker invalidates the cache of "run go mod download" layer as it comes after the source code which got changed and rebuild & so as a default rule, this layer will get rebuild too.

And this will increase the build time from what the good order Dockerfile normally take.

What you have to do right now:

You have to Interact with this live artifact to solidify your learning
Draft a summary of what you have understand from this article & comment it under this Article & I will pinned down the best summary.

Immediately try to replicate this experiment with any Dockerfile for any language you could get.

you just need to change order of source code & libraries or package to replicate the result, you will have your own numbers & your own experiment :) Use "time docker build ..."

Banner Image Credit: Gemini

21 yr old kid explaining terraform in stupid simple language

Ashutosh Shukla — Fri, 04 Sep 2026 17:34:49 +0000

What if I told you that instead of clicking through cloud dashboards, you could describe your entire infrastructure in a file and have it built automatically?

That is exactly what Terraform does.

In this blog, I am breaking down everything I have learned so far as a beginner. If you are curious about how companies actually manage cloud infrastructure at scale, keep reading because it gets interesting very quickly.

What is Terraform?

Terraform is an Infrastructure as Code (IaC) tool created by HashiCorp.
But here is the part that makes it powerful.
It behaves like API as Code.

Instead of manually creating resources in AWS or Azure through a console, Terraform talks directly to cloud provider APIs and builds everything for you based on code.

You define infrastructure using HCL (HashiCorp Configuration Language) inside a file called main.tf.

Now imagine this:

What if your entire cloud setup could be recreated just by running a few commands from a file?

That is Terraform.

What Problem Did Terraform Solve?

Before Terraform became popular, organisations that wanted to migrate infrastructure between cloud providers faced a huge challenge.

Every cloud provider had its own syntax, tooling, and way of managing infrastructure. Migrating even a portion of infrastructure from one cloud to another often required months of effort, making hybrid and multi-cloud strategies expensive and inefficient.

HashiCorp solved this problem by introducing Terraform.

The idea was simple:

Learn one tool, write your infrastructure as code, and use providers to interact with different cloud platforms instead of learning every provider's unique syntax from scratch.
This made infrastructure much more portable across providers like AWS, Azure, Google Cloud, Oracle Cloud, DigitalOcean, and many others.

How Things Work Behind The Scene

Terraform keeps track of everything using a file called terraform.tfstate.

Think of it as Terraform’s memory.It remembers what it created, what exists, and what needs to change.

Now let’s walk through what actually happens when you run Terraform commands.

Step 1: terraform init

This is where everything begins.Terraform reads your main.tf file and figures out which provider you are using, like AWS.Then it downloads the required provider plugin.

Here is a simple way to think about it:

The provider plugin is like a translator between Terraform and the cloud.

Step 2: terraform plan

This is where things get interesting.
Terraform builds a map of your infrastructure and compares it with what already exists in the cloud.

It then shows you exactly what will change before doing anything.
Nothing is created yet.This step is like a preview of your infrastructure changes.

In technical terms, this mapping is termed as dependency graph. It tells us what resources are Created (+), Modified (~), and Deleted(-).

Step 3: terraform apply

Now the real execution begins. Once you approve the plan, Terraform sends instructions to the provider plugin.

The plugin converts those instructions into API calls that the cloud provider understands.For example, AWS receives standard API requests and creates the resources.

Step 4: State Update
After everything is created, the cloud provider returns important details like:

Resource IDs
IP addresses
Metadata

Terraform stores all of this inside terraform.tfstate.

This is what allows Terraform to manage updates and changes later.

The Full Flow

[ main.tf ]
      │
      ▼
[ Terraform Core Engine ]
      │ (RPC)
      ▼
[ Provider Plugin ]
      │ (REST API)
      ▼
[ Cloud Provider ]

What is RPC Doing Here?

Or more appropriate question here can be -> Why does Terraform need RPC?

RPC (Remote Procedure Call) acts as the communication bridge between Terraform Core and the Provider Plugin.

Terraform Core and provider plugins are completely separate programs running on your machine. Since they don't share memory, they cannot communicate directly.

RPC allows Terraform Core to send instructions to the provider plugin, which then translates them into API requests the cloud provider understands.

Variables

These help you a lot in writing clean code, so here is what it is->

Variables make Terraform configurations reusable and flexible.

Instead of hardcoding values inside main.tf, you can replace them with variables.

For example:

instance_type = var.instance_type

The variable itself can be defined inside variables.tf with a default value.

When you run terraform apply, Terraform checks whether you've supplied a value.

If you provide one, Terraform uses it.
If you don't, Terraform automatically falls back to the default value.

This makes the same configuration reusable across different environments without editing the code every time.

Outputs

Outputs are used to extract and display important information after Terraform finishes provisioning infrastructure.

They are especially useful for developers who don't have direct access to the AWS Console but still need important deployment details.

I like to think of it this way:

Its like those print statements we used to write in c, python et cetera. like if main.tf created ec2 instance, we define this outputs.tf file to print its public Ip address so that devs can use it later either to ssh into it or whatever purposes they want it to use for.

Example:

main.tf

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Example:
output.tf

output "server_ip" {
  value       = aws_instance.web.public_ip
  description = "The public IP address of the server."
}

After running:

terraform apply
Terraform immediately prints something similar to:

server_ip = "54.213.42.1"

This provides several benefits:

Instant Visibility – View important information like URLs, IP addresses, or database endpoints without opening the AWS Console.
Data Sharing – Pass resource IDs and outputs from one Terraform module to another.
Security Masking – Mark outputs as sensitive = true to prevent passwords and API keys from appearing on screen.

Terraform Examples

If you'd like to explore more Terraform code, you can visit my GitHub repository

github-repo

look at the main.tf, outputs.tf & modules -> I know we haven't discussed modules here yet cause it will defeat the purpose of making it beginners-freindly. but for now just keep in mind they are just some repeatable HCL code which could use by root main.tf file to create & replicate the infra - like creating an simple ec2 instance.

You can also simply search: terraform example github on web browser.
You'll find plenty of beginner-friendly repositories that demonstrate different Terraform use cases and infrastructure patterns.

Now If you've reached here, then it means you love this thing & so I want to leave you with a bonus point that most beginners get wrong about terraform.

Is Terraform only use for provisioning the cloud Infrastructure ?
Its a very basic question if you look into it, & most of the people never ask it because they are not learning why ? - Most of them are learning What ? & How ?

So here is the main idea - Terraform uses this advance functionality called API As Code.

So what this means is you can use Hashicorp Corporation Language (HCL) i.e Terraform syntax language to create & update almost any Infrastructure of any Application until unless it has its API. Or If I'm more direct then->

You can use Terraform to manage non-cloud services, SaaS tools, and internal applications by using specialized providers that communicate directly with third-party REST API

So If someone asks you Is Terraform only use to provision cloud Infrastructure - Now you know the answer!

Final Thoughts

Beleive it or not-I tried my best to hand you over with the simplified knowledge of terraform and I hope you could use this to become familiar with the terraform so that Its documentation doesn't scare you anymore.

PS: This article is a recreation of the article I published on my linkedin:Linkedin Article Link