---
title: "Discussion on \"Scaling Docker Containers with Nginx: A Guide to Reverse Proxy and Load Balancing\" | Hashnode"
description: "Discussion on \"Scaling Docker Containers with Nginx: A Guide to Reverse Proxy and Load Balancing\". Introduction\nIn the world of web development, building scalable and robust REST APIs is crucial. With the increasing popularity of Docker containers, it's essential to know how to scale your Node.js REST API using containers. This guide is inspired b..."
url: "https://hashnode.com/posts/scaling-docker-containers-with-nginx-a-guide-to-reverse-proxy-and-load-balancing/64099253a066236836f314d4"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Scaling Docker Containers with Nginx: A Guide to Reverse Proxy and Load Balancing](https://milaan.hashnode.dev/scaling-docker-containers-with-nginx-a-guide-to-reverse-proxy-and-load-balancing?utm_source=hashnode&utm_medium=feed)

Introduction In the world of web development, building scalable and robust REST APIs is crucial. With the increasing popularity of Docker containers, it's essential to know how to scale your Node.js REST API using containers. This guide is inspired b...

Mar 9, 2023 · 6 min read · milaan.hashnode.dev  
Read the article

-   [#docker](https://hashnode.com/tag/docker)
-   [#nodejs](https://hashnode.com/tag/nodejs)
-   [#docker-compose](https://hashnode.com/tag/docker-compose)
-   [#docker-scaling](https://hashnode.com/tag/docker-scaling)
-   [#docker-nginx](https://hashnode.com/tag/docker-nginx)

## Written by

[Milan Dangol](https://hashnode.com/@milandangol)

@milandangol · Kathmandu, Nepal

  
[View profile](https://hashnode.com/@milandangol)

Tech Lead

I help companies scale across 𝗰𝗹𝗼𝘂𝗱 𝗮𝗻𝗱 𝗼𝗻-𝗽𝗿𝗲𝗺 environments without 𝗼𝘃𝗲𝗿𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴. My focus is on building 𝗽𝗿𝗮𝗴𝗺𝗮𝘁𝗶𝗰, 𝗿𝗶𝗴𝗵𝘁-𝘀𝗶𝘇𝗲𝗱 𝘁𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝘆 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 that support real business needs systems that are reliable, cost-efficient, and easy to operate as the organization grows. I believe technology should enable momentum, not create unnecessary complexity or long-term maintenance burden. I work closely with 𝗹𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 and 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 teams to make intentional technology decisions, balancing speed, stability, security, and cost. My approach is grounded in simplicity, clarity, and long-term sustainability rather than chasing tools or trends. My experience includes: • Designing and scaling platforms across cloud and on-prem • Improving system reliability and operational maturity • Optimizing infrastructure costs through thoughtful architecture • Automating delivery and operations to reduce friction and risk I’m hands-on when execution is needed and strategic when direction matters most. Whether a company is preparing to scale or untangling complexity that has built up over time, I focus on solutions that work today and remain sensible tomorrow. If you value 𝗰𝗹𝗲𝗮𝗿 𝘁𝗵𝗶𝗻𝗸𝗶𝗻𝗴, 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝘁𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝘆 𝘁𝗵𝗮𝘁 𝘀𝗲𝗿𝘃𝗲𝘀 𝘁𝗵𝗲 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀, we’ll work well togetherGiving up is not in the blood, sir. It's not in the blood.

## Responses 1

Markdown supported · ⌘↵ to post

[CDN Edge Ops](https://hashnode.com/@cdnedgeops)

[5d ago](https://hashnode.com/posts/scaling-docker-containers-with-nginx-a-guide-to-reverse-proxy-and-load-balancing/64099253a066236836f314d4/comment/6aebc59dea0102533312b37c)

Solid compose pattern: scale the Node replicas and put nginx in front as the single published listener. The ops detail that usually bites after `docker compose up --scale` is that a static upstream block only learns peers at reload — new container IPs from a recreate stay invisible until nginx reloads or you use a resolver-aware variable upstream. Keep app ports on the internal network only; expose 80/443 on the proxy.

For the load-balancer side I prefer least\_conn once replicas are roughly equal, with modest max\_fails/fail\_timeout so a crashed task leaves the pool instead of 502-ing every other request. Set proxy\_http\_version 1.1, clear Connection for keepalive, and pass Host plus X-Forwarded-For/Proto so the API builds redirects correctly. After a scale event I hit each replica by service DNS from inside the nginx container, then through the public vhost, and compare status and latency — mismatches almost always mean a stale upstream list or a trailing-slash join, not the image tag.