How do you run Node.js processes as a background service?

Q: How do you run Node.js processes as a background service?

**Target Audience:** Engineers preparing for Node.js/DevOps phone screens — assumes very basic `child_process`/Unix process familiarity. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The detached-process survival below was **actually run** on this machine, with a real log file confirming the child kept working after its parent had already exited. ## 1. Why This Even Matters — A Story First A contractor working inside someone's house while the homeowner is present is naturally bound to that visit — when the homeowner leaves and locks up, the contractor leaves too, work half-finished or not. A contractor with their own key, who was explicitly told "keep working after I leave, I do not need to supervise you directly," is a fundamentally different arrangement — the work continues independently of whether the person who started it is still around. Running `node server.js` in a terminal i

The problem

Question presented to candidate: "You start a Node app with 'node server.js' in a terminal, close the terminal, and the app stops. What is actually happening, and what changes to make it run as a real background service?"

What a strong answer should cover:

Running node server.js directly in a terminal ties the process's lifetime to that shell session by default — closing the terminal (or the SSH session) sends a signal that terminates the child process along with it, which is why the app "stops" in the prompt's scenario.
📌 The underlying mechanism, demonstrable directly: a child process spawned with { detached: true } and then .unref()'d genuinely survives its parent process exiting — this is the real OS-level capability every "run in the background" tool ultimately relies on, not magic.
In practice, hand-rolling detached/unref'd process spawning is rarely the right production answer — the standard tools exist specifically to add what raw detaching alone does not provide: automatic restart on crash, log management, and startup-on-boot integration.
pm2 is the most common Node-specific process manager: it restarts a crashed process automatically, manages logs, and supports a cluster mode across CPU cores — a userland tool, not an OS-level mechanism.
systemd (on modern Linux) is the OS-level init system's own service-management mechanism — a unit file describes how to start the process, and systemd itself handles restart policy, boot-time startup, and log capture via journald, with no Node-specific tooling required at all.
A precise answer distinguishes these by layer: nohup/detached-and-unref'd spawning is the raw OS-level survival mechanism; pm2 is a userland process manager built on top of that idea with restart/monitoring logic added; systemd is the OS's own init-system-level equivalent, generally preferred in production specifically because it is already the thing supervising every other system service, rather than adding another separate supervisor layer.

Clarifying questions expected:

"Is this a bare VM/Linux host, a containerized deployment, or a managed platform (a PaaS)?" — the right tool differs a lot: a container orchestrator (Kubernetes, ECS) typically already provides restart/supervision, making an in-container process manager partially redundant.
"Does the team already standardize on one process-management approach elsewhere?" — consistency with existing infrastructure often matters more than the specific tool's feature list.

Code / implementation expected: Optional — actually demonstrating a detached, unref'd child surviving its parent's exit is a strong, concrete way to show the underlying mechanism rather than just naming tool brand names.

pm2
deployment
devops

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js/DevOps phone screens — assumes very basic child_process/Unix process familiarity. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The detached-process survival below was actually run on this machine, with a real log file confirming the child kept working after its parent had already exited.

1. Why This Even Matters — A Story First

A contractor working inside someone's house while the homeowner is present is naturally bound to that visit — when the homeowner leaves and locks up, the contractor leaves too, work half-finished or not. A contractor with their own key, who was explicitly told "keep working after I leave, I do not need to supervise you directly," is a fundamentally different arrangement — the work continues independently of wheth

The solution is hidden so you can try first

7 min read · 9 sections

Read the code

JavaScriptA real detached, unref'd child process outliving its parent, confirmed by a log file written after the parent exited

// bg-worker.cjs — the actual background work
const fs = require("fs");
let n = 0;
setInterval(() => {
  n++;
  fs.appendFileSync("bg-worker.log", `tick ${n} at ${Date.now()}\n`);
  if (n >= 3) process.exit(0);
}, 300);

// bg-spawner.cjs — the parent, which exits immediately
const { spawn } = require("child_process");
const child = spawn(process.execPath, ["bg-worker.cjs"], {
  detached: true,
  stdio: "ignore",
});
child.unref();
console.log("parent exiting immediately, child pid was", child.pid);
// process exits right here — the child keeps running independently

// $ node bg-spawner.cjs
// parent exiting immediately, child pid was 8768
// (parent has fully exited)
// $ cat bg-worker.log
// tick 1 at ...
// tick 2 at ...
// tick 3 at ...

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.