Question
NuxtJS Nitro server concurrency behavior without external process managers
Sky Moss
0 reputation · 17 Jun 2020, 00:37 UTC
45.5K views1
Loading…
0 reputation · 17 Jun 2020, 00:37 UTC
Nuxt 3's Nitro server runs as a single Node.js process by default, sharing one event loop across all incoming requests. When page logic in asyncData, fetch, or server middleware performs CPU-intensive work, that work blocks the event loop and latency grows only when multiple requests arrive concurrently.
The framework does not automatically spawn worker processes or provide a built-in cluster mode; scaling is left entirely to the deployment platform (PM2, Docker, Kubernetes, etc.). This creates a gap between local development, where concurrency is low, and production, where the same single-threaded process must handle burst traffic.
asyncData workloads?Nuxt 3’s Nitro server starts as a single Node.js process with one event loop. All requests share that loop, so any synchronous or CPU‑intensive work in asyncData, useFetch, or server middleware blocks the loop and adds latency for concurrent requests.
The single‑process model becomes a problem when the average CPU time per request is high enough that the event loop cannot keep up with incoming connections. There is no universal numeric threshold; the point at which latency spikes depends on the ratio of CPU‑bound work to I/O‑wait in your specific asyncData or middleware logic.
nuxtjsnitro.config.ts workers option only affects static‑asset generation and dev server tasks, not runtime request handling.nodeCluster exist for local testing but are marked unstable and not recommended for production.npm run buildnode .output/server/index.mjsautocannon -c 20 -d 15 http://localhost:3000
Observe the latency metrics. If p99 latency grows sharply with concurrency while system CPU shows idle cores, the single event loop is the bottleneck.
To decide whether you need an external process manager or can rely on caching strategies, confirm whether your asyncData/middleware workload is primarily CPU‑bound (heavy computation) or I/O‑bound (waiting for databases/APIs). This detail changes the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 17 Jun 2020, 05:08 UTC
The default Node preset in Nitro creates a standard http server that runs inside a single Node.js process and shares one event loop across all requests. Because there is no built‑in cluster or worker‑pool logic, the only way to utilise multiple CPU cores without relying on an external process manager is to wrap the generated server with Node’s native cluster module yourself (e.g., by creating a custom server/index.js that forks workers and forwards requests). This approach mirrors what tools like PM2 do internally, but it must be implemented manually in your Nuxt project if you want to avoid third‑party managers.