Beginner on Hoang Duong

Deploying Node.js with Docker + Nginx

Tue, 10 Feb 2026 00:00:00 +0000

Deploying Node.js with Docker + Nginx — Case Study

You’ve finished writing your API with Node.js, and it works perfectly on localhost. But when it comes to deploying on a real server, you face a bunch of questions:

How do I keep the app running stably and auto-restart on crash?
How do I prevent clients from accessing port 3000 directly?
How do I handle SSL, rate limiting, and static files?

The answer: Docker + Nginx reverse proxy. In this article, I’ll walk you through deploying a Node.js (Express) application from start to finish, using Docker for packaging and Nginx as a reverse proxy in front.

Architecture Overview

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Client (Browser / Mobile)
 │
 ▼
 ┌──────────┐
 │ Nginx │ ← Port 80/443 (HTTP/HTTPS)
 │ (proxy) │
 └────┬─────┘
 │ proxy_pass http://app:3000
 ▼
 ┌──────────┐
 │ Node.js │ ← Port 3000 (internal)
 │ (Express)│
 └──────────┘

Nginx sits in front, receives requests from clients, then forwards (proxies) them to Node.js running behind it. Clients never access Node.js directly.

Why do we need Nginx in front?

Reason	Explanation
Reverse proxy	Hides the app’s real port, clients only see port 80/443
Static files	Nginx serves static files (CSS, JS, images) much faster than Node.js
SSL termination	Nginx handles HTTPS, Node.js only receives plain HTTP
Rate limiting	Limits requests at the Nginx layer, protecting Node.js from being overloaded
Load balancing	When scaling multiple Node.js instances, Nginx distributes requests

Step 1: Create the Node.js Application (Express)

Project Structure

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


my-app/
├── src/
│ └── server.js
├── package.json
├── package-lock.json
├── Dockerfile
├── .dockerignore
├── nginx/
│ └── default.conf
└── docker-compose.yml

File `package.json`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "name": "my-app",
 "version": "1.0.0",
 "main": "src/server.js",
 "scripts": {
 "start": "node src/server.js"
 },
 "dependencies": {
 "express": "^4.21.0"
 }
}

File `src/server.js`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


const express = require("express");
const app = express();
const PORT = process.env.PORT || 3000;

app.get("/", (req, res) => {
 res.json({ message: "Hello from Node.js!", timestamp: new Date() });
});

app.get("/health", (req, res) => {
 res.json({ status: "ok" });
});

app.listen(PORT, "0.0.0.0", () => {
 console.log(`Server running on port ${PORT}`);
});

Note: app.listen(PORT, "0.0.0.0") — you must bind to 0.0.0.0 so the container can receive requests from outside. If you bind to 127.0.0.1 (localhost), Nginx won’t be able to connect to the app.

Step 2: Write the Dockerfile for Node.js

File `.dockerignore`

1
2
3
4


node_modules
npm-debug.log
.git
.env

According to the official Docker documentation, a Dockerfile for Node.js should use multi-stage builds, create a non-root user, and leverage cache mounts for optimization.

File `Dockerfile`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# Stage 1: Install dependencies
FROM node:18-alpine AS deps
WORKDIR /app

COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
 npm ci --only=production

# Stage 2: Production
FROM node:18-alpine AS production
WORKDIR /app

# Create non-root user (following best practices from Docker docs)
RUN addgroup -g 1001 -S nodejs && \
 adduser -S nodejs -u 1001 -G nodejs

ENV NODE_ENV=production

COPY --from=deps /app/node_modules ./node_modules
COPY src ./src
COPY package.json ./

USER nodejs

EXPOSE 3000

CMD ["node", "src/server.js"]

Explanation:

