Ecosystem File vs CLI-Only Management for Deploying a Stateful Node.js App Under PM2

I'm deciding how to standardize PM2 deployments for a Node.js service that runs in cluster mode and holds some in-memory session state. The two documented approaches are starting processes directly with pm2 start app.js and persisting them with pm2 save plus pm2 startup, versus declaring everything in an ecosystem.config.js file under version control.

The CLI route is faster for prototyping, but I worry about configuration drift between staging and production when flags like -i max, watch settings, and environment variables live only in shell history. The ecosystem file makes cluster mode and per-environment variables declarative and reviewable, but adds a layer of indirection for quick local experiments.

There is also a behavioral tension I can't resolve from the docs alone: for a stateful app, pm2 reload promises zero-downtime staggered worker restarts in cluster mode, while pm2 restart hard-kills processes. It's unclear how in-flight connections are drained during a reload.

1. For a stateful cluster-mode app, does the ecosystem file offer any operational advantage over CLI flags beyond version control, or is it purely a maintainability choice?
2. Does pm2 reload wait for existing connections to close before replacing a worker, or must connection draining be handled in application code?
3. Given in-memory sessions, is cluster mode with reload safe, or should I assume a distributed session store is a hard prerequisite?