Pin the Node.js version for a deploy: put the major in engines.node.

The same repository can build on three different Node versions depending on where you push it. This is what each platform documents, highest priority first.

Pin a major: 24.x. A major gets security patches without surprising you. An exact version like 24.11.0 freezes you on old patches where the platform allows it, and many platforms only offer majors anyway. An open range like >=18 has no ceiling, so the day a platform adds a new major, your build may move to it. Heroku’s docs give the same advice.

Keep .nvmrc if your team uses nvm or fnm, but treat it as a local convenience and keep it equal to engines.node. When the two disagree, the platform reading one and your laptop reading the other is how “works locally” builds fail.

// package.json: the file deploy platforms read
{
  "engines": { "node": "24.x" }
}

# .nvmrc: for nvm and fnm on your machine (Canner ignores it)
24

Canner reads engines.node from the package.json in your project’s root directory and compares it with the project’s Node.js version setting (Settings, default Node 22). It only compares majors. Each case prints its own line in the build log:

• No `engines.node`: the setting is used. The log shows [canner] node version: 22.
• The setting satisfies the range: the setting is kept. >=18 stays on Node 22 rather than jumping to 24, so a broad range never moves a working project to a new major.
• The setting doesn’t satisfy it: Canner takes the newest major it offers that does, and says so: [canner] package.json engines.node="^24" isn't satisfied by Node 22; building on Node 24.
• Nothing satisfies it: the build stops before installing: package.json engines.node="20.x" needs a Node version Canner doesn't offer (available: 24, 22). Widen or remove engines.node, or set the project's Node version and turn on "force". The same happens with 26.x, Vercel’s current default.
• The range can’t be read: Canner keeps the setting and notes Couldn't read engines.node="…". A range with an upper bound written as <= is one example; write >=18 <23 instead of >=18 <=22.
• Minor versions are not compared. >=22.17 counts as satisfied by Node 22. If a dependency needs a recent minor, choose Node 24.

Sometimes a dependency declares a range your app doesn’t really need, or you want to test a major before changing package.json. The API has a node_version_forced field on the project: with it on, Canner builds on the setting and logs engines.node="…" ignored — this project pins Node 22. There is no dashboard switch for it yet.

# Use the project's version and ignore engines.node
curl -X PATCH https://api.canner.ca/v1/projects/my-app \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"node_version": "24", "node_version_forced": true}'

• The platform reads a different file than you edited. Netlify and Render read .nvmrc; Heroku documents only engines, and Canner doesn’t read .nvmrc. Check the table above.
• A higher-priority source wins. On Render or Netlify, a NODE_VERSION variable set long ago in the dashboard beats your new .nvmrc.
• The file is in the wrong directory. In a monorepo, the platform reads the package.json of the directory it builds. On Canner that is the project’s Root directory.
• npm doesn’t enforce `engines`. Unless engine-strict is set, npm treats the field as advisory and only warns. Whether it changes the Node version is up to the platform, not npm.
• The major is end-of-life or not offered. Node 20 is end-of-life. A platform that dropped it either refuses the build or moves you up.