Technique	Purpose
`node:18-alpine`	Small base image (~170 MB instead of ~900 MB for `node:18`)
Multi-stage build	The `deps` stage installs dependencies, the `production` stage only copies the result
`npm ci`	Installs exactly according to `package-lock.json`, ensuring reproducible builds
`--mount=type=cache`	Caches npm packages across builds
Non-root user	Doesn’t run the app as root, improving security
`COPY src ./src`	Only copies the required source code, not the entire project

Step 3: Configure Nginx as a Reverse Proxy

File `nginx/default.conf`

According to the official Nginx documentation, the proxy_pass directive is used to forward requests to another server. The proxy_set_header directives need to be configured so the backend server receives correct client information.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


upstream nodejs_app {
 server app:3000;
}

server {
 listen 80;
 server_name _;

 # Limit request body size (prevent oversized uploads)
 client_max_body_size 10m;

 location / {
 proxy_pass http://nodejs_app;

 # Forward original client information to Node.js
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 # WebSocket support (if the app needs it)
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 }

 # Health check endpoint (Nginx responds directly, no need to go through Node.js)
 location = /nginx-health {
 access_log off;
 return 200 "ok";
 add_header Content-Type text/plain;
 }
}

Key directives explained:

Directive	Meaning
`upstream nodejs_app`	Defines a group of backend servers. When scaling multiple instances, add servers here
`proxy_pass http://nodejs_app`	Forwards requests to the defined upstream
`proxy_set_header Host $host`	Preserves the original hostname from the client (by default Nginx changes it to `$proxy_host`)
`proxy_set_header X-Real-IP`	Sends the client’s real IP to Node.js (not Nginx’s IP)
`proxy_set_header X-Forwarded-For`	The chain of IPs through proxies, helping Node.js identify the real client
`proxy_set_header X-Forwarded-Proto`	Tells Node.js whether the client is using HTTP or HTTPS
`proxy_http_version 1.1`	Required for WebSocket and keep-alive support

Step 4: Docker Compose — Connecting Everything

According to the Docker Compose production guide, when deploying to production you should: remove volume binds for code, set restart policies, and separate compose files for each environment.

File `docker-compose.yml`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


services:
 app:
 build:
 context: .
 dockerfile: Dockerfile
 target: production
 container_name: nodejs-app
 restart: unless-stopped
 environment:
 - NODE_ENV=production
 - PORT=3000
 expose:
 - "3000"
 healthcheck:
 test:
 [
 "CMD",
 "wget",
 "--quiet",
 "--tries=1",
 "--spider",
 "http://localhost:3000/health",
 ]
 interval: 30s
 timeout: 5s
 retries: 3
 start_period: 10s
 networks:
 - app-network

 nginx:
 image: nginx:1.27-alpine
 container_name: nginx-proxy
 restart: unless-stopped
 ports:
 - "80:80"
 volumes:
 - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
 depends_on:
 app:
 condition: service_healthy
 networks:
 - app-network

networks:
 app-network:
 driver: bridge

Key configurations:

Configuration	Explanation
`expose: "3000"`	Only opens the port internally between containers, not exposed to the host
`ports: "80:80"`	Only Nginx is exposed to the outside
`depends_on: condition: service_healthy`	Nginx only starts after Node.js is healthy
`restart: unless-stopped`	Auto-restarts on crash, unless you manually stop it
`:ro` (read-only)	Mounts the Nginx config in read-only mode
`networks: app-network`	Both containers share the same network, Nginx calls `app:3000` via the service name

Step 5: Build and Run

1
2
3
4
5
6
7
8


# Build and run everything
docker compose up --build -d

# View logs
docker compose logs -f

# Check status
docker compose ps

Verify it’s working:

1
2
3
4
5
6
7
8


# Request through Nginx (port 80)
curl http://localhost

# Check Node.js health
curl http://localhost/health

# Check Nginx health
curl http://localhost/nginx-health

Expected output:

1

{ "message": "Hello from Node.js!", "timestamp": "2026-02-10T12:00:00.000Z" }

Step 6: Redeploying After Code Changes

