Engineering resilience into a system often matters more than the initial feature set.
I recently solved a recurring challenge in our deployment pipeline: eliminating the 502 Bad Gateway errors that typically occur when rebuilding and restarting Docker containers on a single EC2 instance. Instead of scaling up infrastructure costs, I implemented a blue-green deployment strategy using Nginx as a dynamic reverse proxy and a custom Bash-driven health-check logic.
I have documented the architecture and the deployment scripts in detail here: <a href="https://saadh393.github.io/projects/blue-green-deployment-zero-downtime" target="_blank" rel="noopener nofollow">https://saadh393.github.io/projects/blue-green-deployment-zero-downtime</a>
#SoftwareEngineering #DevOps #SystemDesign #NextJS #AWS #Docker #Nginx #FullStackDevelopment

Saad Hasan

A blue-green deployment strategy implemented on a single EC2 instance to eliminate 502 Bad Gateway errors during Docker container restarts. The approach uses Nginx as a dynamic reverse proxy combined with custom Bash health-check logic to achieve zero-downtime deployments without increasing infrastructure costs.

Deploy Your Application with Zero Downtime & zero extra cost

Nice description of the idea, thanks.

Nice! it will be a great help to other devs out there (including me)!

Ok… what should we do if we don’t want to fully flip to another instance… for example take only 5% of your requests to new one … And step by increase to 100%
We could have a bug on some endpoints or flow and we don’t want to break this for all users!!

i think this is close but misses the mark ever so slightly.
Blue / Green deployments are certainly important but the way it’s executed in this article still has flaws from an architectural POV IMO. I haven’t read this article thoroughly but based on that nginx config if your application experiences an exception or failure (OOM perhaps) and the process is killed that would mean the upstream would switch to a version of the upstream that you may not have wanted released for example.
There are tools like K8s that can help tackle this but if you’re on a small EC2 instance I think this could be revised a little to ensure you get the smooth releases but also app resilience with version pinning to ensure you’re you don’t make something live unless explicitly intentional.