DEV Community: utkarsh srivastava

How to Containerize a Full-Stack App (Part 2)-Optimizing the Frontend with Multi-Stage Docker Builds.

utkarsh srivastava — Wed, 04 Nov 2026 03:28:21 +0000

Series Navigation:

✅ Part 1: Setting up locally (Required)

📍 Part 2: Frontend Multi-Stage Docker Builds (You are here)

➡️ Part 3: Containerizing the Backend & MySQL

Intro

This is Part 2 of our series. If you haven't set up the local Full-Stack Todo app yet, check out Part 1: Local Setup to get your environment ready.

In Part 2, we will guide you on how to containerize our Frontend application. In the upcoming blog post, I will explain the rest of the details.

If you are a frontend developer and only want to know how to Dockerize your frontend, this section is very important. Also, you can use this Docker image in production as well.

Note: This Setup you can use for any React app that uses Vite. There may be a few changes if you are using some other bundler. But the basic idea of deployment remains the same.

Here is what we will cover:

Frontend Code Walkthrough: A brief overview of our React app structure.
Generating the Production Build: How to prepare the app for deployment.
Deployment Architecture: High-level view of our deployment
From Source Code to Container: Visualizing the transformation process
Writing Our First Dockerfile: Writing the step-by-step build instructions.
Creating nginx configuration file: Configuring nginx to serve our static files
Building Docker Image: Building Docker Image and Running it.
Managing Environment Variables: Configuring API URLs and secrets securely.
Docker File optimization: Intro to Docker Image Optimization.
Multi-Stage Docker file: The professional way to shrink image size.
Securing Frontend Docker Container: Restricting folder permissions and user access.
Bonus: Extra observation on nginx.
Wrap Up

1. Frontend Code Walkthrough: A brief overview of our React app structure.

Prefer Video? Watch Here

Our React app was built via vite. It had a folder structure like below

Where

frontend/
├── public/                 # Static assets (favicons, manifest, etc.)
├── src/                    # our todo  application source code
|——— .env                   # environment file    
├── .env-example            # Template for environment variables
├── .gitignore              # Files/folders to be ignored by Git
├── eslint.config.js        # Linting rules to keep code consistent
├── index.html              # Entry Point. Vite treats this file as source code. It contains a <script type="module" src="..."> tag that points to your React entry file (usually src/main.tsx).
├── package-lock.json       # Exact versions of installed dependencies
├── package.json            # Project metadata and script definitions
├── README.md               # Project documentation
├── tsconfig.app.json       # TypeScript config for the frontend app
├── tsconfig.json           # Main TypeScript configuration
├── tsconfig.node.json      # TypeScript config for Node-based tools (like Vite)
└── vite.config.ts          # Vite-specific settings and plugins

2. Generating the Production Build: How to prepare the app for deployment.

Prefer Video? Watch Here

So, to deploy this React app. We first need to create a bundle of it by running the build command.

So we need to run

npm run build

Once you run this command inside the frontend folder.
You can see the dist folder, which looks like the following structure

 dist/
 ├── assets/
  │   ├── index-DiW657_O.css # All your CSS (minified)
  │   └── index-D9fK2_zX.js  # All your React code + libraries (minified)
 ├── index.html # The main entry point (minified)
 └── vite.svg # Copied directly from public/

By running this command, Vite took our development code and transformed it into a highly optimized bundle designed for web browsers. Because our browser does not understand JSX or TypeScript. So Vite converts our code into standard JavaScript.

Vite creates a new directory in our root folder called dist/

This folder contains everything your web server needs:

index.html: The entry point, now updated with the correct paths to your hashed JS and CSS files.
assets/: A folder containing your minified .js and .css files.

Now to test our build locally, run the command

npm run preview

This starts a local server that serves the dist folder, allowing you to see exactly how your app will perform in production.

Now go to your browser and type http://localhost:4173/

You are able to see our todo app, so it shows that our build was created successfully, and it is also running perfectly.

Now kill that server by running ctrl + c or cmd + c in mac.

3. Deployment Architecture: High-level view of our React app deployment.

Prefer Video? Watch Here

Before we proceed, we first need to understand how our React app actually runs in production.

So in the code walkthrough section, we ran the npm run build command in order to build our project. Then in order to test that build
Locally, we ran npm run preview command. This command spins up a web server and serves the dist folder.

We need to set up a similar environment for our production.

For the web server, we will use nginx because it is mostly used in production. And nginx will handle upcoming requests and serve the dist folder.

See the diagram to get a better idea

In summary: Nginx takes a web request, finds the correct static file on the disk, and hands it back to the browser.

For Production, we need:

A web server, i.e., nginx
dist folder (bundle of our application)

4. From Source Code to Container: Visualizing the transformation process.

Prefer Video? Watch Here

Before we proceed, I would like to provide a high-level overview of containerization.

Containerization involves a few steps

Stage 1: Our Source Code
Stage 2: Take our source code and compile our source code and configuration into a package
Stage 3: The result of Stage 2 is a static Docker Image
Stage 4: This is the live, running instance of the created Docker image. Now we can access our application

I hope the above diagram gives us some idea.

So I think our responsibility is to create a Docker image for our application.

But how do we provide our source code to Docker so that it can build the Docker image?

Also, how does it understand what it needs to do to build our project?

So here comes Dockerfile to rescue us.

4.1 What is a Dockerfile?

"A Dockerfile is a simple text file that acts as a blueprint for building a Docker Image. It contains a set of sequential instructions that tell Docker exactly how to set up the environment, copy your code, and get your application running."

We need to create a Dockerfile in our frontend directory. In the Dockerfile, we define everything that is required to build our project.

So, how do we create our Docker file, and what content will we put inside it so that Docker understands it and create docker image by reading it?

5. Writing Our First Dockerfile: Writing the step-by-step build instructions

Prefer Video? Watch Here

Go to the frontend directory if you are not and inside that directory, create a file with the name Dockerfile.

Open Dockerfile.

So to build our project, we need npm (Node Package Manager)
And it comes with Node.js. So first, we need Node.js

So we will use a prebuilt Node.js image from Docker Hub. So that we can run the npm command.

Copy the line in your Dockerfile

FROM node:lts

As we know, to serve our React app, we need a web server.
We already discussed that we will use Nginx for this.
Now let's install nginx.

Copy the line below in your Dockerfile

# Updates the Linux package manager and installs Nginx
RUN apt-get update && \
    apt-get install -y nginx

Now let's set up WORKDIR inside our container. All subsequent commands (COPY, RUN, CMD) will be executed relative to this path.

Copy the line below in your Dockerfile

WORKDIR /frontend-app

So let's recap what we've done. We have installed Node.js. Because we need it to build our project. Also, we installed nginx so that we can serve our React app.

Now to serve our frontend. We need to build our ReactJS project. To build it, we first need to install the project dependencies. Then we need to copy our project code inside the container. So that when we run the npm run build command. It successfully create build for our react.js project.

For installing dependencies we need package.json file.

Add this line to your Dockerfile

COPY package*.json ./
RUN npm ci

This will copy package.json. Inside the workdir that we set up above. And then install dependencies.

What is RUN npm ci?

Runs a "clean install." This is faster and more reliable than npm install for automated environments (CI/CD) because it adheres strictly to the package-lock.json.

Via the above command, we installed our Project dependencies. Now we need to build our project. So, for building the project, we need to copy our frontend project code as well inside the container.

Add this line to your Dockerfile

COPY . .

Copy the rest of your source code into the container. Except files which are defined inside the dockerignore file. We will talk about the dockerignore later.

Now, let's add a build command for building our project.

RUN npm run build

Via this command, we build our project.

Now we need to set up our Nginx so that it serves our static build files.

First of all, we create a directory. Where will we store our static files? Right now, our bundle files are present inside the dist folder.

Then we copy those files from dist to the mywebsite folder.

Add these lines to your Dockerfile

# Ensure nginx directories exist
RUN mkdir -p /frontend-app/mywebsite

# Copy nginx config
COPY nginx.conf /etc/nginx/sites-available/default