According to the Docker Compose docs, when updating code, you only need to rebuild the necessary service:

1
2
3


# Rebuild only the app service (without affecting Nginx)
docker compose build app
docker compose up --no-deps -d app

The --no-deps flag ensures only the app service is restarted, not Nginx. Clients experience no interruption.

Scaling: Running Multiple Node.js Instances

When traffic increases, you can run multiple Node.js instances and let Nginx load balance:

1

docker compose up --scale app=3 -d

Update nginx/default.conf so Nginx knows about multiple instances:

1
2
3
4
5


upstream nodejs_app {
 # Docker Compose DNS automatically resolves the service name
 # to all running container IPs
 server app:3000;
}

When using Docker Compose with --scale, Docker DNS automatically resolves app to all IPs of the app containers. Nginx will round-robin requests to each instance.

Implementation Notes

When applying to your project, keep these important points in mind:
- Always use expose instead of ports for backend services — only Nginx should be exposed to the outside
- Bind 0.0.0.0 in Node.js, not 127.0.0.1
- Use npm ci instead of npm install to ensure reproducible builds
- Create a non-root user in the Dockerfile for security
Best practices:
- Use docker compose up --no-deps -d app when you only need to redeploy the app
- Pin versions for base images (node:18-alpine, nginx:1.27-alpine) instead of latest
- Separate docker-compose.prod.yml for production config
Troubleshooting:
- Nginx returns 502 Bad Gateway? → Node.js hasn’t finished starting or is bound to the wrong address. Check docker compose logs app
- Can’t connect between Nginx and Node.js? → Make sure both are on the same network and the correct service name is used in proxy_pass
- Requests are timing out? → Check client_max_body_size and proxy_read_timeout in the Nginx config

🎯 Conclusion

Here’s a summary of the deployment flow:

Write the app — Node.js (Express) with a health check endpoint
Dockerfile — multi-stage build + non-root user
Nginx config — reverse proxy with proxy_pass and the necessary headers
Docker Compose — connect app + Nginx, only expose port 80
Deploy with docker compose up --build -d
Update with docker compose build app && docker compose up --no-deps -d app

This is the most basic architecture for deploying a Node.js application to production. From here, you can extend with SSL (Let’s Encrypt), databases, monitoring, and more as needed. 🚀

If you find this article helpful, feel free to ⭐ star the repo or 📱 share it with your friends! 😊

References

Docker Official - Containerize Node.js — Official Docker guide for Node.js
Docker Compose in Production — Production deployment guide with Compose
Nginx Reverse Proxy — Official reverse proxy configuration documentation
Nginx Beginner’s Guide — Beginner’s guide from nginx.org

Docker Compose for Beginners (v2) — Hands-on Practice

Wed, 04 Feb 2026 00:00:00 +0000

Docker Compose v2 - Multi-container Management Tool

Docker Compose is a tool that helps you define and run multiple containers simultaneously through a YAML file. Version v2 brings many improvements in performance and new features.

I. Installation and Preparation

1. Check Docker Compose Version

1
2
3
4
5


# Check current version
docker compose version

# Expected output (v2.x.x)
Docker Compose version v2.24.5

2. Basic Project Structure

1
2
3
4
5
6
7
8


my-app/
├── docker-compose.yml
├── .env
├── app/
│ ├── Dockerfile
│ └── src/
└── nginx/
 └── nginx.conf

II. Docker Compose v2 Syntax

1. Basic docker-compose.yml File

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


version: "3.8"

services:
 web:
 build: .
 ports:
 - "3000:3000"
 environment:
 - NODE_ENV=development
 volumes:
 - .:/app
 - /app/node_modules
 depends_on:
 - db

 db:
 image: postgres:15
 environment:
 POSTGRES_DB: myapp
 POSTGRES_USER: user
 POSTGRES_PASSWORD: password
 volumes:
 - postgres_data:/var/lib/postgresql/data
 ports:
 - "5432:5432"

