{"id":2234,"date":"2026-07-14T11:18:57","date_gmt":"2026-07-14T11:18:57","guid":{"rendered":"https:\/\/ukspeed.co.uk\/blog\/?p=2234"},"modified":"2026-07-14T11:44:18","modified_gmt":"2026-07-14T11:44:18","slug":"pm2-resurrect-node-js-uk-vps-auto-restart-after-reboot-2026","status":"publish","type":"post","link":"https:\/\/ukspeed.co.uk\/blog\/pm2-resurrect-node-js-uk-vps-auto-restart-after-reboot-2026\/","title":{"rendered":"How to Auto-Restart Node.js Apps After UK VPS Reboot: PM2 Resurrect & pm2.dump 2026 Guide"},"content":{"rendered":"\n

PM2 Resurrect UK VPS<\/strong> is the two-command trick every Node.js developer needs to know before shipping to production, because a single unplanned reboot can silently take down your entire API stack without it. PM2 is the Node.js process manager that keeps applications running under load, restarts crashed workers, and \u2014 with pm2 save<\/code> plus pm2 startup<\/code> \u2014 reliably brings every service back after any UK VPS reboot. This guide shows the complete PM2 Resurrect workflow, from installation to auto-restart configuration and monitoring, tested on Ubuntu 24.04 LTS running on a UK Speed premium network VPS<\/a>.<\/p>\n\n\n\n

\n\n<\/linearGradient><\/defs>\n\nPM2 Resurrect UK VPS \u2014 Boot Recovery Flow 2026<\/text>\n\n\n1. pm2 start<\/text>\nLaunch Node app<\/text>\nCluster mode<\/text>\nAuto-restart on crash<\/text>\npm2 start app.js<\/text>\n-i max –name api<\/text>\n\n2. pm2 save<\/text>\nSnapshot process list<\/text>\nWrite dump.pm2<\/text>\n~\/.pm2\/dump.pm2<\/text>\npm2 save<\/text>\n\n3. pm2 startup<\/text>\nGenerate systemd unit<\/text>\nInstall boot hook<\/text>\nEnable systemctl<\/text>\npm2 startup<\/text>\nsystemctl enable pm2<\/text>\nOn reboot: systemd \u2192 pm2 resurrect \u2192 apps online in seconds<\/text>\n<\/g>\n<\/svg>\n
The three-step PM2 Resurrect workflow every Node.js production on UK VPS needs.<\/figcaption>\n<\/figure>\n\n\n\n

Why Node.js Apps Need PM2 Resurrect on UK VPS<\/h2>\n\n\n\n

A Node.js app started with node server.js<\/code> dies the moment the SSH session ends, the process crashes, or the UK VPS reboots. In production, none of those events should ever bring down your API. PM2 solves crash restart automatically, but that alone does not survive a reboot \u2014 after a fresh boot, PM2 itself is not running, and without pm2 save<\/code> plus pm2 startup<\/code>, every Node.js service must be manually started. PM2 Resurrect closes this final gap: on any reboot, systemd starts PM2, PM2 reads its saved dump, and every app comes back exactly as it was.<\/p>\n\n\n\n

How PM2 Resurrect Manages Node.js Processes in Production<\/h2>\n\n\n\n

PM2 is a single Node.js binary that runs as a daemon and supervises child processes. It handles clustering (fork mode or cluster mode across all CPU cores), automatic restart on crash, log aggregation, memory and CPU limits, and graceful reload for zero-downtime deploys. Under the hood, PM2 maintains a list of managed apps with their environment, working directory, and restart policy \u2014 everything needed to reconstruct the runtime state. On a modest 4 vCPU UK Speed NVMe VPS, PM2 comfortably supervises 10-20 Node.js processes, matching the performance profile of the VPS NVMe tier<\/a>.<\/p>\n\n\n\n

How to Install PM2 on Ubuntu 24.04 UK VPS<\/h2>\n\n\n\n

Install Node.js 22 LTS from NodeSource: curl -fsSL https:\/\/deb.nodesource.com\/setup_22.x | sudo -E bash - && sudo apt-get install -y nodejs<\/code>. Verify with node --version<\/code>. Then install PM2 globally: sudo npm install -g pm2@latest<\/code>. Confirm with pm2 --version<\/code>. Best practice is to run PM2 under a dedicated non-root user like appuser<\/code> \u2014 this contains any compromise to that user’s home directory. Create the user with adduser appuser<\/code>, switch to it with sudo -iu appuser<\/code>, and install your Node.js app files under \/home\/appuser<\/code>.<\/p>\n\n\n\n

Using pm2 save and pm2.dump for State Persistence<\/h2>\n\n\n\n

Start your Node.js app with PM2: pm2 start app.js --name api-server -i max<\/code>. The -i max<\/code> flag runs one instance per CPU core in cluster mode, giving free horizontal scaling on the same VPS. Verify with pm2 list<\/code> that the app shows online. Then run pm2 save<\/code>. This writes ~\/.pm2\/dump.pm2<\/code> \u2014 a JSON snapshot of every running app with its exact command, environment, and cluster settings. Any time you change the app list (new app, deleted app, changed args), run pm2 save<\/code> again. Skipping this step is the number-one cause of “apps disappear after reboot” tickets.<\/p>\n\n\n\n

How to Set Up PM2 Resurrect for Automatic Boot Recovery<\/h2>\n\n\n\n

Run pm2 startup<\/code>. PM2 detects your init system (systemd on modern Ubuntu, Debian, and Rocky Linux) and prints a single sudo env PATH=... pm2 startup systemd -u appuser --hp \/home\/appuser<\/code> command. Copy and paste that command exactly \u2014 it installs a systemd unit file at \/etc\/systemd\/system\/pm2-appuser.service<\/code> that starts PM2 at boot under your app user. Enable and verify with sudo systemctl status pm2-appuser<\/code>. From this point, every reboot triggers systemd \u2192 PM2 \u2192 pm2 resurrect<\/code>, which reads the dump and starts every app.<\/p>\n\n\n\n

How PM2 Resurrect Works After a UK VPS Reboot<\/h2>\n\n\n\n

The PM2 Resurrect chain runs in this order: systemd starts the pm2 unit \u2192 PM2 daemon boots \u2192 PM2 reads dump.pm2<\/code> \u2192 each app process starts in cluster or fork mode \u2192 PM2 begins restart-on-crash supervision. The whole sequence completes in 3-8 seconds on a UK Speed NVMe VPS. Because Node.js apps typically boot in under a second, your API is live essentially at kernel-ready. Combined with unmetered UK VPS bandwidth<\/a>, the reboot recovery pattern is bulletproof even when a viral event drives massive traffic immediately after restart.<\/p>\n\n\n\n

Testing PM2 Resurrect with a Real Server Reboot<\/h2>\n\n\n\n

Never trust a PM2 Resurrect configuration without testing it. Confirm apps are running, run pm2 save<\/code>, then sudo reboot<\/code> the VPS. Reconnect via SSH after 30 seconds and run pm2 list<\/code> to confirm PM2 Resurrect worked \u2014 every app should be back with a fresh uptime counter and zero restarts. If any app is missing, check journalctl -u pm2-appuser -e<\/code> for the boot-time error. Common causes: forgot to pm2 save<\/code> after adding an app, PM2 startup running as the wrong user, or the app directory unreadable due to disk mount timing. Similar patterns work well inside Docker Compose stacks on UK VPS<\/a>.<\/p>\n\n\n\n

How to Use PM2 Ecosystem File for Reproducible Deploys<\/h2>\n\n\n\n

Command-line flags work for one-off starts, but production UK VPS deployments live in ecosystem.config.js<\/code>. This file declares every app your PM2 instance manages \u2014 name, script, cwd, env, instances, exec_mode, max_memory_restart, log paths, and restart policy \u2014 as version-controlled JavaScript. Start the whole fleet with pm2 start ecosystem.config.js --env production<\/code>. The --env<\/code> flag activates named environment blocks so the same file drives staging and production with different NODE_ENV<\/code> and secrets. Because the file lives in git, every teammate deploys the same stack with the same tuning, and disaster recovery on a new UK VPS is one git clone && pm2 start ecosystem.config.js<\/code> away from full restoration.<\/p>\n\n\n\n

Combine the ecosystem file with an EnvironmentFile=\/home\/appuser\/.env.production<\/code> loaded by the systemd wrapper so secrets never end up committed to the repo. PM2 reads them at process start via process.env<\/code>, giving your Node.js code the same runtime shape across staging and production.<\/p>\n\n\n\n

Monitoring Node.js Apps with PM2 Metrics<\/h2>\n\n\n\n

pm2 monit<\/code> opens a real-time terminal dashboard showing CPU, memory, and event loop lag per process. For historical monitoring, use PM2 Plus’s free tier or expose PM2 metrics on a local port and scrape them with Prometheus. Set memory restart limits with --max-memory-restart 500M<\/code> \u2014 PM2 gracefully restarts any process that exceeds 500 MB, preventing runaway memory leaks. Set --restart-delay 3000<\/code> to add a three-second cooldown between restarts, avoiding thrashing when a bug causes constant crashes.<\/p>\n\n\n\n

How to Zero-Downtime Deploy with PM2 Reload<\/h2>\n\n\n\n

Beyond PM2 Resurrect, the final PM2 production skill: pm2 reload api-server<\/code> restarts your app in cluster mode by shutting down old workers one at a time as new ones come online, with zero dropped connections. Compare to pm2 restart<\/code> which kills all workers simultaneously \u2014 a brief outage. Zero-downtime reload works because cluster mode has multiple workers behind PM2’s internal load balancer; a rolling restart keeps requests flowing. Combine with sub-100ms TTFB optimizations<\/a> and your Node.js API on UK VPS matches the operational quality of managed platforms costing 10x more.<\/p>\n\n\n\n

Troubleshooting Common PM2 Resurrect Failures<\/h2>\n\n\n\n

Three failures cover 90% of “apps did not come back” tickets. First, forgetting pm2 save<\/code> after adding a new app \u2014 the dump is stale, and only the previously-saved apps resurrect. Second, permission issues on ~\/.pm2<\/code> \u2014 running pm2 startup<\/code> as root but then running apps as another user creates the wrong dump path. Third, database or Redis unreachable at boot \u2014 the app crashes on startup because its dependency is not yet ready; fix with Requires=<\/code> and After=<\/code> in the PM2 systemd unit. For deeper context, see the official PM2 startup documentation<\/a>.<\/p>\n\n\n\n

Conclusion: Production Node.js on UK VPS<\/h2>\n\n\n\n

PM2 Resurrect turns a Node.js app from a fragile foreground process into a boot-resilient production service. Three commands \u2014 pm2 start<\/code>, pm2 save<\/code>, pm2 startup<\/code> \u2014 and every reboot brings every service back automatically. Pair with UK Speed’s fast NVMe storage and premium network, and your Node.js stack matches managed hosting reliability at a fraction of the cost.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

PM2 Resurrect UK VPS is the two-command trick every Node.js developer needs to know before shipping to production, because a single unplanned reboot can\u2026<\/p>\n","protected":false},"author":3,"featured_media":2242,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[105],"tags":[299,143,147,61,146,145,113,136,140],"class_list":["post-2234","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorials","tag-backup","tag-database","tag-docker","tag-hosting","tag-linux","tag-nvme","tag-performance","tag-ssl","tag-vps"],"_links":{"self":[{"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2234","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=2234"}],"version-history":[{"count":1,"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2234\/revisions"}],"predecessor-version":[{"id":2241,"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2234\/revisions\/2241"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/media\/2242"}],"wp:attachment":[{"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=2234"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=2234"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ukspeed.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=2234"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}