HubSpot CLI Node 20 support ends 8 January 2027

HubSpot CLI Node 20 support ends on 8 January 2027 — and the version HubSpot points you at is already in maintenance. Node.js 22 reaches its own end of life on 30 April 2027, 112 days after the cutoff. If your pipeline pins Node 20, you have two upgrades ahead of you, not one, and only the first has a date HubSpot will enforce.

The announcement is short. HubSpot published it on 19 October 2026 with a stated live date of 8 January 2027: "we are deprecating Node.js 20 from the HubSpot developer CLI starting on January 8, 2027." After that, "the developer CLI will require Node.js v22 or higher to run." That is 79 days from this writing.

HubSpot CLI Node 20 support ends on 8 January 2027: the facts

Fact	Value	Source
Announced	19 October 2026	HubSpot changelog
Live	8 January 2027	HubSpot changelog
Minimum Node after that date	Node.js v22 or higher	HubSpot changelog
Node.js 20 end of life	30 April 2026	Node.js release schedule
Node.js 22 end of life	30 April 2027	Node.js release schedule
Latest @hubspot/cli	8.16.0, published 7 October 2026	npm registry

Note the gap in the middle of that table. Node.js 20 — codename Iron — went end of life on 30 April 2026, nearly six months before HubSpot said anything. Teams pinned to it have been running an unsupported runtime since spring; the January date is HubSpot catching up to Node, not Node catching up to HubSpot.

Who breaks, and what HubSpot actually says

Read the changelog narrowly, because it is narrow. It names two groups: people running the developer CLI, and people using the HubSpot GitHub Action. It does not enumerate project types — it says nothing about private apps, UI extensions or developer projects by name. So the honest scope is this: anything you ship by invoking hs on a machine whose Node is pinned to 20, whether that machine is a CI runner or a laptop.

For CLI users, HubSpot's remedy is one command: "You can upgrade to the latest version of the developer CLI at any time by running: npm i -g @hubspot/cli@latest." Worth knowing that the published package has not moved yet — @hubspot/cli 8.16.0, released on 7 October 2026, still declares engines.node: ">=20". The enforcement is announced; the manifest has not caught up. Do not read a passing npm install in December as evidence you are clear.

Four steps to get off Node 20 before January

We have not run this migration ourselves. Creuto does not deploy a HubSpot project, so each step below is drawn from HubSpot's changelog and Node's published release schedule rather than from our own run — we have verified the package metadata and the action source, not the deploy.

1. Raise the runner's Node version. In GitHub Actions that is the node-version input on your actions/setup-node step; locally it is nvm install 24 && nvm use 24. Change it in every workflow that touches HubSpot, not just the deploy one. From HubSpot's stated requirement of v22 or higher.
2. Reinstall the CLI globally. npm i -g @hubspot/cli@latest, exactly as the changelog gives it. A global install from a cached older Node can keep a stale binary on the path, so check hs --version afterwards rather than assuming. Command quoted from HubSpot; the verification step is our own suggestion.
3. Find every pinned version in CI config. Grep your workflows for node-version, for @hubspot/cli@ with a fixed number, and for container images with a Node tag. HubSpot's own composite action defaults CLI_VERSION to 8.0.0 when neither an input nor DEFAULT_CLI_VERSION is set, which is a pin you may not know you have. Read from the action source on GitHub.
4. Confirm you are actually clear. Print node --version and hs --version as a step in the pipeline itself and read them in the log of a real run. A green build in December proves nothing about 8 January, because nothing fails until HubSpot flips the switch. Our inference from the announcement, not a HubSpot instruction.

The GitHub Action is the part you cannot fix yourself

HubSpot's instruction for Action users is conditional: "you will need to update to the latest action version once released to support Node.js 22+." Once released. As of 21 October 2026, the newest release of HubSpot's hubspot-project-actions repository is v1.1.2, published on 28 May 2026 — nearly five months before the announcement. No Node 22 release has shipped.

That is the practical blocker, and it is worth stating plainly: if you consume the official Action, steps one to four above do not finish the job, and the remaining work is on HubSpot's side. The mitigating detail is that the Action is a composite one — it does not set up Node itself, it runs npm install -g @hubspot/cli@$CLI_VERSION on whatever Node the runner already has. So raising your runner's Node may well carry you through regardless. We cannot promise that, and neither has HubSpot.

Node 22 is not the version to land on

HubSpot's floor is v22 or higher, and taking the floor is the wrong move. Node.js 22 (Jod) left active LTS for maintenance on 21 October 2025 and goes end of life on 30 April 2027 — under four months past the HubSpot cutoff. Node.js 24 (Krypton) is supported to 30 April 2028, and Node.js 26 enters LTS on 28 October 2026 with support to 30 April 2029. Upgrade once, to 24 or 26, and do not book this ticket again in the spring.

This does not affect you if

Most readers of this post do not need to do anything. You are unaffected if you do not use the HubSpot developer CLI at all — integrating against HubSpot's REST APIs from your own backend is a separate concern, covered in our post on HubSpot API deprecation, and nothing in this changelog touches it. You are also fine if your runners track an LTS alias rather than a pinned major, if your developers run nvm use against a current .nvmrc, or if HubSpot work in your organisation happens entirely in the browser.

A pinned runtime is a dated liability

The useful lesson is not about HubSpot. A pinned runtime version in CI is a dated liability that nobody owns, and it fails on someone else's schedule. Node 20 had been out of support for almost six months before this announcement gave anyone a reason to look. We have made the same argument about macos-14 runner retirement and about .NET 8 end of support, and the pattern is identical each time: the breakage is announced by a vendor, but the exposure was created months earlier by a version string in a YAML file.

The fix is a list. Every pipeline you own, the runtime major it pins, and the date that major dies — the same discipline we have written about for GitHub Actions workflow lockfiles, which pin build-time dependencies but say nothing about the runtime underneath them. That list takes an afternoon and it is the only artefact that turns announcements like this one into a calendar entry rather than a failed deploy.

So the next decision is not whether to upgrade — it is whether anyone can tell you, today, which Node major each of your pipelines pins. If the answer takes more than a grep, that is the thing to fix before January. If you want help auditing it, that work sits in our API development and integrations practice.