volumes:
 postgres_data:

2. Using .env File

1
2
3
4
5
6
7


# .env file
NODE_ENV=development
DB_HOST=db
DB_PORT=5432
DB_NAME=myapp
DB_USER=user
DB_PASSWORD=password

1
2
3
4
5
6
7


# docker-compose.yml
services:
 web:
 environment:
 - NODE_ENV=${NODE_ENV}
 - DB_HOST=${DB_HOST}
 - DB_PORT=${DB_PORT}

III. Best Practices for Docker Compose v2

1. Network Management

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


version: "3.8"

services:
 frontend:
 build: ./frontend
 networks:
 - frontend-network

 backend:
 build: ./backend
 networks:
 - frontend-network
 - backend-network

 database:
 image: postgres:15
 networks:
 - backend-network

networks:
 frontend-network:
 driver: bridge
 backend-network:
 driver: bridge

2. Health Checks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


services:
 web:
 build: .
 healthcheck:
 test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
 interval: 30s
 timeout: 10s
 retries: 3
 start_period: 40s

 db:
 image: postgres:15
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
 interval: 10s
 timeout: 5s
 retries: 5

3. Resource Limits

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


services:
 web:
 build: .
 deploy:
 resources:
 limits:
 cpus: "0.5"
 memory: 512M
 reservations:
 cpus: "0.25"
 memory: 256M

IV. Common Docker Compose v2 Commands

1. Basic Commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Start services (detached mode)
docker compose up -d

# View logs
docker compose logs -f

# Stop services
docker compose down

# Rebuild and restart
docker compose up --build -d

# View service status
docker compose ps

2. Advanced Commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Run a command inside a container
docker compose exec web bash

# Scale a service
docker compose up --scale web=3 -d

# View resource usage
docker compose top

# Validate compose file
docker compose config

V. Real-World Example: Web App with Database

1. Node.js + PostgreSQL + Redis

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


version: "3.8"

services:
 app:
 build:
 context: .
 dockerfile: Dockerfile
 ports:
 - "3000:3000"
 environment:
 - NODE_ENV=development
 - DATABASE_URL=postgresql://user:password@db:5432/myapp
 - REDIS_URL=redis://redis:6379
 volumes:
 - .:/app
 - /app/node_modules
 depends_on:
 db:
 condition: service_healthy
 redis:
 condition: service_started
 restart: unless-stopped

 db:
 image: postgres:15-alpine
 environment:
 POSTGRES_DB: myapp
 POSTGRES_USER: user
 POSTGRES_PASSWORD: password
 volumes:
 - postgres_data:/var/lib/postgresql/data
 - ./init.sql:/docker-entrypoint-initdb.d/init.sql
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U user"]
 interval: 10s
 timeout: 5s
 retries: 5
 restart: unless-stopped

 redis:
 image: redis:7-alpine
 command: redis-server --appendonly yes
 volumes:
 - redis_data:/data
 restart: unless-stopped

 nginx:
 image: nginx:alpine
 ports:
 - "80:80"
 volumes:
 - ./nginx.conf:/etc/nginx/nginx.conf
 depends_on:
 - app
 restart: unless-stopped

volumes:
 postgres_data:
 redis_data:

2. nginx.conf File

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


events {
 worker_connections 1024;
}

