Node.js Cluster Module

How it works

This fixture starts one owned worker only, receives a readiness message and waits for its exit. It exercises the actual cluster API without binding a public listener or claiming multi-core throughput. A deployed cluster needs a worker-count budget, failure/restart policy, connection-drain behaviour and persistent state outside ordinary process globals. Container or service managers may provide a different process-scaling boundary.

Run the code

Run this example locally with Node.js. The exact sources are reviewed on Node 22.15.1 and Node 24.22.1 unless a specialised lab states otherwise. Save the complete source as cluster.mjs in a separate empty exercises folder and run node cluster.mjs. There is no Node.js browser runner on Bhylu; the plain JavaScript playground does not provide these filesystem, server or process APIs.

Download the complete source. Ordinary Node scripts need no Apache, PHP or MySQL service. File examples own their temporary folders; network fixtures use loopback and available temporary ports.

Example

import cluster from 'node:cluster';
import { fileURLToPath } from 'node:url';
import { once } from 'node:events';
if (cluster.isPrimary) {
  cluster.setupPrimary({ exec: fileURLToPath(import.meta.url), silent: true });
  const worker = cluster.fork();
  const exited = once(worker, 'exit');
  const [message] = await once(worker, 'message');
  const [status] = await exited;
  console.log(message.ready, status);
} else {
  process.send({ ready: true }, () => process.disconnect());
}

Expected result

true 0

The primary observes one real worker lifecycle. The message is a controlled IPC value, not proof that a database is ready or a public load balancer has registered the instance. No unrelated Node process is stopped by this example.