---
title: "Comment by Lakhyajit Changmai on \"The 7 Threads Running Inside Every Node.js Process\" | Hashnode"
description: "Helpful distinction between runtime helper threads and the libuv pool. One practical debugging trap: raising UV_THREADPOOL_SIZE will not move CPU-bound JavaScri"
url: "https://hashnode.com/posts/why-an-empty-nodejs-process-runs-7-threads/6af6d73a41060513e7d11ea0/comment/6af73fef3b7fa79a4a2fd181"
---

[Discussion](https://hashnode.com/posts/why-an-empty-nodejs-process-runs-7-threads/6af6d73a41060513e7d11ea0)

Comment [The 7 Threads Running Inside Every Node.js Process](https://hashnode.com/posts/why-an-empty-nodejs-process-runs-7-threads/6af6d73a41060513e7d11ea0)

[Lakhyajit Changmai](https://hashnode.com/@lakhyajit)

[4h ago](https://hashnode.com/posts/why-an-empty-nodejs-process-runs-7-threads/6af6d73a41060513e7d11ea0/comment/6af73fef3b7fa79a4a2fd181)

Helpful distinction between runtime helper threads and the libuv pool. One practical debugging trap: raising UV\_THREADPOOL\_SIZE will not move CPU-bound JavaScript off the event loop; it changes libuv’s pool capacity, while CPU-heavy work needs worker\_threads or a separate process. I’d also label any observed startup thread count with the exact Node and platform versions, since “seven” is an observation rather than a portable guarantee.