How to Check the Node.js Version: Three Commands That Work Everywhere and Why the Answer Still Matters in Production

Q: What is the difference between node -v and node --version?

Nothing functionally — they print the same Node version. node -v is the short form, node --version is the long form. Use whichever reads better in your shell history and your scripts.

Q: How do I check the Node version from inside a script?

Read process.versions.node from the Node API. It returns a string like '22.11.0'. The full process.versions object also includes V8, libuv, and OpenSSL versions, useful for native module debugging.

Q: How do I check the Node version on a remote server?

SSH in and run node -v. If the service is in a Docker container, check the FROM line of the Dockerfile. If the service is on a PaaS, check the platform's dashboard or CLI for the runtime version, or hit any health or metadata endpoint the platform exposes.

Q: How do I check which Node version a Docker image uses?

Look at the FROM line in the Dockerfile. FROM node:22 uses Node 22, FROM node:20-slim uses the slim variant of Node 20. The Node in the image is fixed at build time; updating it requires rebuilding the image.

Q: Does nvm current show the same thing as node -v?

Yes, when the current shell is using the nvm-managed Node. On a system with two Node installations, they can differ — nvm current shows the nvm one, node -v shows whichever wins the PATH race.

To check the Node.js version, run node -v (or the long form node --version) in the shell. Inside a script or running app, read process.versions.node. On a remote server, SSH in and run the same command, or hit the platform’s runtime metadata endpoint if it has one. That is the whole answer for the question as written. The reason the question keeps getting asked is that there is a second question hiding under it: which Node is the one my code is actually running on right now? That one is more interesting, and it is the one that catches teams on deploy day.

This post covers both. The first half is the three commands that cover every case. The second half is why the version on a running service is often not the version the developer expects, and how to find out for sure.

The interesting thing about “check Node version” is that it is one of those questions where the simple answer is correct, but the questioner is usually asking something else. The thing they actually need is usually “is this the version I built against?” — and that is a different problem with a different answer.

The direct answer
The three commands that work everywhere
Inside a running app: process.versions
The version you have versus the version you are running
Why a PaaS report the wrong version
Finding the Node version on a remote server
The opinion this post is built on
FAQ

The direct answer

Open a terminal and run:

node -v
# or
node --version
# or
nvm ls           # if you use nvm, lists all installed versions
nvm current      # the version the current shell is using

That prints something like v22.11.0. That is the version the shell sees, which is the version any command the shell runs will use. If you want to check from inside a Node process:

console.log(process.versions.node); // '22.11.0'
console.log(process.versions);     // full version object

The interesting failure mode is when node -v in the terminal returns one version and the running service returns another. That is a real thing, it happens in production, and it is almost always a sign that the deploy is using a different Node than the one the developer is testing against.

The three commands that work everywhere

node -v is the one to remember. It is short, it is in every Stack Overflow answer, and it works in every shell. If node is not on the PATH, the command fails with command not found, which is itself useful information — it means the binary is not installed or is not in the current PATH. Either way, the developer knows what to do.

node --version is the long form of the same thing. Some shells and some scripts prefer the long form because it reads more clearly in logs. The output is identical. If you find yourself writing a script that checks Node, the long form is the more polite choice because the next person reading the script will understand it without a translation.

nvm current (or fnm current, or volta list node) is the version manager’s view. It tells you which version the manager is pointing at, which is the version the shell sees. This is the most useful answer on a development machine because it answers both “what is installed?” and “which one am I using right now?” at the same time.

For a one-shot check on a server, node -v is enough. For a thorough audit, run all three. The triple-check takes ten seconds and catches the case where two Node versions are installed and the shell is using the wrong one.

Inside a running app: process.versions

process.versions is the Node API for asking “what runtime am I in?” The full object looks like:

{
  node: '22.11.0',
  v8: '12.4.254.21',
  uv: '1.51.0',
  zlib: '1.3.0.1-motley',
  brotli: '1.1.0',
  ares: '1.34.4',
  modules: '127',
  nghttp2: '1.64.0',
  napi: '10',
  llhttp: '9.2.1',
  openssl: '3.0.15+quic',
  cldr: '46.0',
  icu: '76.1',
  tz: '2024b',
  unicode: '16.0'
}

The Node team exposes this on purpose. It is the most reliable way to check the runtime from inside code, and it is the answer to the question “is this running in the version the package.json expects?” — at least on the Node major. For the patch version, the same field is the source of truth.

A useful pattern: log process.versions to a health check or to a startup log line. Then, when the version is wrong in production, the answer is on the page, not in a Slack thread.

// In a FastAPI-like startup hook or a /health route
app.get('/runtime', (req, res) => {
  res.json({
    node: process.versions.node,
    v8: process.versions.v8,
    platform: process.platform,
    arch: process.arch,
    uptime: process.uptime(),
  });
});

This is also how a deploy platform can expose the runtime version over HTTP without the developer having to SSH in. A platform that surfaces /runtime or a similar metadata route is one less guess to make when the deploy is misbehaving.

The version you have versus the version you are running

This is the question the searcher is usually actually asking. The shell says one thing, the deploy says another, and the engineer is stuck in the middle.

