Cluster Module vs PM2 Reload for Zero‑Downtime Express Restart

Direct answer

For a small Express app, PM2 reload in cluster mode offers the best balance of zero-downtime request handling and minimal operational overhead. However, neither PM2 reload nor the Node.js cluster module preserves in-memory Express sessions when a worker restarts. If session state must survive a restart, externalize sessions to Redis or switch to stateless tokens before choosing a restart method.

What each method does

Node.js cluster module

All workers share one listening port through the operating system. You can fork a replacement worker, allow it to accept traffic, then close the old worker after a drain timeout so in-flight requests finish first. The cluster module itself does not cause port conflicts during rolling restarts; EADDRINUSE appears only if a worker or another process binds the port independently.

PM2 reload

PM2 restarts instances one at a time. True zero-downtime behavior generally requires cluster mode with more than one instance. A single instance may stop listening briefly while the replacement binds the port. PM2 does not share process memory between instances.

Sessions and active connections

In-memory sessions live in a worker's heap. Restarting that worker loses its sessions. Sticky sessions route a client to the same worker, but they do not survive that worker's restart. Active TCP connections cannot be transferred to a new process; zero-downtime means surviving workers keep accepting traffic while the restarting worker drains.

Recommended steps

1. Externalize session storage (for example, connect-redis) or issue stateless session tokens if persistence is required.
2. Start the app with PM2 in cluster mode: pm2 start app.js -i 2.
3. Use pm2 reload app_name for rolling restarts.
4. Verify by sending a slow request during reload and confirming it completes without connection errors.

Assumptions and verification

This guidance assumes PM2 5.x or 6.x and a modern Node.js release. Older PM2 versions may handle reload timing differently. Confirm your production instance count and sticky-session setting; a single instance may produce a brief stop-start gap during reload.

Missing diagnostic detail: Can you externalize session storage or switch to stateless authentication before deploying? This changes the recommendation because neither approach meets your stated session-preservation goal with in-memory storage alone.