Node.js Command Cheat Sheet: Essential Commands 🟢

Bookmark this one. A Node.js command cheat sheet is the thing you want open in a second tab when you're mid-build and can't remember whether it's npm update or npm outdated that tells you what's stale. This page covers the three command families that matter — node, npm, and npx — with copy-ready syntax, real examples, and the troubleshooting bits nobody includes.

Here's the short version:

• node -v — check your Node.js version
• npm -v — check your npm version
• node app.js — run a JavaScript file
• npm init -y — create a package.json instantly
• npm install <package> — install a dependency
• npm run <script> — execute a package.json script

What this Node.js commands cheat sheet includes

This isn't a tutorial. It's a reference. Everything is grouped by the task you're actually trying to finish — check a version, install something, run a script, debug a crash, fix a broken PATH.

Who it's for

Junior backend devs, students, technical founders, and sysadmins who inherited a Node app and now have to keep it alive. If you already know what Node.js is and have it installed, you're ready.

Before you start

• Node.js installed — if not, follow how to install Node.js and npm first
• A terminal: Bash, zsh, PowerShell, or Command Prompt
• npm and npx (both ship with Node — you don't install them separately)
• Admin/sudo rights if you plan on global installs
• A project folder with a package.json for anything npm-related

One caveat: flags change between major Node versions. The --watch flag, for instance, only became stable in Node 20+. If a command here throws an error, check your version before assuming a typo.

Node vs npm vs npx commands explained

This is where most confusion starts, so let's kill it early.

Rough rule of thumb: if you're running your own code, it's node. If you're managing someone else's code, it's npm. If you want to use someone else's tool once and never think about it again, it's npx. And yes, npx is essentially an alias for npm exec these days — same underlying mechanism, shorter to type.

Wondering whether npm is even the right package manager for you? That's a separate rabbit hole — see npm vs Yarn vs pnpm.

Basic Node.js CLI commands every developer should know

These are the ones you'll type hundreds of times.

If you memorize five things today, make it these: node -v, node app.js, node, npm init -y, npm install. Everything else you can look up.

Node.js version commands and environment checks

Version mismatches cause more "it works on my machine" incidents than any bug I've debugged. Check first, blame later.

That process.platform trick is underrated. When a cross-platform build script misbehaves, it tells you exactly which branch Node thinks it's on. For deeper coverage there's a full guide on how to check your Node.js version, and if you need the host details too, the OS version via command line guide pairs nicely.

npm commands cheat sheet for package management

This is the section you'll come back to most. I've grouped it by task rather than alphabetically, because nobody thinks alphabetically at 11pm.

Pro tip: in CI pipelines, use npm ci instead of npm install. It deletes node_modules, installs exactly what the lockfile says, and fails loudly if package.json and package-lock.json disagree. Deterministic builds, every time.

The local-vs-global distinction trips people up constantly. Local packages live in your project's node_modules and get committed to package.json. Global packages live once on your machine and are almost never what you want — more on that shortly. Related reading: check npm version, update npm, and install npm on Ubuntu.

npx commands for running packages without global installs

npx downloads a package, runs its binary, and doesn't leave it cluttering your system. That's it. That's the pitch.

Order of resolution matters: npx checks your local node_modules/.bin first, then the npm registry. So if eslint is already a devDependency, npx uses that copy — not a fresh download. That's exactly the behaviour you want in a team repo where everyone must run the same linter version.

package.json script commands with npm run

Scripts are where daily work actually happens. Here's a realistic block:

{
  "scripts": {
    "start": "node server.js",
    "dev": "node --watch server.js",
    "build": "webpack --mode production",
    "test": "jest",
    "lint": "eslint ."
  }
}

And the commands that drive it:

• npm start — shortcut for the start script
• npm test — shortcut for the test script
• npm run dev — any custom script needs run
• npm run build — production bundle
• npm run — lists every available script
• npm run build -- --watch — passes flags through to the underlying tool
• npm run lint --silent — suppresses npm's own log noise

That double dash catches everyone once. Without it, npm swallows the flag instead of forwarding it. And if you're dropped into an unfamiliar repo, plain npm run is the fastest way to see what the previous developer built. Faster than opening package.json, honestly.

Node.js REPL and debug commands

Type node with no arguments and you're in the REPL — a live JavaScript scratchpad.

Warning: never leave the inspector port exposed on a production server. It grants full code execution. Bind it to localhost and tunnel over SSH if you genuinely need remote debugging. Memory-hungry apps are also worth pairing with server-side tuning — see how to improve VPS performance and optimize Linux performance.

Common Node.js command mistakes to avoid

• Mixing node and npm. There's no such thing as node install. Runtime commands and package commands are different tools.
• Installing everything globally. Global packages drift out of sync with projects and break when Node updates. Keep tools local, use npx for one-offs.
• Running npm commands outside the project root. If there's no package.json in the current directory, npm walks up the tree and may install into the wrong place — or your home folder.
• Ignoring engine mismatches. A package requiring Node 20 will fail in weird, unhelpful ways on Node 16. Check how to update Node.js when that happens.
• Using npm install in CI. It can silently upgrade transitive dependencies. Use npm ci.
• Committing node_modules. Just don't. That's what the lockfile is for.

How to fix "node: command not found" and version mismatch errors

NVM is the cleanest long-term answer. It installs Node per-user, avoids sudo entirely, and lets you switch versions per project with a single command. Start with install NVM on Ubuntu. For npm-specific breakage, there's a dedicated walkthrough on how to fix the npm command not found error.

Running Node.js apps on a VPS

Sooner or later, localhost stops being enough. Your app needs to stay up when your laptop lid closes.

That's the moment a VPS earns its keep. Root access means you install what you need without asking permission. Persistent processes mean PM2 keeps your app alive through crashes and reboots. Isolated resources mean a neighbour's traffic spike doesn't tank your response times. Add Nginx as a reverse proxy, deploy via Git over SSH, and you've got a production setup that costs less than a couple of coffees a month.

The typical stack: SSH in, clone your repo, run npm ci, start with PM2, put Nginx in front for TLS. Start with how to connect to a VPS, then follow the guide on how to deploy your Node.js application on a VPS.

Ready to run your Node.js app beyond localhost?

MonoVM's Node.js VPS hosting gives you full root access, NVMe storage, and a developer-friendly Linux environment across multiple global locations. Prefer a blank canvas? A general Linux VPS works just as well, and 24/7 support is there when a deployment goes sideways at 2am.

Keep this cheat sheet handy

Bookmark it, print it, share it with whoever on your team keeps typing node install. Once these commands are second nature, the natural next step is shipping — and a Node.js VPS is the shortest path from localhost to a live URL.

More cheat sheets worth keeping close: the Linux commands cheat sheet and the Docker cheat sheet.