---
title: "Comment by Node Edge Ops on \"Implementing Zero-Downtime CI/CD for Node.js Apps on AWS EC2\" | Hashnode"
description: "Zero-downtime Node deploys on EC2 only work when health, traffic shift, and rollback share one definition of ready. Prefer bringing the new instance to a passin"
url: "https://hashnode.com/posts/implementing-zero-downtime-cicd-for-nodejs-apps-on-aws-ec2/691eaeb4aced8a9d8edd5e2c/comment/6af2a267aacfcbbc2966ab4d"
---

[Discussion](https://hashnode.com/posts/implementing-zero-downtime-cicd-for-nodejs-apps-on-aws-ec2/691eaeb4aced8a9d8edd5e2c)

Comment [Implementing Zero-Downtime CI/CD for Node.js Apps on AWS EC2](https://hashnode.com/posts/implementing-zero-downtime-cicd-for-nodejs-apps-on-aws-ec2/691eaeb4aced8a9d8edd5e2c)

[Node Edge Ops](https://hashnode.com/@nodeedgeops)

[2d ago](https://hashnode.com/posts/implementing-zero-downtime-cicd-for-nodejs-apps-on-aws-ec2/691eaeb4aced8a9d8edd5e2c/comment/6af2a267aacfcbbc2966ab4d)

Zero-downtime Node deploys on EC2 only work when health, traffic shift, and rollback share one definition of ready. Prefer bringing the new instance to a passing readiness probe before removing the old target, drain in-flight connections with a bounded wait, and keep the previous AMI or process tree bootable until error budgets clear. Treat a green build artifact as necessary but not sufficient — the cutover gate should be live request success, not a CI badge alone.

Ops prove-out after wiring the pipeline: roll a canary host under peak-like load and confirm the balancer only sends traffic after readiness passes, then abort mid-roll and confirm traffic returns to the prior healthy set without dual-serving broken builds. Watch 5xx share, connection reset rate, and deploy duration for one release window — rising resets with flat health usually means drain was shorter than the longest in-flight handler. Keep one untouched host on the prior revision beside the new fleet so you can tell a bad artifact from a balancer misconfig.