NodeJSAuto-Restart with nodemon

Auto-Restart with nodemon

When you change a file, a running Node process doesn't notice — you have to stop it and node app.js again, every single time. nodemon ("node monitor") removes that friction: it watches your project files and automatically restarts the process whenever something changes, so your save-and-see loop is instant. It's a development-only tool, configurable in which files it watches and what it ignores, and it's one of the first things most Node developers install. This page covers running it, configuration, watch/ignore rules, the modern built-in alternative (node --watch), and why it must never run in production.

Running nodemon

Bash
npm install --save-dev nodemon

npx nodemon app.js          # like 'node app.js', but restarts on file changes
# Edit & save any watched file → nodemon restarts the process automatically.
[nodemon] 3.x.x
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,cjs,json
[nodemon] starting `node app.js`
[nodemon] restarting due to changes...
[nodemon] starting `node app.js`
`nodemon app.js` runs your app and restarts it on every file change — the core dev-loop convenience
Used in place of `node`, **`nodemon app.js`** starts your application *and* watches the project directory; the moment you save a change to a watched file it kills and restarts the process, so you never manually restart again. By default it watches the current directory recursively for `.js`, `.mjs`, `.cjs`, and `.json` files. You can also type `rs` + Enter in the terminal to force a manual restart. Install it as a **`devDependency`** and expose it through an npm script (`"dev": "nodemon src/index.js"`) so the whole team uses the same command. This tight feedback loop — edit, save, see the result — is what makes iterative server and script development pleasant.
Configuration — nodemon.json

nodemon.json

JSON
{
  "watch": ["src"],                       // only watch these paths
  "ext": "js,ts,json",                    // file extensions that trigger a restart
  "ignore": ["src/**/*.test.js", "dist"], // never restart for these
  "exec": "node --inspect src/index.js",  // the command to run on each restart
  "delay": "500"                          // debounce: wait 500ms after a change
}
A `nodemon.json` controls what to watch, which extensions trigger restarts, what to ignore, and the command to run
For anything beyond the defaults, drop a **`nodemon.json`** in your project root (or a `nodemonConfig` key in `package.json`). The useful knobs: **`watch`** narrows monitoring to specific paths (watch `src/` only — far cheaper than the whole tree), **`ext`** sets which file extensions count (add `ts` for TypeScript), **`ignore`** excludes paths so they never trigger a restart, **`exec`** customizes the launch command (e.g. add `--inspect` for the [debugger](/nodejs/node-inspector), or run through a TS loader), and **`delay`** debounces rapid bursts of saves into a single restart. Scoping `watch` and `ignore` properly is the main way to keep restarts fast and avoid pointless reloads from build output or test files.
nodemon with TypeScript

Bash
# Run TypeScript directly on each restart by combining nodemon with a TS runner:
npx nodemon --watch src --ext ts --exec "tsx src/index.ts"

# Though for TS, the built-in watch of tsx is usually simpler:
npx tsx watch src/index.ts
For TypeScript, point nodemon at a TS runner — or just use `tsx watch`, which already restarts on change
To use nodemon with [TypeScript](/nodejs/typescript-intro), tell it to watch `.ts` files and execute them through a TS runner: `nodemon --ext ts --exec "tsx src/index.ts"` (or `ts-node`). This works, but as the [ts-node & tsx page](/nodejs/ts-node-tsx) notes, **`tsx watch`** already bundles file-watching and restart-on-change, so for a pure-TypeScript project it's the simpler one-tool answer and you may not need nodemon at all. Reach for nodemon-plus-runner when you want nodemon's richer config (custom watch/ignore globs, delays, multiple commands) or already use nodemon for a mixed JS/TS project; reach for `tsx watch` when you just want "run my TS and restart on save" with zero config.
The built-in alternative — `node --watch`

Bash
# Node 18.11+ has watch mode built in — no dependency:
node --watch app.js                 # restart on change
node --watch-path=./src app.js      # restrict what's watched
Node 18.11+ ships `--watch` natively — for simple restart-on-change you may not need nodemon anymore
Recent Node versions (18.11+) include a native **`--watch`** flag that restarts the process on file changes with no dependency, plus `--watch-path` to scope it. For the common case — "restart my app when I save" — this can replace nodemon outright. nodemon still wins when you need its **richer configuration**: custom file-extension lists, glob-based ignore rules, debounce delays, running non-Node commands, or per-event hooks. So the practical guidance mirrors the dotenv/`--env-file` story: use the **built-in flag when it's enough**, and the **package when you need its extra control**. Either way the goal is identical — a fast, automatic dev loop.
Development only — never in production
nodemon is a dev tool — run compiled/plain `node` in production under a real process manager like PM2, not nodemon
nodemon (and `node --watch`) exist to speed up **development** and must never run your **production** process. Watching the filesystem for changes is wasted overhead on a server whose code doesn't change at runtime, an auto-restart on an unexpected file change is a reliability hazard, and nodemon's restart logic is *not* a process supervisor — it won't handle crashes, clustering, log management, or zero-downtime reloads. In production you run the app with plain `node` (the compiled output, for TypeScript) under a proper **process manager** like [PM2](/nodejs/pm2) or your platform's supervisor (systemd, Docker's restart policy, Kubernetes), which restart on *crashes*, run multiple instances, and manage logs and graceful shutdown. Keep nodemon in `devDependencies` and behind `npm run dev`; let production-grade tooling own the live process.
Next
Catch problems before they run by linting your code: [Linting with ESLint](/nodejs/eslint).