Skip to content

The Nx Daemon is a background process that watches workspace files and keeps project graph data in memory. Each workspace starts its own daemon process, so multiple workspaces can use different Nx versions without sharing daemon state.

Nx needs the project graph before it can run targets or calculate affected projects. Rebuilding the entire graph for every command becomes expensive as a workspace grows.

The daemon watches for file changes and updates the graph incrementally. Because it already knows which files changed and retains graph state in memory, subsequent Nx commands can request an up-to-date graph without starting the analysis from scratch.

The daemon shuts down after 3 hours without requests or file changes. Run nx reset to stop it manually and clear other Nx workspace state.

The daemon is enabled by default on local development machines. Disable it for a workspace by setting useDaemonProcess in nx.json:

{
"useDaemonProcess": false,
}

Set NX_DAEMON=false to disable it for one command or environment. The environment variable takes precedence over nx.json.

Terminal window
NX_DAEMON=false nx show projects

Nx disables the daemon by default in CI, containers, sandboxed environments, and WebAssembly environments where its persistent state or file watching isn't useful. Set NX_DAEMON=true to opt in when a supported long-running environment can reuse the process.

Run nx daemon to print the daemon process ID and log file path. Open the file in your IDE or stream it from another terminal:

Terminal window
nx daemon
tail -f <daemon-log-path>

Nx places the Unix socket in a temporary directory by default. Set NX_DAEMON_SOCKET_DIR when multiple long-running containers need to access a shared daemon socket:

Terminal window
NX_DAEMON_SOCKET_DIR=<shared-directory> nx daemon

The containers must share the directory, workspace files, Nx version, and compatible file-system permissions. Ephemeral CI containers should keep the daemon disabled.

Nx automatically disables the daemon in Docker containers, CI environments, and sandboxed AI-agent environments. The daemon's performance benefits come from maintaining state between commands and watching for file changes. In ephemeral environments where each command runs in a fresh container, this state cannot be reused, so the overhead of starting a background process provides no benefit.

A persistent development container can benefit from the daemon, but check these constraints before enabling it:

  • Volume mounts can change file metadata in ways that affect file watching.
  • Container restarts invalidate the daemon socket.
  • Host and container permission differences can block socket access.