PM2 Reloads Nobody Feels: Next.js With Zero Downtime

Deploys that kick users off

You ship a one-line fix at noon. For eleven seconds the store returns 502s.

A customer mid-checkout refreshes, sees an error and never comes back.

The deploy "worked". PM2 restarted the app with the new code. But a restart kills every worker first and boots replacements after.

An eleven-second hole where your business does not exist.

Close it. Reload, not restart. And a cluster config most tutorials skip.

Restart, reload or redeploy

Restart turns an annoyance into lost revenue. Three reasons.

Next.js boots slowly. A production server warms routes, connects the database and compiles on first hit. Eleven seconds of boot is normal. Eleven seconds of dead workers is the bill.

Checkouts overlap deploys. Payment webhooks and multi-step forms outlive any deploy window. Killing a worker mid-webhook turns a 200 into a retry storm.

Crashes cascade the same way. Without restart limits, one bad setting crash-loops every worker at once.

Serverless platforms hide all this behind per-request pricing. A little PM2 configuration buys much of the same behavior at a flat price.

What to do

Know what the default gives you.

BoringPush runs your app under PM2, which restarts it if it crashes and brings it back after a reboot. Every deploy ends in a reload, not a hard restart.

The kit's default runs one app process.

A reload on a single process still has a short moment where the old one is going away and the new one is booting.

For most small apps that gap is brief.

For checkout-heavy apps it is worth closing.

Close the gap with two workers.

Run the app in PM2's cluster mode with two instances. Tell PM2 to wait until each worker says it is ready.

A reload then reboots one worker while the other keeps serving. BoringPush does not turn this on for you, so it is a change you make on your server.

Two instances fit a 2GB box with room left for the database. On a 1GB box, add swap and expect slower boots.

Prove it with a load loop.

In one terminal, request your site every fraction of a second and print the status code. In another, trigger a reload.

The first terminal must print 200 without a single gap. If a line drops, the worker is not signalling ready or the health route is misconfigured. Fix it once and every future deploy inherits the proof.

How bp deploy fits

bp deploy swaps the new build in, reloads the app and waits until the new build is serving before it declares success. If it never serves, the old build is put back.

One command, and the reload story composes with it.

The cost

Cluster mode doubles baseline memory. A rolling reload is slower than a mass restart, by design.

On the smallest servers that trade-off bites. Speed of deploy is vanity. Continuity of checkout is money.

Know this first

The default runs one process. A reload on one process has a short gap. Cluster mode needs setup on your side, and it doubles memory.

On the smallest boxes, that bites.

Why BoringPush is the way to do this

Ship at noon. Nobody notices.

BoringPush runs your app under PM2, brings it back after a reboot and reloads it on every deploy. bp deploy waits until the new version is serving.

A bad release is put back.

FAQ

Does zero-downtime reload work for websocket or SSE routes?

Rolling reloads drain normal HTTP requests cleanly, but long-lived connections on a worker that is going away get cut when its shutdown time expires. Raise that limit past your longest stream, or keep realtime traffic on a separate process.

Why not just restart at 3 a.m. when nobody visits?

Because "nobody" is a guess and webhooks do not sleep. Payment providers retry at whatever hour they please. A reload behaves the same at noon and midnight.

How many instances should a $5 VPS run?

Two. One leaves no cover during a rolling reboot.

Two gives cover with headroom for SQLite and the operating system on a 2GB box. On 1GB, run two with swap, or accept slower boots.

What restarts a crash-looped app before I wake up?

PM2 restarts crashed processes by itself, and you can cap restarts so a bad setting does not churn forever. BoringPush's Telegram and Discord alerts cover critical failures. Auto-restart plus a human alert beats either alone.

Do I need PM2 Plus for any of this?

No. Cluster mode, reload, saving the process list and starting on boot are all in the free, self-hosted PM2. Paid dashboards add graphs, not continuity.

How does this interact with bp deploy?

bp deploy swaps the new build in, reloads the app and waits until the new build is serving before it declares success. If it never serves, the old build is put back. One command, and the reload story composes with it.

Keep reading

• git push production deploy: Skip the 9-Minute CI Queue — the hook this reload line lives in
• Next.js 'Killed' on 1GB VPS? The 5-Minute Swapfile Fix — the memory companion for small boxes
• Deploy Next.js on Hetzner $5 by Dinner Tonight — the full afternoon build, start to finish