# Move dist files
RUN cp -r ./dist/* /frontend-app/mywebsite/

We did not talk about this line COPY nginx.conf /etc/nginx/sites-available/default

This line will overwrite the default Nginx configuration with your custom config file. This tells Nginx how to handle routing and where to look for static files.

We will talk about it more later.

We're done with our project setup. Now we need to expose the port as well. So that when we try to connect with our frontend, we can reach our web server, which is running on port 80.

EXPOSE 80

This command tells users (and Docker) that the container listens on port 80. Here we are exposing the container port 80.

Now let's start our nginx server

CMD ["nginx", "-g", "daemon off;"]

The above command is divided into two commands:

nginx: Starts the nginx server.
-g "daemon off;”: Runs Nginx in the foreground. If you don't do this, Nginx runs in the background, and the Docker container will immediately exit (stop) because it thinks its job is done.

That's it, we're done with our Dockerfile. Final version of your Dockerfile looks like this:

FROM node:lts

# Install nginx on Debian
RUN apt-get update && \
    apt-get install -y nginx

WORKDIR /frontend-app

COPY package*.json ./
RUN npm ci

COPY . .

RUN npm run build

# Ensure nginx directories exist
RUN mkdir -p /frontend-app/mywebsite

# Copy nginx config
COPY nginx.conf /etc/nginx/sites-available/default

# Move dist files
RUN cp -r ./dist/* /frontend-app/mywebsite/

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

6. Creating nginx configuration file: Configuring nginx to serve our static files

Prefer Video? Watch Here

When we write our Dockerfile. We encounter one line

COPY nginx.conf /etc/nginx/sites-available/default

Here we are copying some nginx.conf file to some location. But currently, in our project, inside the frontend directory. We don't have any nginx.conf file. So what's the purpose of this file?

Let's talk about it

Nginx comes with a default configuration file. When a request reaches Nginx, it looks for a configuration file which matches the request. If it cannot find the conf file, it selects default.conf.

And default.conf comes with predefined rules. We want to override it with our custom configuration rules. So that niginx handle our request flawlessly.

Also, we want nginx to look into /frontend-app/mywebsite directory. For serving static file.

Create a file nginx.conf inside frontend directory.

And then copy and paste the content below into it

server {
    listen 80;          # Listen for IPv4
    listen [::]:80;     # Listen for IPv6
    server_name localhost;

    root /frontend-app/mywebsite;
    index index.html;


    location / {
        try_files $uri /index.html;
    }
}

Let's break down each line step by step

First things first, the conf file had

server {
options
}
This denotes a server block. When any request reaches the web server, it will start looking for server_name on these server blocks. Once server_name matches, then that particular server block option is applied to the server.

Nginx is designed to always serve something rather than just crashing. If it can't find a server_name that matches the URL the user typed, it looks for a block labelled with the default_server flag.

Standard Default: Usually, this is a block that listens on Port 80 and points to a folder like /var/www/html or /usr/share/nginx/html.

The Result: The user will see the famous "Welcome to nginx!" landing page instead of your actual website.

I hope you understand the point. Now let's break down the above file step by step.

listen 80;
Tells Nginx to listen for incoming web traffic on port 80 using IPv4.

listen [::]:80;
Tells Nginx to listen for incoming web traffic on port 80 using IPv6.

server_name localhost;
Tells Nginx to apply these rules when the request comes to "localhost" (or your domain name in production).

root /frontend-app/mywebsite;
Sets the home base. It tells Nginx that all your static files (HTML, CSS, JS) are stored inside the /frontend-app/mywebsite folder.

index index.html;
Defines the default file. When a user visits your site without specifying a file, Nginx automatically serves them index.html.

The "Magic" for Single Page Apps (React):

location / {
try_files $uri /index.html; This line prevents 404 errors on refresh. It tells Nginx: "First, look for the specific file the user asked for. If you can't find it, don't show an error—just serve index.html and let the JavaScript app handle the routing."
}

$uri —> Requested File like if user type
http://localhost:8080/dashboard —> $uri is /dashboard.

Nginx checks: Does a file called /frontend-app/mywebsite/dashboard exist?
Result:
No (Because /dashboard is just a virtual route in your React app, not a real file on the disk)

Fallback: Nginx moves to the second option in your try_files line -> /index.html.

Outcome: The user gets index.html, and your JavaScript app loads and reads the URL to display the “Dashboard” page content.

We are still not ready to build our image. Because if you try to build an image now. We will accidentally send our .env secrets or a heavy folder like node_modules. Because in our DockerFile we added this line COPY . ..

We need to restrict this behaviour somehow so that Docker will not pick up those files.

How can we do this?

Ans is the .dockerignore file.

What is .dockerignore?

The .dockerignore file is just like .gitignore, but for Docker. It tells Docker which files to exclude when sending your code to the container builder.

It speeds up the process of building images. It ignore heavy folder likes node_module, dist etc

It prevents sensitive files (like .env secrets or .git history) from accidentally ending up inside your public image.

Create a .dockerignore file inside the frontend directory

and copy the content

**/.classpath
**/.dockerignore
**/.env
**/.git
**/.gitignore
**/.project
**/.settings
**/.toolstarget
**/.vs
**/.vscode
**/.next
**/.cache
**/*.*proj.user
**/*.dbmdl
**/*.jfm
**/charts
**/docker-compose*
**/compose.y*ml
**/Dockerfile*
**/node_modules
**/npm-debug.log
**/obj
**/secrets.dev.yaml
**/values.dev.yaml
**/build
**/dist
LICENSE
README.md
**/backend
/*.yaml

7. Building Docker Image: Building Docker Image and Running it

Prefer Video? Watch Here

Now we are all set for building our Docker image

After saving all the files

Go to your terminal and go to the frontend directory by running the command

cd frontend

Once you are in the frontend directory. Now, let's build a Docker image

Run the build command

docker build -t my-frontend-todo-app:v1 .

Let's break down the above command

docker build

This is the core instruction. It tells the Docker engine to read a Dockerfile and "bake" it into a static image (a snapshot of your application).

-t my-frontend-todo-app:v1

-t (Tag): This flag lets you name your image.

my-frontend-todo-app: our image name

:v1 Version tag allows us to provide a version to our build. If we leave this, our Docker default uses the latest as the version.

. —> (The Dot) Most important part! It effectively says: "Look for the Dockerfile and the source code in the current folder I am in right now."

Once you run the above command and it build docker image successfully. Your terminal looks like this:

You can also check the Docker image by going to Docker Desktop inside the image tab.

The diagram illustrates what we have done so far.

We successfully created our frontend image. Now it's time to run it.

In the same terminal where you built the image, run the command below or open a new terminal and cd to frontend if you are not in the frontend directory.

And run the command

docker run -it -p 8080:80 --name my-todo-app-container my-frontend-todo-app:v1

Once you run the above command, your terminal looks like this:

Let's break down the above command

docker run

The command to start a new container from an image.

-it

This runs the container in Interactive Mode. Instead of running silently in the background, it attaches the container to your current terminal window so you can see the logs (Nginx output) immediately.

-p 8080:80

(Port Mapping) This acts as a bridge between your computer and the container.

8080 —> The port on your laptop. You will access the site at http://localhost:8080

80 —> The port inside the container where Nginx is listening.

-name my-todo-app-container

Gives the container a custom name. Without this, Docker assigns a random name.

my-frontend-todo-app:v1

Tells Docker exactly which image and version tag to use as the blueprint for this container.

Note:
Right now, we are running the Docker container in interactive mode, which has hijacked our current terminal. If you don’t want that, run the Docker container in detach mode so that the Docker container runs in the background without hijacking our terminal.

The command will run the container in detach mode. Just replace -it with -d. You can play around with it more

docker run -d -p 8080:80 --name my-todo-app-container my-frontend-todo-app:v1

Once the above command is successful, it starts showing in Docker Desktop. Go and check the container section in Docker Desktop

Now go to the browser and go to the URL http://localhost:8080. Now you are able to see our to-do app.

Hurray, our app is perfectly built and up and running.

See the image below for a high-level view. What’s going on

Let's test out the whole flow

If your backend is not running. Go to the backend directory and spin up the backend server. By running

npm run dev

Note: Make sure your MySQL container is up and running

Once our backend is up and running. Go to the browser where our frontend app is running and open the network panel. Or go to the URL http://localhost:8080/.

Open the network tab and in the filter select fetch/xhr

Now refresh this page. We are able to see undefined in the network panel. Click on it to open the details of the request.

Ok, but why is undefined going in the request?

Let’s try to add a new todo and see what’s going to happen

It is still giving me undefined in the URL. What’s going on

Our backend server is running on port 5500, but the frontend call goes to http://localhost:8080/undefined.

Why, because we messed up with the env variable.

Check your .env file in the frontend

It looks like below

This is the correct URL for our backend. But we do not pass our env variable to the frontend, that’s why it’s calling the wrong URL with undefined.

So, how can we pass our environment variable in a Docker image? In the next section, we will talk about it.

8. Managing Environment Variables: Configuring API URLs and secrets securely.

Prefer Video? Watch Here

Handling environment variables is crucial and requires extra precaution. So that we do not expose our secrets accidentally in public.

Let's understand how to handle env variables

There are two ways we can pass the env variable in our Docker image

Passing env variables during build time using build args.
Passing env variables at run-time by injecting them into the window object.

Let's discuss both of them one by one

1. Passing env variable during build time using build args:

In this approach, when we are building the image, we only need to pass the env variable using the build arguments into our image.
These variables become static. In order to change the env variable, we need to rebuild the image.

This approach we mostly avoid because it is not efficient. Because we need to rebuild the image every time if the environment variable changes. And building images is a costly or time-consuming process.

Ok, enough talk now, let’s try out

First things first, we need to add the build arg VITE_API_URL in our Docker file. Add it after the line
COPY . .

# Build arguments for environment variables
ARG VITE_API_URL
ENV VITE_API_URL=$VITE_API_URL

Now our Dockerfile looks like


FROM node:lts

# Install nginx on Debian
RUN apt-get update && \
    apt-get install -y nginx

WORKDIR /frontend-app

COPY package*.json ./
RUN npm ci

COPY . .

# Build arguments for environment variables
ARG VITE_API_URL
ENV VITE_API_URL=$VITE_API_URL

RUN npm run build

# Ensure nginx directories exist
RUN mkdir -p /frontend-app/mywebsite

# Copy nginx config
COPY nginx.conf /etc/nginx/sites-available/default

# Move dist files
RUN cp -r ./dist/* /frontend-app/mywebsite/

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Now build a new image by passing the build args as our env variables. In our case, it's a backend URL. Go to the terminal where we ran our Docker container. Stop it by pressing Ctrl + c. It stops the running container.

Then run the docker build command by passing the --build-arg flag with the build arg VITE_API_URL, with our backend URL.

Like --build-arg VITE_API_URL=http://localhost:5500/api/todos

Copy Api backend URL from the frontend .env file. And then pass that in
docker build command

docker build --build-arg VITE_API_URL=http://localhost:5500/api/todos -t my-frontend-todo-app-with-env:v1 .

Once it's built successfully, it looks something like this

Now run it via the docker run command

docker run -d -p 8080:80 --name my-todo-container-with-env my-frontend-todo-app-with-env:v1

In the command above, we ran it in detach mode, so it will not hijack our terminal. It will start the container in the background.

If the above command is successful, you will see something like this in the terminal

You can also verify from the Docker Desktop

Now go to http://localhost:8080 or refresh the page if you already have it open in the browser

Woo, we can see two seeded todos from the database, and we are now hitting the correct URL.

We're done with this approach. Let’s see the second approach now

2. Passing env variables at run-time by injecting them into the window object

So the idea is that somehow we will provide an env variable to our frontend at runtime so that we don’t need to build images every time.

So How we do this?

Our frontend is running on a browser. They cannot access the Docker container's environment variables (like process.env) at runtime.
So when the browser requests index.html from the server. We inject one JS script into our index.html. That script will inject our env variable into the window object.

Note:

But this approach only works if your environment does not contain any sensitive data. In general, we avoid putting sensitive data like api key, password, etc. in the frontend. Because with this approach, anyone can see your env variable in the console by accessing the window object.

Let’s implement this as well

Comment out those lines that we added previously for build args.

# Build arguments for environment variables
# ARG VITE_API_URL
# ENV VITE_API_URL=$VITE_API_URL

Now, inside the frontend directory, create a file nginx-entrypoint.sh

And copy the snapshot below and paste it into nginx-entrypoint.sh

#!/bin/sh

# Start the generated config file
CONFIG_PATH="/frontend-app/mywebsite/env-config.js"
echo "window.env = {" > $CONFIG_PATH

# Find all environment variables starting with "VITE_" and add them to the file
for var in $(env | grep "VITE_"); do
  name=$(echo "$var" | cut -d "=" -f 1)
  value=$(echo "$var" | cut -d "=" -f 2-)
  echo "  $name: \"$value\"," >> $CONFIG_PATH
done

# End the config file
echo "};" >> $CONFIG_PATH
echo "Environment variable injection completed."
exec nginx -g 'daemon off;'

nginx-entrypoint.sh

This script runs immediately before Nginx starts. It takes the environment variables from Docker and writes them into a real JavaScript file that the browser can read.

Line-by-Line Breakdown

Create the File (echo "window.env..."). It creates a new JavaScript file called env-config.js inside the /frontend-app/mywebsite and starts defining a global object: window.env = {. 
The Loop (for var in...) It looks through all the system environment variables currently set in the container.
- grep "VITE_": It filters the list to only grab variables that start with VITE_ (security measure to avoid exposing secrets like internal keys). 
The Injection (echo " $name: \"$value\","). It extracts the Name and Value of the variable and writes them into the JS file as a key-value pair.
- Result inside file: VITE_API_URL: https://my-api.com, 
Close & Launch (exec nginx...) It closes the JS object (};) and finally starts the Nginx server to serve your website.

Final Result: Our frontend code can now access variables via window.env.VITE_API_URL.

Once the above file is saved. Now we want to run this script before nginx starts so that we can inject the env variable at runtime. To do that

Go to Dockerfile and add the lines after the RUN mkdir -p /frontend-app/mywebsite command

COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh
RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh
RUN chmod +x /frontend-app/nginx-entrypoint.sh

Here we are copying nginx-entrypoint.sh into Docker, converting any Windows-style line endings to Linux format to prevent execution errors, and giving it executable permission so that Docker can run this script.

After adding the above lines, our Docker file looks like this:

Now, comment out this line

# CMD ["nginx", "-g", "daemon off;"]

And after the above line, add

ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]

This command tells Docker: "No matter what else happens, run this script first when the container starts."

It guarantees your environment variables are injected every single time the container launches.

Finally, our Dockerfile will look like this

FROM node:lts

# Updates the Linux package manager and installs Nginx
RUN apt-get update && \
    apt-get install -y nginx

WORKDIR /frontend-app

COPY package*.json ./
RUN npm ci

COPY . .    

# Build arguments for environment variables
# ARG VITE_API_URL
# ENV VITE_API_URL=$VITE_API_URL

RUN npm run build

# Ensure nginx directories exist
RUN mkdir -p /frontend-app/mywebsite
COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh
RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh
RUN chmod +x /frontend-app/nginx-entrypoint.sh

# Copy nginx config
COPY nginx.conf /etc/nginx/sites-available/default


# Move dist files
RUN cp -r ./dist/* /frontend-app/mywebsite/

EXPOSE 80
# CMD ["nginx", "-g", "daemon off;"]
ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]

We are almost done with this approach; only a small change is required.

As we know, this script will generate an env-config.js file. We also need to add this script to our index.html, then only the browser downloads it, and then only the JavaScript script executes and adds our env variables into the window object.

Go to index.html of the frontend directory and add the line below inside the <head> tag.

<script async src="/env-config.js"></script>

index.html

Now that we're done with this setup, let’s build a new image. Make sure you are in the frontend directory.

Run the build command in the terminal for building the image

docker build -t my-frontend-todo-app-with-runtime-env:v1 .

It’s build our image if everything is fine.

Now, how to pass the env variable so that our nginx-entrypoint.sh reads our env variable.

We can pass an env variable or a whole env file via the Docker run command. To run and pass environment variables into a Docker container, run the command below.

Note:

Before running the command. Make sure port 8080 is free. If your frontend container is running on port 8080. Please first stop it.
Via Docker Desktop.

Go to Docker Desktop and click on the action button

docker run -d -p 8080:80 --env-file ./.env --name my-todo-container-with-runtime-env my-frontend-todo-app-with-runtime-env:v1

Here, the --env-file flag is used to pass the whole .env file.

Once your above command is successful, our container starts successfully

Now our container is running successfully. Go to the browser and check http://localhost:8080

Hurray👏, we can see our todos

We've done it. You can check it in the window object by going to the browser devtools console panel and typing

window.env

You can see VITE_API_URL env variables in the devtool console panel.

We successfully passed our ENV_variable at runtime. I mostly prefer this approach when my environment variable contains no sensitive information.

So we're done with containerizing our frontend app. Now, let’s look at how to optimize the size of our Docker image. And make it production-ready

In the next section, we will discuss it.

9. Docker File optimization: Intro to Docker Image Optimization.

Prefer Video? Watch Here

Let’s first check the size of our images

Run the below command to see the list of images. Remember, we need to focus on the image my-frontend-todo-app-with-runtime-env:v1

docker images

See the size of our image, it is 1.28 GB. And see also the MySQL DB image size 777mb. Our image size is greater than MySQL.

Note: These image sizes may vary from system to system. So don't worry about it. Just understand the intent.

This is not good; we need to reduce the size of the image because in production, we can’t use very large images. Also, when Docker downloads this image from the registry, it takes a lot of time.

So, how can we reduce image size?

Right now, we are using the node:lts image for Node.js. Which is a standard image and not lightweight.

In Docker for production usage, we mostly prefer images like Alpine, slim and distroless images. These images are lightweight and recommended for use.

Note:
If you are building any banking application where security is a concern, then go with distroless images. These images do not contain any bash, package manager, or Hardest to hack because a hacker is unable to execute any command on it. But also the hardest to debug.

For our use case, we will use an Alpine image of Node.js.

We need to make some changes to our Dockerfile. So that we can use an Alpine image.

Change

FROM node:lts

FROM node:lts-alpine3.22

Replace

RUN apt-get update && \
     apt-get install -y nginx

with

RUN apk add --no-cache nginx

Replace

COPY nginx.conf /etc/nginx/sites-available/default

With

COPY nginx.conf /etc/nginx/http.d/default.conf

After changes, our Dockerfile looks like below

FROM node:lts-alpine3.22

RUN apk add --no-cache nginx    

WORKDIR /frontend-app

COPY package*.json ./
RUN npm ci

COPY . .    

# Build arguments for environment variables
# ARG VITE_API_URL
# ENV VITE_API_URL=$VITE_API_URL

RUN npm run build

# Ensure nginx directories exist
RUN mkdir -p /frontend-app/mywebsite
COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh
RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh
RUN chmod +x /frontend-app/nginx-entrypoint.sh

# Copy nginx config
COPY nginx.conf /etc/nginx/http.d/default.conf


# Move dist files
RUN cp -r ./dist/* /frontend-app/mywebsite/

EXPOSE 80
# CMD ["nginx", "-g", "daemon off;"]
ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]

Now let’s build this image and run it. But before doing that, we need to stop the frontend container that we started previously.

Go to Docker Desktop and click on the action button

Run the build command for building the image. Run inside the frontend directory

docker build -t my-frontend-todo-optimize-app:v1 .

To run a container, run the command below in the terminal

docker run -d -p 8080:80 --env-file ./.env --name my-frontend-todo-optimize-app my-frontend-todo-optimize-app:v1

Now, once it runs successfully, go to the browser and check http://localhost:8080

It’s working fine, and it's able to access our backend as well.

Note:
If you face any issue on the backend, like the todos api getting 500, then stop and then again restart the backend server.

Now go to the terminal and run the docker images command, and now check the size of the container.

See that from 1 GB to 281 MB we drastically reduce the size.

Can we optimize our image further?

Is this image is production ready?

Do we build images like this in production? Or is there any other way?

We will talk about it in the next section.

10. Multi-Stage Docker file: The professional way to shrink image size.

Prefer Video? Watch Here

For production, a multi-stage Docker file is recommended.

So the Dockerfile we built so far is a single-stage Dockerfile. There is only one stage.

The drawback of a single-stage Docker file is that it attempts to do everything—downloading source code, installing dependencies, building the app, and running it—inside the same environment.

This increases the size of the images. Also, it exposes the attack surface for hackers because it contains more tools that will give hackers more chances to hack it.

But if we use a multi-stage Docker build, we get rid of these problems

So In multi stage docker file. We build our image in multiple stages. Like the build stage, final stage or prod stage.

In the build stage

We copy our source code and package.json, package-lock.json files.
Then we install all the dependencies.
And finally, we build the code.

In Final stage or Prod Stage

We install the nginx image
Copy the dist folder from the build stage and put it inside the web server directory.

Because in Prod we only need a web server and our build folder, that’s it.

And in a multi-stage Dockerfile, the final image only had these two things.

Enough talk, let’s write our multi-stage Docker file

First things first, comment out the older content of the Docker file. Once you comment out the Docker file, you will be able to see some errors in VS Code. But don't worry about it.

Then copy the content below after the commented content

FROM node:lts-alpine3.22 AS build
WORKDIR /frontend-app
RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=package-lock.json,target=package-lock.json \
    --mount=type=cache,target=/root/.npm \
    npm ci

# Copy the rest of the source files into the image.

COPY . .

# Run the build script.

RUN npm run build

FROM nginx:stable-alpine-slim AS final

COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh
RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh
RUN chmod +x /frontend-app/nginx-entrypoint.sh

# Copy the production dependencies from the build stage
COPY --from=build /frontend-app/nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /frontend-app/dist /frontend-app/mywebsite


# Expose the port that the application listens on.
EXPOSE 80
ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]

Line-by-line explanation

So here we define two stages, one is build and another is final

Build Stage:

We set up node js environment for building our application.

FROM node:20-alpine3.22 AS build

Think of AS build like giving a name tag to a specific step in your setup. It simply lets you tell Docker later on, 'Hey, remember that step we named 'build'? Go grab the files from there.

The above line tells Docker to download a lightweight version of Linux ("Alpine") that has Node.js LTS version installed.

WORKDIR /frontend-app

Creates a folder inside the container at /frontend-app and sets it as the default location for all future commands.

RUN --mount=type=bind,source=package.json,target=package.json

This command looks different. Usually, we do COPY package.json . This physically duplicates the file into a layer of our Docker image.

But --mount=type=bind,source=package.json,target=package.json. In this way, we are telling to Docker Don't copy the file. Just let me 'borrow' package.json from my computer (source) and make it visible inside the container at package.json (target) just for the duration of this command.

It keeps the image layer cleaner. As soon as the command finishes, the file is technically no longer "in" that layer, because it was never copied, only mounted.

Note: The second line does the same thing for the package-lock.json file.

--mount=type=cache,target=/root/.npm

Problem:

Normally, Docker containers start fresh. When you run npm install, it downloads megabytes of files from the internet. If you rebuild the image, it forgets those downloads and does it all over again.

This command tells Docker to create a special storage bucket (cache) on your host machine (your computer) and mount it to /root/.npm inside the container (which is where npm stores its cache).

So now npm downloads libraries and saves them to /root/.npm. As cache, and when we try to rebuild the image. It just reaches out to our host machine( our laptop) storage and grabs the files instead of downloading them from the internet again.

This speeds up the process of installing dependencies. Also not store package.json or package-lock.json files in our image because we don’t need these files in our final image as well.

npm ci

Installs your project dependencies.

COPY . .

Copies all the files from your laptop (current directory) into the container's current folder (/frontend-app)

RUN npm run build

This usually creates a dist folder containing the final website files.

Final Stage:

This section throws away the heavy Node.js tools and starts fresh with a tiny web server.

FROM nginx:stable-alpine-slim AS final

We use a "slim" version of Nginx. It doesn't have Node.js; it only knows how to serve web files.

COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh

Copies a custom script file from your laptop to the root of the container.

RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh

Removes hidden Windows line endings from the script so it doesn't crash inside the Linux container.

RUN chmod +x /frontend-app/nginx-entrypoint.sh

Changes the permissions of that script to make it executable (so it can be run as a program).

COPY --from=build /frontend-app/nginx.conf /etc/nginx/conf.d/default.conf

It reaches back into the build stage to grab our custom configuration file and places it into the final Nginx folder to overwrite the server's default settings.

COPY --from=build /frontend-app/dist /frontend-app/mywebsite

Copies the compiled website from the dist folder from the "build" stage to a folder named /frontend-app/mywebsite in the final stage.

EXPOSE 80

This container listens on port 80

ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]

Specifies the script that must run every time the container starts up.

If you didn't use multi-stage builds, your final image would include all of Node.js, your source code, and thousands of dev dependencies, making it heavier. By using this method, your final image only contains Nginx and your static files, this make your final build lighter.

Now let’s build an image and then run it to check if it’s working fine or not.

In the terminal, go to your frontend directory and run the build command

docker build -t my-frontend-todo-app-multistage:v1 .

It's build successfully

We build it successfully. Now let’s run it.

Note: Before running the container. Please stop the already running container on port 8080.

docker run -d --env-file ./.env -p 8080:80 --name todo-app-multistage-container my-frontend-todo-app-multistage:v1

Our container is running now

Now go to the browser and open the URL http://localhost:8080

Hurray, it’s working fine. Make sure your backend server is running.

Now, let’s check the size of our image. Go to the terminal and run

docker images

See the image size now, from 281 MB to 13.4 MB. Now our image is ready for prod usage.

We're done with our image optimization. Is it ready for production environments? Not yet, we need to secure it as well. We will discuss it in the upcoming section.

11. Securing Frontend Docker Container: Restricting folder permissions and user access.

Right now, our container is running as a root user. This is not recommended in a production environment. If an attacker manages to get the access of our server. Then they can take over the entire server. Which is soo scary.

To completely secure our container, we need to run it using the least privileged user. This ensures that even if an attacker gains access to the container, they cannot execute malicious code or alter server permissions. They are effectively locked down and stripped of the authority to compromise the system.

So, before we proceed, we need to understand how Linux file permissions work.

1. The Three Security Scopes (The "Who")

Prefer Video? Watch Here

Every file and directory in Linux evaluates access requests sequentially against three distinct user scopes:

Owner (u): The system administrator who created the resource (usually root in a container).
Group (g): The specific service account or application tier assigned to the resource (e.g., sudo group).
Others (o): Unauthenticated entities or unrelated system users. All the other users.

When you issue a command like chmod 750, you are passing a three-digit configuration payload. The first digit applies to the Owner, the second to the Group, and the third to Others.

2. The Binary Breakdown: Read, Write, and Execute

Linux permissions do not use complex configuration files. They are based entirely on three simple actions, mapped to a 3-bit binary system where 1 is ON (allowed) and 0 is OFF (denied).

Here are the only three actions a user can take:

Read: You can view the text inside a file, or see the list of files inside a folder.
Write: You can edit, modify, or delete a file.
Execute: You can run a file as a script or program. (Crucial gotcha: For **folders, Execute simply means the ability to open or "enter" the folder).

Each of these three actions is assigned to a specific slot in a 3-bit binary number. When you convert that binary sequence into standard decimal numbers, you get the magic numbers used in chmod:

Read is the first slot (1 0 0 in binary), which equals 4.
Write is the middle slot (0 1 0 in binary), which equals 2.
Execute is the last slot (0 0 1 in binary), which equals 1.

To give a user a combination of permissions, you simply turn on the binary bits you want, which adds the numbers together.

For example: If you want a user to be able to Read and Execute, but not Write, the binary is 1 0 1. If you add the standard numbers together (4 + 0 + 1), you get 5. If you want them to have all three powers (1 1 1), it is 4 + 2 + 1 = 7.

3. The Practical Implementation (`chmod 750`)

Prefer Video? Watch Here

We achieve this with the matrix 750:

Owner gets 7 (4 + 2 + 1): The binary flag is 111. Root has Read, Write, and Execute authority.
Group gets 5 (4 + 0 + 1): The binary flag is 101. Group users get Read and Execute authority, but Write (0) is strictly denied.
Others get 0: The binary flag is 000. A total block for other users.

I hope you get some understanding of Linux permissions from above. Let's see it in action

Right now, our Dockerfile runs as the root user.

To check it. Go inside the Docker container by using the docker exec command

For Mac

docker exec -it todo-app-multistage-container sh

For Windows, run the command

winpty docker exec -it todo-app-multistage-container sh

Once you're inside the container, run the whoami command

whoami

You will see the root

Like this

Now go inside the frontend-app directory.

cd /frontend-app

Check the list of files in /frontend-app by running the ls command.

ls

You will see a list of files as shown in the image below

Now, let's try to simulate the same behaviour. If our server gets hacked by someone. What can an attacker do if he can get the root access?

He might delete the mywebsite folder. Then our website crashed immediately. Because it contains all the static files.

Let's see what happened if we delete the mywebsite folder.

Inside the frontend-app, run the following command

rm -rf mywebsite/

This command deletes the whole mywebsite folder.

Now, if you run the ls command, you will not be able to see the mywebsite folder.

ls

Now go to our frontend URL http://localhost:8080.

You will see a 500 internal server error.

See our website broke now. So, for mitigating this issue. We
need to run our container with the least privileged user. So no one can delete or interrupt our resources on the server.

How can we do it 🤔?

So, to lock down our Dockerfile. Need to do the following tasks:

Creating a group, e.g. frontend_group.
Creating a user, e.g. frontend_user, and adding it to the frontend_group.
Creating the necessary folders required for running nginx properly.
Then we need to set the owner for the folders. Which required protection.
Then we need to lock down our files and folders. And give the least privilege to the groups and users.

Now, let's do each step one by one

1. Creating a group, e.g. `frontend_group`

In your Docker file, after the last COPY command. Add the following command for creating the group

RUN addgroup -S frontend_group

Breakdown of the above command

RUN addgroup -S frontend_group

addgroup: This tells Linux to create a brand new group.

-S: This stands for "System." It tells Linux to make this a system group rather than a normal user group. System groups don't have passwords and are specifically designed for running background services (like Nginx or Node), which makes them much more secure.

2. Creating a user, e.g. `frontend_user`, and adding it to the `frontend_group`

After that, to create a user and add it to the group, add the following command after the above command

RUN adduser -S frontend_user -G frontend_group

Pro-Tip: The One-Liner Optimization (`&&`)

While writing those commands on two separate lines makes them easy to read, you will almost always see them combined in professional Dockerfiles like this:

RUN addgroup -S frontend_group && adduser -S frontend_user -G frontend_group

Why do we do this? Docker Layers.

Every time you write the word RUN in a Dockerfile, Docker creates a brand new "layer" (a snapshot) of your system.

Two RUN commands = Two layers added to your image.
One RUN command with && = One single layer.

By chaining related commands together with &&, you tell Docker to execute both actions simultaneously inside the exact same layer. This reduces your final image size, speeds up build times, and is the golden standard for production Dockerfiles!

3. Creating the folder required to run nginx properly.

We need to create the /run/nginx folder. Because
When Nginx boots up, the operating system assigns it a unique ID number. Nginx is hardcoded to instantly write this number into a file called nginx.pid.

By default, it tries to save this file in a locked, root-only system folder. Because we are securing our app by running as a non-root user, Nginx will instantly crash with a "Permission Denied" error. We pre-create the /run/nginx folder to give our app a dedicated, writeable sandbox just for this one file.

Add the mkdir command below after the above line

RUN mkdir -p /run/nginx

4. Setting the owners for the folders which required protection

For securing our frontend app. We need to provide protection mostly to the frontend-app and some nginx folders.

Then add the Run command

RUN chown -R root:frontend_group /frontend-app /etc/nginx /run/nginx /var/cache/nginx /var/log/nginx

RUN: Tells Docker to execute this command while building the image.
chown (Change Owner): This is the Linux command used to change who owns a file or folder.
-R (Recursive): Just like in our chmod commands, this tells Linux to dive into the folders and apply this ownership to every single file and sub-folder hidden inside them.
root:frontend_group: This is the core logic. You are explicitly stating two things:
The Owner is root: The system administrator owns the files.
The Group is frontend_group: You are assigning these files to your application's service group.

Why do it this way? By making the root owner, you permanently prevent the frontend_user from ever running a chmod command to change permissions later.

The Folders (Why these specific five?)

When you run Nginx as a standard, non-root user (like frontend_user), you have to manually grant it access to the specific folders it relies on to function. If Nginx cannot read or write to these native Linux folders, the container will instantly crash with a "Permission Denied" error on startup.

Here is exactly what Nginx is doing in each of those directories:

/frontend-app
- What it is: Your custom directory containing your compiled React/Vite build (the dist folder).
- Why it needs it: Nginx needs permission to open this folder to serve your HTML, CSS, and JS files to the user's browser.
/etc/nginx
- What it is: The default Linux directory for Nginx configuration files (like nginx.conf and your custom server blocks).
- Why it needs it: Nginx has to read these rules to know how to route traffic, handle API proxies, and serve your application.
/run/nginx
- What it is: A temporary system folder used to store the PID (Process ID) file.
- Why it needs it: When Nginx starts, Linux assigns it a unique ID number and writes that number to a file (e.g., nginx.pid). If Nginx cannot create this file, it refuses to start.
/var/cache/nginx
- What it is: The storage location for temporary files and cached data.
- Why it needs it: When Nginx processes large client requests, handles fastCGI, or acts as a proxy, it buffers that data into temporary files. It needs strict Write access here to function efficiently.
/var/log/nginx
- What it is: The official directory for access.log (who visited your site) and error.log (what broke).
- Why it needs it: Nginx constantly streams data to these files while running. If it cannot write to the log folder, it will crash.

As we created a directory /run/nginx. For nginx to write its PID (Process ID).

By default, Nginx is hardcoded to write this file into a strict, root-only system folder. Because we are forcing Nginx to run as our non-root frontend_user, it will instantly crash with a "Permission Denied" error when it tries to write that PID file.

To fix this, we use a single command to rewrite the Nginx configuration file and point the PID to the /run/nginx folder we explicitly unlocked in the previous step.

# Update the PID path in the nginx config
 RUN sed -i 's|.*nginx.pid;|pid /run/nginx/nginx.pid;|g' /etc/nginx/nginx.conf

This line changes the nginx internal configuration command. It changes the default path from nginx.pid to /run/nginx/nginx.pid.

5. Locking down our files and folders. And give the least privilege to the groups and users.

We have already seen the five folders above. We need to lock some files and folders among them.

For our two core directories—/frontend-app (our code) and /etc/nginx (our config)—we give root full control. However, we restrict our frontend_group to only Read and Execute permissions. This allows Nginx to open the folders and serve the website perfectly, but physically prevents it from modifying, overwriting, or deleting any core files.

For locking down our core folder, use the chmod command

RUN chmod -R 750 /frontend-app /etc/nginx

For our main application code, we used 750 to strictly block write access. However, Nginx physically must be able to write to its cache, logs, and PID directories to function.

We unlock these specific, isolated sandbox folders using the 770 lock code.

# Grant Write access to the isolated Nginx runtime folders
RUN chmod -R 770 /run/nginx /var/cache/nginx /var/log/nginx

-R (Recursive): Apply this permission to the folders and everything inside them.
770 (The Access Matrix):
- Owner gets 7 (4 + 2 + 1): root retains full control.
- Group gets 7 (4 + 2 + 1): Our frontend_group (Nginx) is granted Read, Write, and Execute powers. This is the crucial difference. We are explicitly allowing Nginx to generate and delete files inside these sandboxed directories.
- Others get 0: Unauthenticated users are completely blocked.

By specifically targeting only these runtime directories with 770, we give Nginx exactly the Write permissions it needs to survive, without exposing our core application code to dangerous modifications!

That's it. Now let's switch from root to frontend_user.

Add the below command just before the expose command

USER frontend_user

After all the above changes, your Dockerfile looks like

FROM node:lts-alpine3.22 AS build
WORKDIR /frontend-app
RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=package-lock.json,target=package-lock.json \
    --mount=type=cache,target=/root/.npm \
    npm ci

# Copy the rest of the source files into the image.

COPY . .

# Run the build script.

RUN npm run build

FROM nginx:stable-alpine-slim AS final


COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh
RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh && \
chmod +x /frontend-app/nginx-entrypoint.sh

# Copy the production dependencies from the build stage
COPY --from=build /frontend-app/nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /frontend-app/dist /frontend-app/mywebsite
RUN addgroup -S frontend_group && adduser -S frontend_user -G frontend_group
RUN mkdir -p /run/nginx
# # 1. Set root as the owner and frontend_group as the group for ALL folders.
# # Because root owns them, frontend_user is permanently blocked from using chmod.
RUN chown -R root:frontend_group /frontend-app /etc/nginx /run/nginx /var/cache/nginx /var/log/nginx
# # 2. Update the PID path in the nginx config
RUN sed -i 's|.*nginx.pid;|pid /run/nginx/nginx.pid;|g' /etc/nginx/nginx.conf
# # 3. Lock down the app and config folders to Read/Execute (750).
# # Owner (root): Read/write/Execute (7)
# # Group (frontend_group): Read/Execute (5)
# # Others: No Access (0)
RUN chmod -R 750 /frontend-app /etc/nginx
# # 4. Grant Write access to the specific runtime folders Nginx needs to function and env creation folder (770).
# # Owner (root): Read/Write/Execute (7)
# # Group (frontend_group): Read/Write/Execute (7)
# # Others: No Access (0)
RUN chmod -R 770 /run/nginx /var/cache/nginx /var/log/nginx
USER frontend_user

# Expose the port that the application listens on.
EXPOSE 80
ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]

Now, let's build our Docker image and then run it

For building run inside the frontend directory

docker build -t my-frontend-secure-todo-multistage:v1 .

Now, let's run our container. But before that, please delete your older frontend container that we created previously.

Then run

docker run -it --env-file ./.env -p 8080:80 --name todo-app-multistage-secure-container my-frontend-secure-todo-multistage:v1

After running the above command, it runs successfully

Now go to our frontend app and refresh it, or open the URL
http://localhost:8080

We are not able to see any todos in our app. Check if your backend server is still running. In my case, it's running. Also, our frontend again starts calling the undefined URL. This means we again messed up with env variables. But where 🤔?

Check the nginx logs in the terminal where you run the docker run command. If you check the starting logs. You will see some Permission Denied errors.

What's the issue here?

If you remember, for injecting the runtime environment. We are creating a /env-config.js. On the startup of our container inside the directory /frontend-app/mywebsite.

So when we start our container with frontend_user. It had only read and execute permission for the directory /frontend-app/mywebsite. But here we are trying to create a new file inside the /frontend-app/mywebsite. Due to a lack of write permission, the creation of the /env-config.js file failed. And in the terminal, it's showing a permission denied error. How can we fix it?

I still don't want to give write permission to frontend_user for /frontend-app/mywebsite directory. Otherwise, we again get into trouble.

But I can create one directory inside the /frontend-app/mywebsite. Specially for creating the/env-config.js file. And permit write permission only for that particular directory instead of the whole /frontend-app/mywebsite directory.

So we create a /env directory inside the /frontend-app/mywebsite directory. And then give write permission to our frontend_user.

For creating /env, add the mkdir command. Just after this line RUN mkdir -p /run/nginx

RUN mkdir -p /frontend-app/mywebsite/env

Now, to give write permission, just add the above directory at the end of the command.

Add /frontend-app/mywebsite/env at the end of the chmod command like this

RUN chmod -R 770 /run/nginx /var/cache/nginx /var/log/nginx /frontend-app/mywebsite/env

There is one more problem we need to address

The Port 80 Problem: Privileged vs. Unprivileged Ports

If you try to run your secure, non-root Nginx container on standard HTTP Port 80, it will immediately crash. But why?

In Linux, network ports are divided into two strict categories:

Privileged Ports (0 to 1023): These include core internet protocols like HTTP (80), HTTPS (443), and SSH (22).
Unprivileged Ports (1024 to 65535): These are open for general application use.

Historically, Linux restricted ports under 1024 as a security measure. It guaranteed users that if a website was running on Port 80, it was officially set up by the system administrator (root), not a random user running a rogue script.

Because we intentionally stripped away our administrative powers by using USER frontend_user, Linux mathematically prevents our application from binding to Port 80.

The Solution: Instead of fighting Linux security, we follow the industry standard: we tell Nginx to run on an unprivileged port, like 8080.

So, in your Dockerfile, change EXPOSE 80 to EXPOSE 8080.

Finally, after all changes, your Dockerfile looks like

# FROM node:lts-alpine3.22

# # Install nginx on Apline Linux
# RUN apk add --no-cache nginx

# WORKDIR /frontend-app

# COPY package*.json ./
# RUN npm ci

# COPY . .

# # Build arguments for environment variables
# # ARG VITE_API_URL
# # ENV VITE_API_URL=$VITE_API_URL

# RUN npm run build

# # Ensure nginx directories exist
# RUN mkdir -p /frontend-app/mywebsite
# COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh
# RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh
# RUN chmod +x /frontend-app/nginx-entrypoint.sh

# # Copy nginx config

# COPY nginx.conf /etc/nginx/http.d/default.conf


# # Move dist files
# RUN cp -r ./dist/* /frontend-app/mywebsite/

# EXPOSE 80
# # CMD ["nginx", "-g", "daemon off;"]
# ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]


FROM node:lts-alpine3.22 AS build
WORKDIR /frontend-app
RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=package-lock.json,target=package-lock.json \
    --mount=type=cache,target=/root/.npm \
    npm ci

# Copy the rest of the source files into the image.

COPY . .

# Run the build script.

RUN npm run build

FROM nginx:stable-alpine-slim AS final


COPY nginx-entrypoint.sh /frontend-app/nginx-entrypoint.sh
RUN sed -i 's/\r$//' /frontend-app/nginx-entrypoint.sh && \
chmod +x /frontend-app/nginx-entrypoint.sh

# Copy the production dependencies from the build stage
COPY --from=build /frontend-app/nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /frontend-app/dist /frontend-app/mywebsite
RUN addgroup -S frontend_group && adduser -S frontend_user -G frontend_group
RUN mkdir -p /run/nginx
RUN mkdir -p /frontend-app/mywebsite/env
# 1. Set root as the owner and frontend_group as the group for ALL folders.
# Because root owns them, frontend_user is permanently blocked from using chmod.
RUN chown -R root:frontend_group /frontend-app /etc/nginx /run/nginx /var/cache/nginx /var/log/nginx
# 2. Update the PID path in the nginx config
RUN sed -i 's|.*nginx.pid;|pid /run/nginx/nginx.pid;|g' /etc/nginx/nginx.conf
# 3. Lock down the app and config folders to Read/Execute (750).
# Owner (root): Read/write/Execute (7)
# Group (frontend_group): Read/Execute (5)
# Others: No Access (0)
RUN chmod -R 750 /frontend-app /etc/nginx
# 4. Grant Write access to the specific runtime folders Nginx needs to function and env creation folder (770).
# Owner (root): Read/Write/Execute (7)
# Group (frontend_group): Read/Write/Execute (7)
# Others: No Access (0)
RUN chmod -R 770 /run/nginx /var/cache/nginx /var/log/nginx /frontend-app/mywebsite/env
USER frontend_user

# Expose the port that the application listens on.
EXPOSE 8080
ENTRYPOINT ["/frontend-app/nginx-entrypoint.sh"]

Also, update your nginx.conf file. With the following changes
change these two lines:

From listen 80; to listen 8080;
From listen [::]:80; to listen [::]:8080;

Finally, your nginx.cong. Files look like

   server{
    listen 8080;          # Listen for IPv4
    listen [::]:8080;     # Listen for IPv6
    server_name localhost;

    root /frontend-app/mywebsite;
    index index.html;


    location / {
        try_files $uri /index.html;
    }
    }

Also, update the new env path in nginx-entrypoint.sh.

Update the CONFIG_PATH from /frontend-app/mywebsite/env-config.js to /frontend-app/mywebsite/env/env-config.js

After the change, your final nginx-entrypoint.sh file looks like

   #!/bin/sh

# Start the generated config file
CONFIG_PATH="/frontend-app/mywebsite/env/env-config.js"
echo "window.env = {" > $CONFIG_PATH

# Find all environment variables starting with "VITE_" and add them to the file
for var in $(env | grep "VITE_"); do
  name=$(echo "$var" | cut -d "=" -f 1)
  value=$(echo "$var" | cut -d "=" -f 2-)
  echo "  $name: \"$value\"," >> $CONFIG_PATH
done

# End the config file
echo "};" >> $CONFIG_PATH
echo "Environment variable injection completed."
exec nginx -g 'daemon off;'

Also, change the src path in our index.html file.

From <script async src="/env-config.js"></script> to
<script async src="/env/env-config.js"></script>

After the above changes, your index.html file looks like

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script async src="/env/env-config.js"></script>
    <title>Vite + React + TS</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

We're done with all the changes. Now, let's build it again and run it to check if everything is working or not

For building run docker build inside the frontend directory

docker build -t my-frontend-secure-todo-multistage:v2 .

It build successfully

Now start the container. But please delete the older container that we created previously.

Then run the docker run command

docker run -it --env-file ./.env -p 8080:8080 --name todo-app-multistage-secure-container my-frontend-secure-todo-multistage:v2

Our container started without any Permission denied error.

Now go to the URL http://localhost:8080. And check now we getting todos or not?

Hurray, it's working 😎

Now let's check if our app is still secure or not. Now we again try to perform the same scenario that we performed previously. We try to delete some files inside the mywebsite folder.

To go inside the container, run the docker exec command

docker exec -it todo-app-multistage-secure-container sh

For Windows run

winpty docker exec -it todo-app-multistage-secure-container sh

Once you're inside the container

Run the whoami command, and you will see frontend_user after running it.

whoami

You will see

Now go to the /frontend-app/mywebsite directory. And try to delete the index.html file. You will see a permission denied error. frontend_user is not able to delete the index.html file.

Run the cd command to go inside the /frontend-app/mywebsitedirectory.

cd /frontend-app/mywebsite

Then run the rm -rf command for deleting the index.html file.

rm -rf index.html

You will see a permission denied error

See our frontend_user working fine, it's unable to delete any files inside the frontend-app. But still it can delete /env/env-config.js file because it had write access for the /env directory. You can try deleting on your end.

So we secured our website from being deleted. Now the hacker is not able to delete our website, at least.

So finally we've done it. And we successfully created our production-ready frontend Dockerfile. Now you can use the same template for any frontend project which mostly based on CSR.

That's all for this blog post. We're done with our blog post. If you want to check out the bonus section. Go and check it for extra knowledge.

And if you follow along till here, pat your back. You did a great job.

12. Bonus: Extra observation on nginx.

Prefer Video? Watch Here

Note:

The core tutorial concludes here. The following section covers some extra observations of mine on nginx. It is strictly optional—feel free to skip it, or read on to understand the underlying mechanics.

If you noticed or not. The path to default.conf in the Dockerfile changes depending on the image.

In the following Dockerfile, we used a different path to replace the existing default.conf with our custom nginx.conf file.

In node:lts image there we used the path /etc/nginx/sites-available/default

The line we used in our Dockerfile COPY nginx.conf /etc/nginx/sites-available/default

In node:lts-alpine3.22 we used /etc/nginx/http.d/nginx.conf

In the final Stage of the multistage Dockerfile for the image nginx:stable-alpine-slim.
We used path /etc/nginx/conf.d/default.conf

Every time default.conf file path location changes on each Docker file. Why? Because each Linux distro uses a different location for niginx configuration files.

How to know about these paths?

To check it if you're not sure about the path.

Just install nginx and run the container with the default configuration. Now go inside the container via the exec command. And then run the nginx -t command. It will give you the location of the main nginx configuration file. Now run the cat command to check the content of nginx.conf main file content.

Let’s do this as well. Do it in our running container. We just ran the container for our final build

Run command

docker exec -it todo-app-multistage-container /bin/sh

It will connect your terminal to the container. Once you are inside your container. Run below command

niginx -t

Copy the highlighted path and run the command

cat /etc/nginx/nginx.conf

Are you able to see the content of niginx.conf file. In that file, check for an include statement. It will denote the path where you can put your site config files.

That’s it.

13. Wrap Up:

We're done with our frontend Docker image part. We have seen all the aspects of building images. Now you can also optimize our prod build further by using distroless images. And learn about it more. Stay tuned for the next post, where we will containerize our backend and integrate a MySQL database.

How to Containerize a Full-Stack App (Part 3)-Containerizing the Backend and Mysql Database Integration

utkarsh srivastava — Sun, 01 Nov 2026 05:54:15 +0000

Series Navigation:

✅ Part 1: Setting Up Locally (Required)

✅ Part 2: Frontend Multi-Stage Docker Builds (Optional for this guide)

📍 Part 3: Containerizing the Backend & MySQL (You are here)

This is Part 3 of our series. If you haven't set up the local Full-Stack Todo app yet, check out Part 1 Setting Up Locally to get your environment ready.
If you do not containerize the frontend app, check out Part 2 Frontend Multi-Stage Docker Builds.

If you want to skip both, follow TL;DR: Fast-Track Setup section.

TL;DR: Fast-Track Setup

⚠️ Prerequisite: Before starting this step, you must have Docker Desktop and Node.js installed and running on your machine.

If you didn't follow along with the previous posts or simply want to skip the manual local setup, you can easily catch up. Grab the existing code from the repository and spin it up using Docker to jump right into the rest of the content.

1. Clone the repository and checkout the part-2-frontend branch:

Check out the repo link

git clone https://github.com/utkarsh4321/devops-todo-starter-app.git
cd devops-todo-starter-app
git checkout part-2-frontend
cd frontend

2. Build the Docker image:

docker build -t my-frontend-secure-todo-multistage:v2 .

3. Run the container:

docker run -it --env-file ./.env -p 8080:8080 --name todo-app-multistage-secure-container my-frontend-secure-todo-multistage:v2

Once your container is up and running on port 8080, validate frontend in the browser.

4. Set up MySQL container:
In the terminal run

docker run --name mysql-container \
  -e MYSQL_ROOT_PASSWORD=myrootpassword \
  -e MYSQL_DATABASE=my_testing_db \
  -p 3306:3306 \
  -d mysql:8.0

5. Set up backend environment:
Inside the backend folder, create a .env file. Copy the environment variables from below and paste them

DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=my_testing_db
DB_USERNAME=root
DB_PASSWORD=myrootpassword
ALLOWED_ORIGIN=http://localhost:8080

6. Run the backend:
Open a new terminal and run

cd backend
npm i
npm run migrate
npm run dev

Once your backend is up and running on port 5500, you are completely caught up! Let's continue with the rest of the blog post.

Intro

In Part 3, we will guide you on how to containerize our Backend application with a MySQL database.

If you are a backend developer and only want to know how to Dockerize backend, this section is very important.

Here is what we will cover:

Backend Code Walkthrough: A brief overview of our Backend app structure.
Generating the Production Build: How to prepare the app for deployment.
Deployment Architecture: High-level view of our deployment
Writing multistage dockerfile for our backend: Writing the step-by-step build instructions.
Building Docker Image: Building Docker Image and Running it.
Persisting MySQL Data in Docker Containers: Secure your MySQL data against container destruction.
Isolating Services with Docker Networks: Use custom internal networks to securely connect your backend to MySQL.
Automating with Docker Compose: Spin up your complete architecture, including networks and volumes, with just one command.
Bonus Section: Add a React frontend to complete your stack.
Wrap Up

1. Backend Code Walkthrough: A brief overview of our Backend app structure.

Prefer Video? Watch Here

Our Backend Tech stack is:

Express js
Drizzle ORM
Esbuild as a bundler
Mysql DB

Our backend file structure looks like

backend/
├── drizzle/   
├── node_modules/
├── routes/
├── .env
├── .env-example
├── .gitignore
├── db.js
├── drizzle.config.js
├── esbuild.config.js
├── index.js
├── migrate.js
├── package-lock.json
├── package.json
└── schema.js

Explanation of each files and folders

drizzle/: Stores database migration files and snapshots generated by Drizzle ORM to track schema changes.
node_modules/: Contains all the installed third-party libraries and dependencies required for the project to run.
routes/: Define routes for the todos endpoint.
db.js: likely the setup file that initializes and exports the connection to our database.
drizzle.config.js: The configuration file for Drizzle Kit, telling it where to find your schema and where to output migrations.
index.js: The entry point for our backend.
migrate.js: A custom script to run migrations. With some dummy-seeded todos.
package-lock.json: Locks down the exact versions of your dependencies.
package.json: The project manifest.
schema.js: Defines your database tables and columns using Drizzle syntax.
esbuild.config.js: Configuration for esbuild. Using this to bundle your backend code for deployment or to transpile TypeScript/modern JS.

2. Generating the Production Build: How to prepare the app for deployment.

Prefer Video? Watch Here

Our backend project required the following steps for deployment

Database migration
Build creation
Securely providing env variables
A health check that ensures that the DB and backend are running successfully.

The 3rd and 4th points we see later. For 1st and 2nd points, we need to check our package.json file.

Our package.json looks like

In the script section, we need to focus on these commands:

generate: Script used to generate DB migrations.
migrate: Script used to run migration on the database.
build: Script used to create a bundle.

Note: Whenever the backend container starts, we need to run our migration on the DB first. Then our backend will run. Otherwise, our backend gives an error.

We already ran the npm run migrate command. Now, let's see how to build our backend application.

Go to the backend directory and then run

npm run build

Once you run the above command. It will create a dist directory inside the backend folder. This is our backend bundled code that we need for production.

3. Deployment Architecture:High-level view of our deployment

Prefer Video? Watch Here

Let’s Understand High-Level View

At the end of the blog post, we will achieve the architecture described above.

Here we need two containers, one for our MySQL DB and another for our Backend service.

Generally in prod. We expose our backend api’s but not the DB. DB is present inside the secure network that can only be accessed via our backend service.

4. Writing multistage dockerfile for our backend: Writing the step-by-step build instructions.

Prefer Video? Watch Here

We are directly creating a multistage Docker file for our backend.

Create a Dockerfile inside the backend folder.

Then, copy and paste the code snippet into the Dockerfile

FROM node:lts-alpine3.22 AS base
WORKDIR /app

# 2. Deps Stage: Install ONLY production dependencies
FROM base AS deps
# Use cache mount to install fast and keep image clean
RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=package-lock.json,target=package-lock.json \
    --mount=type=cache,target=/root/.npm \
    npm ci --omit=dev

# 3. Builder Stage: Install ALL deps and build
FROM base AS builder
RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=package-lock.json,target=package-lock.json \
    --mount=type=cache,target=/root/.npm \
    npm ci
# COPY source code AFTER installing deps to preserve cache
COPY . .
RUN npm run build

# 4. Final Stage: The Production Runner
FROM base AS runner
WORKDIR /backend-app
ENV NODE_ENV=production

RUN addgroup -S backend_group && adduser -S backend_user -G backend_group

# Copy the entrypoint script
COPY docker-entrypoint.sh /backend-app/docker-entrypoint.sh
RUN sed -i 's/\r$//' /backend-app/docker-entrypoint.sh
# Copy necessary files from previous stages
COPY --from=deps /app/node_modules /backend-app/node_modules
COPY --from=builder /app/dist /backend-app

RUN chown -R root:backend_group /backend-app
RUN chmod -R 750 /backend-app

# Run as non-root user for security
USER backend_user


EXPOSE 5500
ENTRYPOINT ["/backend-app/docker-entrypoint.sh"]

Step-by-step explanation of Docker file

Base Stage
Establishes the common foundation for later stages.
- FROM node:lts-alpine3.22 AS base: Starts using a lightweight Alpine Linux image with Node.js installed. Name this stage "base".
- WORKDIR /app: Sets /app as the current working directory inside the image for future commands.
Deps Stage
Focuses solely on installing production dependencies accurately and quickly.
- FROM base AS deps: Starts a new temporary stage named "deps", inheriting from the "base" stage.
- RUN --mount=... npm ci --omit=dev: Installs only production dependencies defined in package-lock.json. It uses specialized Docker "mounts" to cache downloaded packages and temporarily read dependency files without copying them permanently inside the image.
Builder Stage
Used to compile the source code (e.g., TypeScript to JavaScript).
- FROM base AS builder: Starts another temporary stage named "builder" from the "base" stage.
- RUN --mount=... npm ci: Installs all dependencies, including development tools needed for building (like TypeScript), using caching for speed.
- COPY . .: Copies the actual application source code from your host machine into the container's /app folder.
- RUN npm run build: Executes the build script defined in your package.json to compile the code (usually outputting to a dist folder).
Final Stage (Runner)
Assembles the final, clean production image.
- FROM base AS runner: Starts the final stage from the fresh "base" image, leaving behind build tools from previous stages.
- WORKDIR /backend-app: Sets the default working directory inside the container where all subsequent commands will be executed and files will be placed.
- ENV NODE_ENV=production: Sets an environment variable to tell Node.js to run in optimized production mode.
- RUN addgroup -S backend_group && adduser -S backend_user -G backend_group: Creates a dedicated system group and user to run the application securely, avoiding the risks of using the default root user.
- COPY docker-entrypoint.sh /backend-app/docker-entrypoint.sh: Copies a custom startup script from your project into the final image.
- RUN sed -i 's/\r$//' /backend-app/docker-entrypoint.sh: A handy quick-fix! It removes any hidden Windows line endings from your startup script so it runs flawlessly in our Linux environment.
- COPY --from=deps /app/node_modules /backend-app/node_modules: Copies the clean production-only dependencies from the "deps" stage.
- COPY --from=builder /app/dist /backend-app: Copies the compiled application files (the dist folder) from the "builder" stage.
- RUN chown -R root:backend_group /backend-app: Safely assigns ownership of your app files. The root user stays in charge, but our new backend group gets the access it needs.
- RUN chmod -R 750 /backend-app: Applies strict security permissions, giving the owner full control, the group read/execute rights, and blocks everyone else.
- USER backend_user: Switches from the default root user to the low-privilege "backend_user" user for enhanced security.
- EXPOSE 5500: Documents that the application inside the container listens on port 5500.
- ENTRYPOINT ["/backend-app/docker-entrypoint.sh"]: Specifies the command that runs immediately when the container starts.

We created our Docker file

Also, create docker-entrypoint.sh in the backend folder. This script file will apply migrations on the database and then run the backend server.

Copy and paste the given code snippet into the docker-entrypoint.sh

#!/bin/sh

set -e

# Run database migrations
echo "Running database migrations..."
npm run migrate


echo "Migrations completed."

# Start the Node.js application
echo "Starting Node.js application..."
node ./bundle.js

The `docker-entrypoint.sh` Script

To ensure our container starts correctly and handles database migrations, we use a startup script. Here is the breakdown:

#!/bin/sh: Interpreter Declaration

Tells the system to run this file using the standard, lightweight Shell (sh) interpreter.
set -e: Fail-Fast Mode

Configures the script to exit immediately if any command returns an error. This is a best practice that prevents the app from starting in a broken state if migrations fail.
npm run migrate: Execute Migrations

Runs the migration script defined in your package.json to update your database schema to the latest version before the app starts.
node ./bundle.js: Start Server

Executes the Node.js runtime on your compiled application file. This is the main process that keeps the container alive and serving requests.

Also, create a .dockerignore file as well inside the backend directory.

And add the following code snippet

**/.classpath
**/.dockerignore
**/.env
**/.git
**/.gitignore
**/.project
**/.settings
**/.toolstarget
**/.vs
**/.vscode
**/.next
**/.cache
**/*.*proj.user
**/*.dbmdl
**/*.jfm
**/charts
**/docker-compose*
**/compose.y*ml
**/Dockerfile*
**/node_modules
**/npm-debug.log
**/obj
**/secrets.dev.yaml
**/values.dev.yaml
**/build
**/dist
LICENSE
README.md
/*.yaml
/*.yml

5. Building Docker Image: Building a Docker Image and Running it.

Prefer Video? Watch Here

We're all set up, let’s build an image and then run our backend container. Make sure your MySQL container is already running.

Please start the MySQL container from Docker Desktop. If you have never created a MySQL container before. Please follow this section Setting up the Database from the Part-1

Once you set up the MySQL container. Go to the backend directory in the terminal and run the following command

docker build -t my-todo-backend-image:v1 .

Hope your Docker image got created. You can check inside the Docker Desktop, in the image section.

Now let’s run a new container for our todo backend in the same terminal, run the following command

Note: Before running any command, please stop your already running dev server for the backend if you previously started it. Otherwise, the port will be occupied. And we are not able to run our container.

docker run -it -p 5500:5500 --env-file ./.env --name my-todo-backend-container my-todo-backend-image:v1

Understanding the Command

When we spin up our backend, we use a single, powerful command. Here is exactly what is happening under the hood:

docker run -it -p 5500:5500 --env-file ./.env --name my-todo-backend-container my-todo-backend-image:v1

docker run: The core command that tells Docker to create and start a new container.
-it: A combination of -i (interactive) and -t (tty). This connects your terminal to the container, which is perfect for watching live logs or debugging.
-p 5500:5500: Port mapping (host_port:container_port). This binds port 5500 on your local machine to port 5500 inside the isolated container so you can access your API via localhost:5500.
--env-file ./.env: Security best practice! Instead of hardcoding secrets, this loads our environment variables (like database URIs or API keys) directly from our local .env file.
--name my-todo-backend-container: Assigns a readable, custom name to the container. If you skip this, Docker assigns a random, quirky name (like sleepy_einstein), making it harder to find later.
my-todo-backend-image:v1: The blueprint. This tells Docker exactly which image and version (v1 tag) to use to build the container.

Pro-tip: If you want this container to run quietly in the background without tying up your terminal, swap the -it flag for -d (detached mode)!

Once you run it, your container will crash. Oops, what happened this

If you follow the above instructions, you will be able to see the above error. After running the above command.

So what we did wrong. Why are we getting this error?🤔

If you see the error. We are getting this error from line no 10 inside the migrate.js file.

Let’s check our migrate.js file

In line no 10 we are calling mysql.createConnection. Ok, the issue is with the database connection.

Let’s check our .env file

The `localhost` Problem

The Setup: In our environment variables, we set DB_HOST to localhost.
Why it worked before: This setup works perfectly when running the backend directly on our local machine.
The Container Shift: Right now, however, we are running the backend inside an isolated Docker container.
The Core Issue: Inside this specific backend container, there is no MySQL server running on its internal localhost.
The Error: When the code runs, it searches the container's internal network for a database, comes up empty-handed, and throws an error.
The Reality: Our MySQL server is actually running inside a completely different container, outside of the backend container's environment.
The Question: So, how do we get these two separate containers to talk to each other? What is the solution?

We can fix this in two ways:

Either we pass the IP address of the container on which MySQL is running.
Or we use host.docker.internal as a special DNS name. This allows code running inside a container to talk to a service running directly on your computer (the host machine).

Let's see both ways one by one and then decide which is better

1. IP Address approach

So we need to get the IP address of the MySQL container

Run the following command to get the IP address of the MySQL container

Note: This approach works regardless of whether our database is exposed or not to our host machine.

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mysql-container

Breaking it down:

docker inspect: This command digs into Docker and returns a massive JSON object filled with low-level details about your container.
-f (or --format): Because the default output is hundreds of lines long, we use this flag to filter it. It uses Go templates to extract exactly what we are looking for.
'{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}': This is the Go template syntax. It tells Docker to look inside the NetworkSettings, loop through the attached Networks, and print out just the raw IPAddress string.
<container_name_or_id>: Replace this with the actual name or ID of your database container.

Once you run the above command, you will get the IP of mysql-container

Copy the IP from the terminal and change DB_HOST from localhost to <IP ADDRESS> in your .env file.

DB_CONNECTION=mysql
DB_HOST=172.17.0.2
DB_PORT=3306
DB_DATABASE=my_testing_db
DB_USERNAME=root
DB_PASSWORD=myrootpassword
ALLOWED_ORIGIN=http://localhost:8080

Once you update your' .env' file, try restarting the backend container with the docker run command.

Please delete the older container or change the name of the container in the command.

I already deleted the older container, so I'm running the command with the same container name.

docker run -it -p 5500:5500 --env-file ./.env --name my-todo-backend-container my-todo-backend-image:v1

🤞

Hurray, it's working now. If it successfully started, your terminal now looks like this

Now try out this URL http://localhost:5500/api/todos in your browser

You will see seeded todos in the response

Ok, we've seen the IP approach. But the IP address approach is not good because IP is Temporary. If your computer restarts Docker, assign a new IP address when the container restarts. That will crash our backend. So we go with the second approach.

2. Use of `host.docker.internal` as a special DNS name

Note: This approach only works if your container is exposed to the host machine; otherwise, this approach also does not work. We exposed the MySQL container to port 3306 on our host machine, so this approach works in our case.

First, check if MySQL is running or not. It is exposed to port 3306.

To check it. Go to Docker Desktop. And in your MySQL container row, check the Port column.

Go to your .env and replace the localhost value with our special DNS name.

Replace 172.17.0.2 with host.docker.internal

DB_CONNECTION=mysql
DB_HOST=host.docker.internal
DB_PORT=3306
DB_DATABASE=my_testing_db
DB_USERNAME=root
DB_PASSWORD=myrootpassword
ALLOWED_ORIGIN=http://localhost:8080

Now, before running our container again. Please delete the older backend container that we created; otherwise, Docker will throw an error. Or you can change the name of the Docker container in the command. I'm using the same container name.

Run Docker container via the following command

docker run -it -p 5500:5500 --env-file ./.env --name my-todo-backend-container my-todo-backend-image:v1

Open this link in your browser: http://localhost:5500/api/todos

You will see the same result as we got above. You will see dummy seeded todos.
Hurray, we're done with this approach as well.

But which approach do we choose for our production?

Because the first approach we discussed is not reliable. If the IP address of the container changes, our backend breaks.

Or if we go with the second approach, then we need to expose our database, then only. We can connect with the database. But in production, we will not expose our DB. It's run inside the container without exposing to the outer world.

Then what should we do now? 🤔

We will talk about it later. But before that, we need to resolve a very important problem that exists with our current setup.

That is a Data persistence issue. We will discuss it in the next section.

6. Persisting MySQL Data in Docker Containers: Secure your MySQL data against container destruction.

Prefer Video? Watch Here

By default, Docker containers are ephemeral or temporary.
If your MySQL container stops, updates, or gets removed, all the data inside it vanishes.

To make your database robust and production-ready, you must implement a reliable data persistence strategy.

We saw the theory above; now let's try it out.

If your frontend container is running, go to http://localhost:8080/

If you are not running a frontend container, you can also use Postman to create some dummy todos. By using the URL http://localhost:5500/api/todos.

I created two todos

Now we delete our MySQL container.

First, we need to stop the container and then delete it

To stop the container run

docker stop mysql-container

Note: Once the MySQL container stops. Your backend container also crashed and stopped due to a DB connectivity issue.

Now to delete the container run

docker rm mysql-container

Now we again create a new MySQL container.

Run command

docker run --name mysql-container \
  -e MYSQL_ROOT_PASSWORD=myrootpassword \
  -e MYSQL_DATABASE=my_testing_db \
  -p 3306:3306 \
  -d mysql:8.0

Once the MySQL container has started. Go to Docker Desktop and start your backend container as well.

Once the backend container starts. Go to your frontend in the browser, go to the URL http://localhost:8080/.

You will not be able to see the todos we created previously. Only dummy-seeded todos present that are generated on the startup of the backend container.

See our data lost due to the removal of our container. So how do we persist our data?

How can we make our MySQL data persistent?

Here Docker Named Volumes comes to rescue us to avoid this condition.

Think of a Named Volume like an external USB hard drive for your container.

Normally, a container is like a temporary sandbox—if you delete the container, everything inside the sandbox is permanently destroyed.

A Named Volume solves this by permitting Docker to create a special, safe folder on your actual computer. You "plug" this volume into your container. Now, whenever your database saves information, it gets written directly to that safe folder instead of the temporary sandbox.

If the container crashes or gets deleted, your data stays completely safe on your computer, ready to be plugged right back into a brand new container.

Now let's see this in action

First, things first, stop the MySQL container and delete it. Similarly to what we did above, or you can do it from Docker Desktop. I'm using Docker Desktop to delete it.

Once the MySQL container is deleted. Firstly, we need to create volume.

To create a volume run command

docker volume create mysql_db_data

Command Breakdown

This command tells Docker to set up a brand new, empty storage space on your host machine.

Here is the exact breakdown of what each word does:

docker: Calls the main Docker program.
volume: Tells Docker you want to interact with its storage management system.
create: The specific action you want to take (make a new one).
mysql_db_data: The custom name you are giving this specific volume so you can easily find it and attach it to containers later.

Analogy: This is like taking a brand new, blank USB flash drive and putting a sticker on it that says mysql_db_data so you know exactly what it's for.

Now run your MySQL container with the mount flag.

docker run --name mysql-container \
  -e MYSQL_ROOT_PASSWORD=myrootpassword \
  -e MYSQL_DATABASE=my_testing_db \
  -p 3306:3306 \
  --mount source=mysql_db_data,target=/var/lib/mysql \
  -d mysql:8.0

Volume Attachment Breakdown

--mount: The modern, more readable flag for attaching volumes.
source=mysql_db_data: Tells Docker to use the named volume you created previously.
target=/var/lib/mysql: The directory inside the MySQL container where the database actually writes its data.

Once your MySQL container has started. Now start your backend container as well.

Hope your frontend container is running. Go to your frontend at http://localhost:8080/.

And create some dummy todos again. I created two new todos. Which comes after our seeded todos?

So, to check whether the data persists or not. We need to remove the container. And again run the container with --mount flag.

I'm first stopping the MySQL container and then deleting it.
Running both commands together

docker stop mysql-container
docker rm mysql-container

Now again run the same command to run the MySQL container with the --mount flag.

docker run --name mysql-container \
  -e MYSQL_ROOT_PASSWORD=myrootpassword \
  -e MYSQL_DATABASE=my_testing_db \
  -p 3306:3306 \
  --mount source=mysql_db_data,target=/var/lib/mysql \
  -d mysql:8.0

Once the MySQL container has started. Start your backend container as well. Once your backend container has started.

Now go to your frontend. You will be able to see the todos we created previously are present.

We resolved the data persistence problem for our project.

Now we move back to our older problem.
For production, how can we connect our backend reliably with our MySQL database without exposing it outside?

Note: In production, we use Kubernetes to manage our containers.

But we are trying to simulate the same behaviour.

To solve our problem, we need to set up Custom Docker Networks. So that our backend can talk securely with the MySQL database.

7. Isolating Services with Docker Networks: Use custom internal networks to securely connect your backend to MySQL.

Prefer Video? Watch Here

By default, Docker containers cannot talk to each other easily.
However, when you place them on the same custom network, Docker provides an automatic internal DNS.
This allows your backend to talk to your database using the container's name, completely securely, without ever publishing ports to your host machine.

Step 1: Create a Custom Network

First, create an isolated internal network for your application services to share.

docker network create my-todo-network

Step 2: Start the MySQL Container (Securely) inside a custom network

Spin up your MySQL container. Notice that we omit the -p 3306:3306 flag here. We also attach it to the network using --network flag that we just created.

Note: I'm also changing container name of our mysql db container. Also please stop the mysql-container. Other wise this container will not start. We are trying to use same volume that's used by another container. We can use it only after stopping it.

docker run -d \
  --name mysql-secure-container \
  --network my-todo-network \
  -e MYSQL_ROOT_PASSWORD=myrootpassword \
  -e MYSQL_DATABASE=my_testing_db \
  --mount source=mysql_db_data,target=/var/lib/mysql \
  mysql:8.0

Because there is no -p flag, nothing on your host machine (or the internet) can access this database. It is entirely locked inside Docker's internal environment.

Step 3: Start Your Backend Container

We start our backend inside the same network where our Mysql Db present.

To securely connect with the MySQL database. We can use the database container's name as the host. So instead of using localhost or an IP address. We will use the database container's name that is mysql-secure-container as the host inside the .env file.

Go to the .env file and change the DB_HOST value from host.docker.internal to mysql-secure-container.

DB_CONNECTION=mysql
DB_HOST=mysql-secure-container
DB_PORT=3306
DB_DATABASE=my_testing_db
DB_USERNAME=root
DB_PASSWORD=myrootpassword
ALLOWED_ORIGIN=http://localhost:8080

Now start the backend container. But before starting it. Please delete the older backend container from Docker Desktop.

Once you have deleted the older backend container, run the following command

docker run -d \
  --name my-todo-backend-container \
  --network my-todo-network \
  --env-file ./.env \
  -p 5500:5500 \
  my-todo-backend-image:v1

Once your backend is up and running, check the URL http://localhost:5500/api/todos.

You will see previously created todos.

Also, go to your frontend and check whether it's working or not.

Hurray, we're done. We securely connected with the MySQL Database without exposing it. If you follow this blog till here, pat on the back.

Now what's next?

Let's recap what we've accomplished so far using the Docker CLI:

Built and Deployed: We successfully built our application images and manually ran both our backend and MySQL database containers.
Secured Data: We configured Docker Named Volumes to guarantee our database records persist, even if the container is destroyed.
Isolated Communication: We established a custom Docker network to ensure our services (frontend, backend, and database) can talk to each other securely without exposing sensitive ports to the host machine.

While this manual CLI approach gives you a great understanding of how Docker works under the hood, it introduces a massive margin for human error. If a single flag is missed, a port is mapped incorrectly, or a network name is misspelled in your terminal, the entire system breaks.

Right now, we are only managing three moving parts: a frontend, a backend, and a database. But imagine if you were working with a microservices architecture that had ten, twenty, or fifty distinct services. How could you possibly start, link, and manage them all by typing out docker build and docker run commands manually for every single service?

The short answer is: you wouldn't. In the next part of this series, we will look at how to solve this exact problem and automate our entire architecture using Docker Compose.

8. Automating with Docker Compose: Spin up your complete architecture, including networks and volumes, with just one command.

Prefer Video? Watch Here

Why Do We Need Docker Compose? (The Problem)

Imagine your full-stack web application relies on three distinct services to function:

Frontend: React
Backend: Node.js (Express)
Database: MySQL

Without Docker Compose, you are forced to type out long, error-prone commands in your terminal every single time you start your development environment:

# 1. Create the isolated network
docker network create my-net

# 2. Run the database container with volume mounts
docker run -d -p 5500:5500 --network my-net --name db mysql:8.0

# 3. Run the backend API container
docker run -d --network my-net --name backend my-node-app

# 4. Run the frontend container and map the public port
docker run -d -p 3000:80 --network my-net --name frontend my-react-app

If you forget a single environment flag, misconfigure a port, or mistype a network name, your services fail to communicate and your entire application breaks. Managing this manually becomes a nightmare as your architecture grows.

The Solution: What is Docker Compose?

Docker Compose is a tool that allows you to define and run multi-container Docker applications. Instead of memorizing and executing four different docker run commands every time you want to code, you define your entire infrastructure once inside a single blueprint file: docker-compose.yml (or compose.yaml).

By defining your architecture as code, you can launch your entire ecosystem—frontend, backend, and database—with just one simple command instead of juggling multiple complex terminal scripts:

docker compose up -d

Key Advantage: Automatic Networking 🌐

One of the best features of Docker Compose is that it handles all the networking for you automatically.

The moment you start your compose file, it instantly creates a private, secure network just for your application services.

Here is why that makes your life easier:

No More IP Addresses: You don't have to keep track of changing container IP addresses anymore.
Simple Hostnames: Your backend service can talk to your database securely using just the database's service name (the name you give it in your YAML file) as the hostname.

Docker completely handles all the complicated internal routing dynamically behind the scenes.

Let’s Write Our Docker Compose File

Navigate to your backend folder and create a file named compose.yml.

And then paste below code inside it


services:
  # Your Database Service
  my-todo-database:
    image: mysql:8.0.44 # or mysql
    restart: always
    environment:
      MYSQL_DATABASE: ${DB_DATABASE}
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      timeout: 20s
      retries: 10
    volumes:
      - mysql_db_data:/var/lib/mysql

  # Your App Service
  todo-backend:
    build: .
    restart: on-failure
    ports:
      - "5500:5500"
    env_file:
      - .env
    depends_on:
      my-todo-database:
        condition: service_healthy

volumes:
  mysql_db_data:
    external: true

Docker Compose Configuration Explained

This docker-compose.yml file sets up a robust, two-tier architecture consisting of a database and a backend application. Here is the line-by-line breakdown of what this configuration tells Docker to do.

The Services Block

services:
The root level of the Compose file. It defines all the different containers (services) that make up your application.

The `my-todo-database` Service

my-todo-database:
Names the first service. This name acts as the hostname on the internal Docker network (so the backend can connect to it using my-todo-database as the host).

image: mysql:8.0.44
Pulls the official MySQL image from Docker Hub, specifically version 8.0.44, instead of building it from a local Dockerfile.

restart: always
Tells Docker always to restart this container if it stops, crashes, or if the server itself reboots.

environment:
Begins the block for setting environment variables inside the MySQL container.

MYSQL_DATABASE: ${DB_DATABASE}
Creates a default database on startup. The value is dynamically injected from a variable named DB_DATABASE (usually found in an adjacent .env file).

MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
Sets the MySQL root user password, also securely injected from the DB_PASSWORD variable.

healthcheck:
Configures a test to determine if the container is actually ready to handle requests, not just running.

test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
The command Docker runs inside the container to check its health. Here, it pings the MySQL server to see if it is actively accepting connections.

timeout: 20s
If the mysqladmin ping command takes longer than 20 seconds to return a result, Docker considers that specific check a failure.

retries: 10
Docker will try the health check 10 times. If it fails 10 times consecutively, the container is officially marked as "unhealthy".

volumes:
Begins the block for mounting storage to the container.

- mysql_db_data:/var/lib/mysql
Maps a named Docker volume (mysql_db_data) to the path inside the container where MySQL stores its raw data (/var/lib/mysql). This ensures your database records survive even if the container is destroyed or recreated.

The `todo-backend` Service

todo-backend:
Name your application service.

build: .
Instead of pulling a pre-made image, this tells Docker to build a new image using the Dockerfile located in the current directory (.).

restart: on-failure
Unlike the database, this container will only restart if it exits with a non-zero exit code (indicating a crash or error). It won't restart if you intentionally stop it gracefully.

ports:
Begins the block for mapping network ports.

- "5500:5500"
Maps port 5500 on your host machine (your laptop or server) to port 5500 inside the container. This allows external traffic (like your browser or a frontend app) to reach your API.

env_file:
Begins the block for loading bulk environment variables.

- .env
Tells Compose to load all key-value pairs from a local .env file and inject them into the backend container.

depends_on:
Controls the startup order of your services.

my-todo-database:
Specifies that the backend relies on the my-todo-database service.

condition: service_healthy
This is the most crucial part of the file. It tells Docker Compose not to start the backend container until my-todo-database has successfully passed its healthcheck. This prevents your backend from crashing on startup due to trying to connect to a database that is still booting up.

The Volumes Block

volumes:
The top-level configuration for volumes used by the services above.

mysql_db_data:
Declares the volume name referenced by the database service.

external: true
Tells Docker Compose that this volume was created manually outside of this Compose file (e.g., a dev ran docker volume create mysql_db_data in the terminal). Also, compose, not try to create a new volume. It will use this volume.

Please stop all the previously running containers. Otherwise, port conflicts will occur except for the frontend container.

Running our Docker Compose

First, go to your backend .env file. And change the value of DB_HOST from mysql-secure-container to my-todo-database.

DB_CONNECTION=mysql
DB_HOST=my-todo-database <-- change this
DB_PORT=3306
DB_DATABASE=my_testing_db
DB_USERNAME=root
DB_PASSWORD=myrootpassword
ALLOWED_ORIGIN=http://localhost:8080

Then, in the terminal, go to the backend directory and run the Docker Compose command.

docker compose up

docker compose up reads your compose.yml file to automatically build, network, and start all your application's containers in the correct order.

Once you run this command, immediately go to Docker Desktop, and you will see MySQL started, but your backend app has not started yet.

But after some time, it automatically gets started. If no error occurs.

After some time, when you see something like below in your CLI, your backend has started successfully

If you see seeding data skipped. Why, because we are using our older volume that we created previously.

Once both the DB and backend container start, go to http://localhost:5500/api/todos, you will be able to see our previously created todos also present.

Also, check your frontend as well. By navigating to http://localhost:5500/api/todos

If you can see our previously created todos. We had done with this setup successfully. Hope you enjoyed it. You can learn more about Docker Compose. Now this blog post is over. If you are interested to setup frontend as well with Docker Compose, follow along with the blog.

9. Bonus Section: Add a React frontend to complete your stack.

Prefer Video? Watch Here

Go to compose.yml that we created previously. Here inside the service section. We just need to add our frontend service as well that's it.

after todo-backendservice paste following code snippet

 todo-frontend:
    build: ../frontend
    ports:
      - "8080:8080"
    env_file:
      - ../frontend/.env

Frontend Service

todo-frontend:
Names your frontend application service. This creates a dedicated container for your UI (like React or Vue) on the same Docker network.

build: ../frontend
Tells Docker to build the container image using the Dockerfile located in the frontend directory. This keeps your frontend build logic cleanly separated from your backend.

ports:
Begins the port mapping configuration.

- "8080:8080"
Maps port 8080 on your local machine to port 8080 inside the container. You will view your app by visiting http://localhost:8080 in your browser, while the internal web server (like Nginx) listens on the HTTP port 8080.

env_file:
Begins the block for injecting environment variables.

- ../frontend/.env
Loads UI-specific environment variables (like your backend API URL) from a dedicated .env file inside the frontend folder.

That's it now save the compose.yml file and run the docker compose command inside the backend directory.

After adding frontend service in your compose.yml. It's finally looks like

services:
  # Your Database Service
  my-todo-database:
    image: mysql:8.0.44 # or mysql
    restart: always
    environment:
      MYSQL_DATABASE: ${DB_DATABASE}
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      timeout: 20s
      retries: 10
    volumes:
      - mysql_db_data:/var/lib/mysql

  # Your App Service
  todo-backend:
    build: .
    restart: on-failure
    ports:
      - "5500:5500"
    env_file:
      - .env
    depends_on:
      my-todo-database:
        condition: service_healthy
  todo-frontend:
    build: ../frontend
    ports:
      - "8080:8080"
    env_file:
      - ../frontend/.env

volumes:
  mysql_db_data:
    external: true

Note: Hope you stopped all the previously running container.

Run docker compose command

docker compose up

Above command run by default in interactive mode. Which hijack your terminal. If you want to run your container in detach mode. you can use -d detached flag.

After running above command you will see all three services spin up. You can check in docker desktop.

Now also check your frontend by visiting http://localhost:8080/.Hope you're able to see our todos.

Our frontend is working fine. As expected.

10. Wrap Up:

We're done with our full-stack todo app deployment using Docker. If you follow along till here, give yourself a gift. Because you really did great work.

From here, you can learn more about Docker Compose. Or you can start learning about Kubernetes. And use this image to run inside the pod in Kubernetes. There is much more to explore.

If this helps you in any way. Please like and share your valuable comment with some love. Hope you like it👋.

How to Containerize a Full-Stack App (Part 1)-Setting Up the Local Development Environment.

utkarsh srivastava — Sat, 31 Oct 2026 01:29:40 +0000

Series Navigation:

📍 Part 1: Setting up locally (You are here)

➡️ Part 2: Frontend Multi-Stage Docker Builds

➡️ Part 3: Containerizing the Backend & MySQL

Prefer Video? Watch Here

In modern web development, Docker has become the standard for ensuring your application runs consistently across dev, test, and production environments. In this post, we are going to focus specifically on how to containerize a full-stack application built with React, Express.js, and MySQL.

In this tutorial, I will guide you through the end-to-end process of containerizing this stack. This is Part 1, so here we will just set up our full-stack app locally. In the upcoming blog post, I will explain the remaining details.

Here is what we will cover:

Prerequisites: Who is this for? (Frontend, Backend, and DevOps developers).
Setup: Installing Docker Desktop on our machine.
Setting up the Database: Setting up the Mysql Database.
The Baseline: Running our full-stack app locally before containerizing.
Conclusion: Summary and final thoughts.

Let’s get started.

1. Prerequisites

Before we dive in, let’s make sure this guide is right for you. This tutorial is designed to be flexible: whether you want to master the entire full-stack containerization process or need a solution for a specific part, you can leverage the sections that matter to you.

Who is this for?

Frontend Developers: You will learn how to serve your React app efficiently without relying on npm start in production.
Backend Developers: You will learn how to containerize your backend for production, ensuring your API and database run reliably together on any server.
DevOps Enthusiasts: You will gain hands-on experience packaging web applications and using Docker Compose to run them locally—the essential first step before managing them in a cloud environment.

⚠️ Important Note:
This guide is not for absolute beginners. We assume you already have a working knowledge of React and Node.js. I'm not covering how to write the application code itself, but rather how to package and ship it effectively.

What you need:

A basic understanding of React and Express.js.
Familiarity with the command line.
A code editor (VS Code recommended).

2. Setup: Installing Docker Desktop on our machine

To work with containers, we need the Docker engine running on our computer. The easiest and most standard way to do this is via Docker Desktop.

Download: Go to the official Docker website for Mac, for Windows, for Linux and download the installer for your OS (Windows, Mac, or Linux).
Install: Run the installer and follow the on-screen instructions.
Start the App: Once installed, open the "Docker Desktop" application. (Important: Docker commands won't work unless this app is running in the background!)
Verify: Open your terminal (or command prompt) and run the following command to make sure everything is connected:

docker --version
# Output Example: Docker version 29.0.1, build eedd969

If you see a version number, you are ready to go!

3.Setting up the Database

To run our backend, we need a MySQL database. Instead of installing the heavy MySQL server software directly on your OS, we will use Docker to spin up a MySQL container.

Run this command in your terminal:

docker run --name mysql-container \
  -e MYSQL_ROOT_PASSWORD=myrootpassword \
  -e MYSQL_DATABASE=my_testing_db \
  -p 3306:3306 \
  -d mysql:8.0

Now, go to Docker Desktop and verify that your MySQL container is running successfully

⚠️ Note:
Please save this password and db name as well because we need them later.
Also, if the above command failed. Then try with a different port number. For example, 3307.

docker run --name mysql-container \
-e MYSQL_ROOT_PASSWORD=myrootpassword \
-e MYSQL_DATABASE=my_testing_db \
-p 3306:3306 \
-d mysql:8.0

What Happens When You Run This Command

Docker downloads the mysql:8.0 image (if not present).
Creates a new container named mysql-container.
Starts the MySQL server inside it.
Initialises the database my_testing_db (first run only).
Sets the root user password to whatever you provided.
Exposes MySQL on your machine's port 3306.

docker run: Tells Docker to create and start a new container from a specified image.
--name mysql-container: Gives the container a custom name: mysql-container. So we can find it easily. If omitted, Docker assigns a random name.
-e MYSQL_ROOT_PASSWORD=myrootpassword: Sets the root password (we'll need this for our backend). The official MySQL image requires the MYSQL_ROOT_PASSWORD environment variable to be set.
-e MYSQL_DATABASE=my_testing_db: This will set the database with name my_testing_db. This env variable is optional. It creates a database on container creation.
-p 3306:3306: Exposes the database port so our local Node.js app can connect to it.
-d mysql:8.0: Image name.

4. The Baseline: Running our full-stack app locally before containerizing

Before we start writing Dockerfiles, we need to understand what we are actually containerizing. In this section, we will get the application running on our machine "the old-fashioned way" (mostly) to ensure the code works.

In this section, we will:

Fork and Clone the starter repository.
Set up the Database.
Run the Application to confirm that everything talks to each other.

4.1 Fork and Clone the Repository

I have prepared a starter repository that contains a basic React frontend and an Express backend.

Fork the repository to your own GitHub account.

Go to repo: Repo Link

Click on Fork

Once forked, clone it.

Clone it to your local machine:

# Clone the repository
git clone https://github.com/YOUR_GITHUB_USERNAME/devops-todo-starter-app.git

# Move into the project directory
cd devops-todo-starter-app

Once you cloned it, open it in VS Code or any IDE.

Note: There are three branches present for each blog post. Make sure you are in the main branch.

You will be able to see two folders: backend, frontend and a README.md file.

4.2 Running the Application

Now that our database is running, let's start the application. Go to your IDE where you open the project.

Go to the backend directory and create a file .env.

Copy content from .env-example. And paste it in .env.

Now replace DB_PASSWORD='<DB_PASSWORD>' with DB_PASSWORD=myrootpassword. And ALLOWED_ORIGIN=http://localhost:4501 with ALLOWED_ORIGIN=http://localhost:8080.

Before proceeding, make sure you are using Node.js version ">=20.0.0". Currently I'm using the LTS version, which is v24.13.0.

Open the terminal and run

node -v

Once you have a compatible node version, start the backend server.

Open a terminal and go to the **backend **directory

Install dependencies

cd backend
npm install

Run the migration

npm run migrate

Once migrated, you will see below the O/P

Run dev server

npm run dev

If everything goes fine, you will see below the O/P

Now, in the browser, open URL http://localhost:5500/api/todos

You will be able to see dummy todos in the browser

Open a new terminal and go to the frontend directory

Install dependencies

cd frontend
npm install

Setup Env Variable:

Go to the frontend directory and create a file .env.

Copy content from .env-example. And paste it in .env.

Start dev server

npm run dev

Open your browser to http://localhost:8080.

If you see data loading from the API, congratulations!🎉. Your baseline environment is set up perfectly.

5. Conclusion

I hope you successfully set up the app locally and enjoyed the process. In the next part, we will learn how to containerize our frontend. Stay tune. Please post your queries if you faced any issues.

My Bulletproof CSS Template for Perfect Text Wrapping

utkarsh srivastava — Mon, 08 Sep 2025 18:44:09 +0000

I recently cracked the code on a CSS template that flawlessly wraps long text into any number of lines without causing overflow. It's a game-changer for clean, responsive layouts, and I'm jotting it down here for future reference. This solution ensures that text stays contained and visually appealing, regardless of the container size or content length.

Refer to this sandbox link
Demo

Let'see

  <div class="container">
      <div class="card">
        <h4>A Big Paragraph</h4>
        <p>
          Lorem, ipsum dolor sit amet consectetur adipisicing elit. Impedit non
          repellendus error quod sunt maiores voluptatum rerum illum, sit neque?
          Lorem, ipsum dolor sit amet consectetur adipisicing elit. Temporibus
          ipsa tenetur nihil placeat soluta rerum fugiat, sequi saepe dolorem
          iste ut beatae quos! Maxime repudiandae dolor labore nulla! Modi
          adipisci est ex quaerat veritatis obcaecati illo unde nihil delectus.
        </p>
      </div>
      <div class="card">
        <h4>A long word without any space</h4>
        <p>  
jjjjjjjjjjjjjjjjdjdjdjdndndndndndjdjsaanansnsns@djejr12243nnfnfnfngn@nfgfgjrmrnn4jfmfnm$mbmbbjbmnfgnvmfmfmfm#kvkfmfmfmfm
        </p>
      </div>
    </div>

So the CSS for the card and container

.container {
  display: flex;
  flex-wrap: wrap;
  gap: 10px;
}
.card {
  box-shadow: 0 0px 5px rgba(0, 0, 0, 0.2);
  border-radius: 5px;
  padding: 0 20px;
  width: 40%;
}

It looks like

See how the long paragraph is growing in height. And our long word is going out of the card, which is disturbing our whole grid.

How to fix it? 🤔

Add this 🥷 Ninja Technique to p tag

p {
  overflow: hidden;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 2;
  text-overflow: ellipsis;
  overflow-wrap: anywhere;
}

-webkit-line-clamp, you can modify this value to adjust your wrapping to limit the number of lines shown. Any text that goes beyond this limit will be hidden. In my case, it goes up to line 2

overflow-wrap: anywhere; this we are using to handle long, big strings or words, like in our case. This property allows the browser to break words at any point to prevent overflow.

Boom see result

Give it a try.

Follow me for more tips like this 🙌

First timer open-source contribution

utkarsh srivastava — Mon, 09 Nov 2020 18:38:29 +0000

About me

My name is utkarsh Srivastava. You can call me ut. I m a front-end developer from India. A wish to make a little contribution in developer community brings me here. I always wish to participate in Hacktoberfest but some hurdles always stop me. But this time I hardly want to contribute in hacktoberfest. So finally I did it.

Background

My Hacktoberfest journey is wonderful. On the time of writing this article, I successfully completed my this year hacktoberfest.

Some steps that I took to complete this challenge

On the beginning of the October first, I went on hacktoberfest website hacktoberfest and signup for hacktoberfest 2020.
I don't have any idea at this point. So I start looking and reading the instructions in hacktoberfest website.
After that, I found some contribution website(where you can search for an open-source project and work on it).
So I found one i.e goodfirstissues.com.
I think this website is by Github I m not sure.
That's empowering first-timers contributors of open-source.
Then I select language in my case javascript to filter out projects.
Then I found beginners friendly projects and start working on the open-source projects.

Contributions

1.Meet-scheduler

This is an amazing Chrome extension that helps to manage google meet links.
I choose this project because I wanted to learn about how to develop a chrome extension. And the tech stack they use also matches my skills set.

2.Personal-dj

This is a personal-DJ website that helps us to create playlist directly in our Spotify account.
I choose this project because I always wanted to create online streaming type application.
So in order to take some idea. I choose this project because it is built with spotify API.

3.Shopyo

It's a point of sales software for small shops.
Build on python and flask
I choose this project to learn about flask.
But contributor told me to fix some small changes so I did that and they merge my PR.

4.Learn-opensource

It's basically a great contribution driven project which helps new developers to get familiar with open source.
I choose this project because it's built on javascript. And it's a little bit challenging to show different API's response into one page.
So I worked on issue page where I have to show all the open issues of their organization. So I added loader and after fetching data from GitHub API. I render it on that page.

Tips

One thing I notice whenever you start contributing to an open-source project. Please talk to repo owner as much as you can and try to understand their requirements what they really want.
And don't hesitate to ask because they are so helpful they will help you as much as they can. So please talk to them before you start working on it. It will save lots of time. So that you can easily submit 4 PR's.

Reflections

That's it, guys. This is all about my hacktoberfest journey. Overall experience is awesome. I have made new connections. Also, learn about so many interesting things. I enjoy this October like an open-source festival. Thanks to open-source community to help me and give me such a great experience. And I m surely participate again in hacktoberfest.

So thank you guys I hope it's helpful.

Connect with me:
Github
Linked-in

DEV Community: utkarsh srivastava

How to Containerize a Full-Stack App (Part 2)-Optimizing the Frontend with Multi-Stage Docker Builds.

Intro

1. Frontend Code Walkthrough: A brief overview of our React app structure.

2. Generating the Production Build: How to prepare the app for deployment.

3. Deployment Architecture: High-level view of our React app deployment.

4. From Source Code to Container: Visualizing the transformation process.

4.1 What is a Dockerfile?

5. Writing Our First Dockerfile: Writing the step-by-step build instructions

6. Creating nginx configuration file: Configuring nginx to serve our static files

What is .dockerignore?

7. Building Docker Image: Building Docker Image and Running it

8. Managing Environment Variables: Configuring API URLs and secrets securely.

1. Passing env variable during build time using build args:

2. Passing env variables at run-time by injecting them into the window object

9. Docker File optimization: Intro to Docker Image Optimization.

10. Multi-Stage Docker file: The professional way to shrink image size.

In the build stage

In Final stage or Prod Stage

Build Stage:

Final Stage:

11. Securing Frontend Docker Container: Restricting folder permissions and user access.

1. The Three Security Scopes (The "Who")

2. The Binary Breakdown: Read, Write, and Execute

3. The Practical Implementation (chmod 750)

1. Creating a group, e.g. frontend_group

2. Creating a user, e.g. frontend_user, and adding it to the frontend_group

Pro-Tip: The One-Liner Optimization (&&)

Why do we do this? Docker Layers.

3. Creating the folder required to run nginx properly.

4. Setting the owners for the folders which required protection

The Folders (Why these specific five?)

5. Locking down our files and folders. And give the least privilege to the groups and users.

12. Bonus: Extra observation on nginx.

13. Wrap Up:

How to Containerize a Full-Stack App (Part 3)-Containerizing the Backend and Mysql Database Integration

TL;DR: Fast-Track Setup

Intro

1. Backend Code Walkthrough: A brief overview of our Backend app structure.

2. Generating the Production Build: How to prepare the app for deployment.

3. Deployment Architecture:High-level view of our deployment

4. Writing multistage dockerfile for our backend: Writing the step-by-step build instructions.

Step-by-step explanation of Docker file

The docker-entrypoint.sh Script

5. Building Docker Image: Building a Docker Image and Running it.

Understanding the Command

The localhost Problem

1. IP Address approach

Breaking it down:

2. Use of host.docker.internal as a special DNS name

6. Persisting MySQL Data in Docker Containers: Secure your MySQL data against container destruction.

Command Breakdown

Volume Attachment Breakdown

7. Isolating Services with Docker Networks: Use custom internal networks to securely connect your backend to MySQL.

Step 1: Create a Custom Network

Step 2: Start the MySQL Container (Securely) inside a custom network

Step 3: Start Your Backend Container

8. Automating with Docker Compose: Spin up your complete architecture, including networks and volumes, with just one command.

Why Do We Need Docker Compose? (The Problem)

The Solution: What is Docker Compose?

Key Advantage: Automatic Networking 🌐

Let’s Write Our Docker Compose File

Docker Compose Configuration Explained

The Services Block

The my-todo-database Service

The todo-backend Service

The Volumes Block

Running our Docker Compose

9. Bonus Section: Add a React frontend to complete your stack.

Frontend Service

10. Wrap Up:

How to Containerize a Full-Stack App (Part 1)-Setting Up the Local Development Environment.

Prefer Video? Watch Here

1. Prerequisites

2. Setup: Installing Docker Desktop on our machine

3.Setting up the Database

4. The Baseline: Running our full-stack app locally before containerizing

4.1 Fork and Clone the Repository

4.2 Running the Application

5. Conclusion

3. The Practical Implementation (`chmod 750`)

1. Creating a group, e.g. `frontend_group`

2. Creating a user, e.g. `frontend_user`, and adding it to the `frontend_group`

Pro-Tip: The One-Liner Optimization (`&&`)

The `docker-entrypoint.sh` Script

The `localhost` Problem

2. Use of `host.docker.internal` as a special DNS name

The `my-todo-database` Service

The `todo-backend` Service