The pattern is consistent:

Developer runs node -v locally and sees v22.11.0.
Developer commits, pushes, deploys.
Service crashes with SyntaxError: Unexpected token '?' or some other feature-not-supported error.
Engineer SSHes into the deploy (if they can), runs node -v, sees v18.19.1.

What happened: the deploy is using the platform’s default Node version, not the one from the project’s .nvmrc. The build succeeded because npm installed the packages on Node 22, but the runtime that actually runs the service is Node 18, because nobody told the platform which Node to use.

The fix is to set the Node version on the deploy. Most platforms let you do this in three ways: a package.json engines field (a hint, not a rule), a .nvmrc file in the project root (a stronger hint), or a platform-specific setting in the dashboard or config file (a rule). Only the last one is actually enforced.

A platform that reads .nvmrc and pins the deploy runtime to it makes this class of bug structurally impossible. A platform that ignores both files and uses a default runtime that has not changed in two years makes it a regular event.

Why a PaaS report the wrong version

The most common reason is that the platform has a default runtime that the developer never overrode. The second most common is that the platform changed the default underneath the project. The third is that the platform is using one runtime for the build and a different one for the runtime, and the developer assumed they would match.

The fix path is the same in all three cases: ask the platform which Node is running, then make sure the answer is the one the project expects. If the platform does not expose that information clearly, the engineer is debugging blind, and that is a problem with the platform, not with the project.

For a deeper look at the version-manager side of the same problem, the guide to updating Node covers how to pin the version in the first place.

Finding the Node version on a remote server

If the deploy is on a VM you control, SSH in and run the same command:

ssh user@server 'node -v'

If the deploy is a Docker container, the Node version is whatever is in the FROM line of the Dockerfile:

FROM node:22-slim
# or
FROM node:20-alpine

The Node in the container is the Node in the image, period. The host’s Node does not matter. The build’s Node does not matter. The Node that runs the service is the one in the image.

If the deploy is a PaaS, the version is whatever the platform decided to use. The fix is to set it explicitly in the platform’s config. If the platform does not let you set it, the engineer’s only real option is to leave, because the next Node version bump will be a surprise outage.

A useful last-resort check: hit any health or metadata endpoint the platform exposes. Some platforms show the runtime version in the dashboard, others in a CLI command (platform runtime, service info, etc.), and others only in the build logs. Whichever path exists, use it. Do not deploy a service that does not let you ask the question “which Node is this?”

The opinion this post is built on

The interesting thing about “how to check Node version” is that the simple answer has not changed in a decade. node -v worked on Node 0.10 and it works on Node 22. The reason the question is still asked is not the command — it is the disconnect between the developer’s machine and the production service. The command answers the first question. The platform answers the second.

A platform that pins the runtime version, surfaces it in the dashboard, exposes it on a health endpoint, and rebuilds the deploy when the version changes is a platform where this question becomes a non-question. A platform that hides the runtime version, ships a different Node from the one it built with, and changes the default without notice is a platform where this question is asked weekly.

The right answer to “how do I check the Node version” is “the same way I check everything else in production: through a path the platform exposes, with a value I trust, against a value the project declares.” When that path exists, the question is solved. When it does not, no amount of node -v will save the engineer from the next incident.

If the next deploy is the one where this matters, the hosting cost calculator is a good way to see what the platform costs against what it returns. The right answer is rarely the cheapest; the right answer is the cheapest that exposes the things you need to see.

FAQ

What is the difference between `node -v` and `node --version`?

Nothing functionally — they print the same Node version. node -v is the short form, node --version is the long form. Use whichever reads better in your shell history and your scripts. Both work on macOS, Linux, and Windows.

How do I check the Node version from inside a script?

Read process.versions.node from the Node API. It returns a string like '22.11.0'. The full process.versions object also includes the V8 version, the libuv version, and the OpenSSL version, which can be useful when debugging native module issues.

How do I check the Node version on a remote server?

SSH in and run node -v. If the service is in a Docker container, check the FROM line of the Dockerfile — the Node in the container is the Node in the image, and the host’s Node is irrelevant. If the service is on a PaaS, check the platform’s dashboard or CLI for the runtime version, or hit any health or metadata endpoint the platform exposes.

Why does the deploy report a different Node version than my local machine?

Because the deploy is using the platform’s default Node version, not the one from your .nvmrc or engines field. The fix is to set the Node version explicitly in the platform’s config. A platform that reads .nvmrc and pins the deploy runtime to it makes this class of bug impossible.

How do I check which Node version a Docker image uses?

Look at the FROM line in the Dockerfile. FROM node:22 uses Node 22, FROM node:20-slim uses the slim variant of Node 20, FROM node:lts-alpine uses whatever the current LTS is on Alpine. The Node in the image is fixed at build time; updating it requires rebuilding the image.

Does `nvm current` show the same thing as `node -v`?

Yes, when the current shell is using the nvm-managed Node. nvm current shows which version nvm is pointing at. node -v shows which node the shell is running. On a well-set-up nvm install, they will be the same. On a system with two Node installations, they can differ — nvm current shows the nvm one, node -v shows whichever wins the PATH race.