Fork mode runs a single instance of your app as one Node.js process — simple and predictable, but it can only use one CPU core and has no built-in load balancing. Cluster mode spawns multiple instances behind PM2's internal load balancer, using the Node.js cluster module to share a single port across processes — ideal for HTTP APIs that need to use every CPU core. Fork mode suits background workers, cron jobs, or apps that already manage their own concurrency; cluster mode is the default choice for stateless web servers.

instances: "max" tells PM2 to detect the number of CPU cores on the host and spawn that many cluster instances automatically, so the same ecosystem.config.js scales correctly whether you deploy to a 2-core or 16-core VPS. You can also use instances: -1 to use all cores minus one, leaving headroom for other services, or a fixed number like 2 for predictable memory usage. "max" only applies in cluster mode — fork mode always runs a single instance.

pm2 save writes the current process list to PM2's dump file so it can be restored later. pm2 startup generates and configures a system init script (systemd, upstart, etc.) that resurrects your saved process list on server reboot. Without both steps, PM2 forgets your apps after a restart or a crash-and-reboot cycle — running only pm2 start ecosystem.config.js keeps the app alive for the current session but does not survive a reboot.

A common starting point is 300-500M for small Node.js APIs and 500M-1G for apps with in-memory caching or larger dependency trees. Set it comfortably above your app's normal steady-state memory usage, which you can check with pm2 monit, so it only triggers on real leaks rather than everyday garbage-collection spikes. Leave it unset while you are still profiling memory usage — adding a restart threshold too early can mask a leak instead of surfacing it.

No — watch mode restarts your app whenever a file in the working directory changes, which is useful in local development but risky in production. Log files, uploaded content, or a deployment script writing new files can trigger unexpected restarts and drop in-flight requests. In production, keep watch: false and restart deliberately after each deploy — use pm2 reload ecosystem.config.js for zero-downtime restarts in cluster mode.