PRNext sleep mode: reduce idle RAM and manage wake-up

#What stays running during sleep

In the mechanism measured here, the Rust server keeps listening while Node workers retire after an idle interval. The next request requiring rendering recreates the needed workers. This differs from stopping the VPS or suspending the operating system.

The local prnext host command can also sleep an entire application behind a gateway. The managed PRNext Host service is another layer again. The values here describe application-server worker retirement, not the total cost of those other mechanisms.

#What the wake-up probe shows

On the small VPS in the October 29 campaign, a simple SSR page was tested with an accelerated two-second idle interval. After workers retired, process-tree PSS fell to about 10.5 MiB. Keeping workers warm used 106.8 MiB in that probe.

The wake-up request took about 1,130 ms, compared with 22.6 ms when warm. Each setting had only one observation. The probe used the identified development candidate, not a new measurement of the final npm package or the whole VPS. These values illustrate the tradeoff without predicting your application.

Read the probe, candidate identity and measurement conditions

#Keep workers warm when latency matters most

After building, --prewarm prepares the framework before accepting requests. It does not execute application pages or APIs and does not prevent later idle retirement. --worker-idle-seconds 0 retains used rendering hosts instead of retiring them for inactivity.

The following command requests prepared startup and retains workers once used. It does not promise that a never-visited route has loaded every dependency. Measure the first visit to expensive routes and behavior after deployment as well.

npx --no-install prnext build
npx --no-install prnext start --hostname 127.0.0.1 --port 3001 --prewarm --worker-idle-seconds 0

#Test an explicit idle interval

An explicit 60-second interval makes the cycle easy to observe on an isolated instance. Visit the page, wait for workers to actually retire and measure the next request. Sixty seconds is an example setting, not a recommendation for every site.

A health probe that continually requests a rendering route can prevent sleep. Check what monitoring requests and how the server handles it. Also test several visits arriving during one wake-up: a single request does not describe that peak.

npx --no-install prnext start --hostname 127.0.0.1 --port 3001 --worker-idle-seconds 60

#Keep durable data outside the process

Retiring a worker removes its in-memory state. Sessions held only in that process, application caches and background work can disappear. Data that must survive needs durable storage or a suitable external service.

Before enabling sleep, test login, a write and a read after wake-up. Check subscriptions, timers and asynchronous work too. A completed request does not prove that untracked background work is protected from process retirement.

#Choose from your application’s idle periods

Demos, preview environments and occasionally visited tools are candidates to investigate. For journeys where the first response needs to remain fast, warm workers may be preferable. Real traffic, monitoring probes and wake-up frequency determine the result.

Compare time asleep, released memory and latency for visits that wake the service. For multiple applications, measure concurrent peaks before concluding that one server can host more projects. Our campaign establishes neither an additional site count nor a billing saving.

Budget for multiple React applications on a VPS