http {
 upstream app {
 server app:3000;
 }

 server {
 listen 80;

 location / {
 proxy_pass http://app;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
 }
}

VI. Override and Multiple Environments

1. docker-compose.override.yml

1
2
3
4
5
6
7
8
9


# docker-compose.override.yml (automatically loaded)
version: "3.8"

services:
 app:
 volumes:
 - .:/app
 environment:
 - DEBUG=true

2. Environment-specific Files

1
2
3
4
5


# Development
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d

# Production
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# docker-compose.prod.yml
version: "3.8"

services:
 app:
 restart: always
 deploy:
 resources:
 limits:
 memory: 1G
 environment:
 - NODE_ENV=production

Implementation Notes

When applying to your project, keep these important points in mind:
- Always use .env files for sensitive data
- Implement health checks for critical services
- Use named volumes for persistent data
- Configure appropriate restart policies
Best practices:
- Separate networks for security
- Use specific image tags instead of latest
- Implement a proper logging strategy
Troubleshooting:
- Use docker compose logs to debug
- Check docker compose config before deploying
- Monitor resource usage with docker compose top

🎯 Conclusion

Docker Compose v2 is a powerful tool that helps you manage multi-container applications with ease. With the best practices above, you can build and deploy applications professionally and efficiently! 🚀

Try experimenting with the examples above and gradually apply them to your real-world projects. 😊

Docker Basics: Image vs Container

Sun, 25 Jan 2026 00:00:00 +0000

Docker Image and Container - Two Essential Concepts

When starting with Docker, the two most important concepts you need to understand are Image and Container. Beginners often confuse them, but in reality, they play different roles in the Docker ecosystem. Image is like a recipe repository (cooking instructions), while Container is the actual execution (the prepared dish). 🍳

In this article, I’ll explain the detailed differences between Image and Container, how they work together, and provide real examples for better understanding.

I. What is a Docker Image?

A Docker Image is a template used to create a Container. It contains everything needed to run an application:

Operating system — usually minimal Linux
Runtime environment — Node.js, Python, Java, etc.
Application code
Dependencies (libraries)
Configuration files
Environment variables

1. Key Characteristics of Docker Image

Read-only: Image is read-only and cannot be changed after creation
Layered structure: Image is built from layers, each layer representing a command in Dockerfile
Reusable: The same image can be used to create multiple containers
Version-controlled: Each image has tags (e.g., 1.0, latest, alpine) for version management

Example of Image Structure:

Layer	Content
Layer 1	Base OS (Alpine Linux)
Layer 2	System packages (curl, wget)
Layer 3	Node.js runtime (18.x)
Layer 4	Application code
Layer 5	Environment variables

2. Common Image Commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Pull an image from Docker Hub
docker pull node:18-alpine

# List downloaded images
docker images

# Remove an unused image
docker image rm node:18-alpine

# Remove all unused images
docker image prune -a

# Build image from Dockerfile
docker build -t myapp:1.0 .

II. What is a Docker Container?

A Docker Container is a running instance created from a Docker Image. Container has:

Its own file system
Isolated network space
Independent processes and operations
Its own environment variables

1. Key Characteristics of Docker Container

Read-only base + Read-write layer: Container has a read-write layer that allows data changes
Isolated: Container is isolated from host and other containers
Stateful: Container can be in various states: running, stopped, paused, exited
Ephemeral: Containers can be created and deleted quickly (< 1 second)

Example of Container:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Create and run container from image
docker run -d --name myapp node:18-alpine node server.js

# List running containers
docker ps

# List all containers (including stopped)
docker ps -a

# Stop container
docker stop myapp

# Restart container
docker start myapp

# Remove container
docker rm myapp

# View container logs
docker logs myapp

2. Comparing Container with Virtual Machine

Aspect	Docker Container	Virtual Machine
Operating System	Share kernel with host	Full dedicated OS
Boot Time	~ 1-2 seconds	~ 1-2 minutes
Disk Size	MB (10-100 MB)	GB (1-10 GB)
Performance	Nearly native	Needs virtualization overhead
Max Per Host	Hundreds	Tens

Docker Container Architecture

III. Detailed Comparison: Image vs Container

For easy visualization, see the comparison table below:

Complete Comparison Table

Aspect	Image	Container
Analogy	Recipe repository (cooking recipe)	Prepared dish
State	Static (read-only)	Dynamic (read-write)
Changes	Cannot change after creation	Can change while running
Quantity	1 image creates N containers	Many containers from 1 image
Creation Time	Slow (first build ~5-10 mins)	Fast (< 1 second)
Storage	Stored in Docker cache	Stored at runtime or in volumes
Portability	Easy to share (push/pull)	Only runs where Docker is installed
Version	Has tags for management (1.0, 2.0, latest)	No separate version
Network	No	Has isolated network
Storage	Stored in layers	Has read-write layer on top of image

Relationship between Image and Container

1
2
3
4
5
6
7
8
9


Docker Image (Template)
 ↓
 docker run
 ↓
Docker Container (Running Instance)
 ↓
 docker commit
 ↓
Docker Image baru (updated)

Notes:

Image is like a class in Object Oriented Programming (OOP)
Container is like an object (instance of a class)
Use docker run to create container from image
Use docker commit to save container as a new image

IV. Real-World Example from Start to Finish

For better understanding, let’s do a detailed example:

1. Create Dockerfile (to build image)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Dockerfile
FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["node", "server.js"]

2. Build image from Dockerfile

1
2
3
4
5
6
7
8


# Build image with name myapp and tag 1.0
docker build -t myapp:1.0 .

# View created image
docker images
# Output:
# REPOSITORY TAG IMAGE ID CREATED SIZE
# myapp 1.0 abc123def456 2 minutes ago 150MB

3. Create and run container from image

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Run container from image myapp:1.0
docker run -d \
 --name myapp-container \
 -p 3000:3000 \
 myapp:1.0

# View running containers
docker ps
# Output:
# CONTAINER ID IMAGE COMMAND STATUS PORTS
# xyz789ghi012 myapp:1.0 "node server.js" Up 2 minutes 0.0.0.0:3000->3000/tcp

# View logs
docker logs myapp-container

4. Interact with container

1
2
3
4
5
6


# Access container shell
docker exec -it myapp-container sh

# Inside container — you can:
ls -la /app
curl http://localhost:3000

5. Remove container and image

1
2
3
4
5
6
7
8


# Stop container
docker stop myapp-container

# Remove container
docker rm myapp-container

# Remove image
docker rmi myapp:1.0

V. Best Practices with Image and Container

1. Image Management

✅ Use specific versions (e.g., node:18.12-alpine instead of node:latest)
✅ Reduce size using minimal base images (alpine, distroless)
✅ Leverage layer cache by ordering commands properly
✅ Use .dockerignore to exclude unnecessary files
✅ Regularly remove unused images with docker image prune

1
2
3
4


# Example: Use specific image version
FROM node:18.12.1-alpine
# instead of
FROM node:latest

2. Container Management

✅ Name containers clearly (--name app-container)
✅ Use -d (detached mode) to run containers in background
✅ Regularly check logs for debugging (docker logs -f)
✅ Use volumes if data persistence is needed
✅ Limit resources with --cpus, --memory

1
2
3
4
5
6
7


# Run container with resource limits
docker run -d \
 --name app \
 --cpus="1.5" \
 --memory="512m" \
 -p 8080:80 \
 myapp:1.0

Common Troubleshooting

1. Cannot create container from image

Error:

1

Error: Cannot start container from image

Causes:

Image hasn’t been built or pulled
Image is corrupted
Port is already in use by another container

Solution:

1
2
3
4
5
6
7
8


# Check if image exists
docker images | grep myapp

# Pull again if not present
docker pull myapp:1.0

# Rebuild image
docker build -t myapp:1.0 .

2. Container doesn’t persist data when stopped

Cause: Container is ephemeral, data inside will be lost when it stops or is removed.

Solution: Use Docker Volumes

1
2
3
4
5
6
7
8


# Create volume
docker volume create myapp-data

# Mount volume to container
docker run -d \
 --name app \
 -v myapp-data:/app/data \
 myapp:1.0

3. Container not accessible from outside

Error: Cannot access http://localhost:3000 when running container

Solution:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Ensure port is mapped from container → host
docker run -d \
 --name app \
 -p 3000:3000 \
 myapp:1.0

# For multi-container setup, use docker network
docker network create mynet
docker run -d --network mynet --name app1 myapp:1.0
docker run -d --network mynet --name app2 myapp:1.0

Implementation Notes 🔧

When applying to your project, remember these important points:

Don’t modify containers directly — Rebuild image with Dockerfile
Use docker-compose.yaml to manage multiple containers and dependencies
Use CI/CD to automatically build and push images to Docker Hub/Registry
Monitor resources with docker stats or Prometheus + Grafana
Backup data regularly from volumes

Best practices:

Always name images and containers clearly
Use specific tags for different environments (dev, staging, prod)
Write .dockerignore to reduce image size and speed up builds
Use multi-stage build to create minimal images

Troubleshooting:

When container crashes, check logs: docker logs <container-name>
When pulling fails, check network: ping registry-1.docker.io
When container can’t access files, mount volume with correct permissions

🎯 Conclusion

To summarize:

Docker Image = Recipe repository (read-only template) — Contains all settings needed to run an application
Docker Container = Prepared dish (running instance) — Container created from image with read-write layer
Image is static, Container is dynamic
Use docker run to create container from image
Use docker commit to update container as a new image

Now you understand the differences between Image and Container. Next step: learn how to use Dockerfile to build images and Docker Compose to manage multiple containers. 🚀

If you found this article helpful, remember to ⭐ star the repo or 📱 share with friends! 😊

Beginner on Hoang Duong

Deploying Node.js with Docker + Nginx

Deploying Node.js with Docker + Nginx — Case Study

Architecture Overview

Step 1: Create the Node.js Application (Express)

Project Structure

File package.json

File src/server.js

Step 2: Write the Dockerfile for Node.js

File .dockerignore

File Dockerfile

Step 3: Configure Nginx as a Reverse Proxy

File nginx/default.conf

Step 4: Docker Compose — Connecting Everything

File docker-compose.yml

Step 5: Build and Run

Step 6: Redeploying After Code Changes

Scaling: Running Multiple Node.js Instances

Implementation Notes

🎯 Conclusion

References

Docker Compose for Beginners (v2) — Hands-on Practice

Docker Compose v2 - Multi-container Management Tool

I. Installation and Preparation

1. Check Docker Compose Version

2. Basic Project Structure

II. Docker Compose v2 Syntax

1. Basic docker-compose.yml File

2. Using .env File

III. Best Practices for Docker Compose v2

1. Network Management

2. Health Checks

3. Resource Limits

IV. Common Docker Compose v2 Commands

1. Basic Commands

2. Advanced Commands

V. Real-World Example: Web App with Database

1. Node.js + PostgreSQL + Redis

2. nginx.conf File

VI. Override and Multiple Environments

1. docker-compose.override.yml

2. Environment-specific Files

Implementation Notes

🎯 Conclusion

Docker Basics: Image vs Container

Docker Image and Container - Two Essential Concepts

I. What is a Docker Image?

1. Key Characteristics of Docker Image

2. Common Image Commands

II. What is a Docker Container?

1. Key Characteristics of Docker Container

2. Comparing Container with Virtual Machine

III. Detailed Comparison: Image vs Container

Complete Comparison Table

Relationship between Image and Container

IV. Real-World Example from Start to Finish

1. Create Dockerfile (to build image)

2. Build image from Dockerfile

3. Create and run container from image

4. Interact with container

5. Remove container and image

V. Best Practices with Image and Container

1. Image Management

2. Container Management

Common Troubleshooting

1. Cannot create container from image

2. Container doesn’t persist data when stopped

3. Container not accessible from outside

Implementation Notes 🔧

🎯 Conclusion

References

File `package.json`

File `src/server.js`

File `.dockerignore`

File `Dockerfile`

File `nginx/default.conf`

File `docker-compose.yml`