HubSpot Node.js 20 Custom Code: What Happens on 17 November

Short answer for the admin who got HubSpot’s email. A custom code action is a step in a workflow (a HubSpot automation) that runs a short program someone wrote. Node.js is the engine that runs the programs written in JavaScript, a programming language. It comes in numbered versions. On 17 November 2026, your existing Node.js 20 custom code actions keep running. You can no longer save changes to them. From that date, any code change means moving the action to Node.js 24 first, and testing it. So make a list: every custom code action, what it does, who owns it, and whether you will upgrade it, replace it or defer the work. Do not start by clicking “Upgrade with Breeze” on everything. Breeze is HubSpot’s AI assistant, and that button asks it to rewrite the code.

One reply in HubSpot’s Community thread about the change put the problem plainly: “the majority of HubSpot clients aren’t devs”. You may be responsible for code you did not write. An agency wrote it, or a colleague who has since left. This article is for the admin who now has to maintain that code.

Reviewed 11 November 2026. The facts below come from HubSpot’s developer changelog (the page where it announces technical changes) and documentation on that date. HubSpot updated the announcement on 4 November, so check the linked pages again before you plan work. After 17 November, you can still inventory and upgrade these actions, but you cannot save changes on Node.js 20 or roll back to it.

What HubSpot announced, date by date

A custom code action replaces a standard action such as “set property value” with a short program written in JavaScript or in Python, another programming language. A property is HubSpot’s name for a field on a record. A record is an entry in the CRM, the customer database, such as a contact or a company. Node.js runs the JavaScript actions. Each version eventually stops receiving security updates. HubSpot’s changelog announcement gives that as the reason: the older versions “no longer receive security updates”.

• 3 November 2026: no new Node.js 20 custom code actions. Node.js 24 is available. No new design manager serverless functions either (code that runs behind a website; more on those below).
• 17 November 2026: you can no longer save changes to existing Node.js 20 actions. Existing actions keep running. Existing design manager functions can no longer be edited.
• 1 February 2027: design manager serverless functions stop running.

Nothing in the notice says your workflows break on the 17th. It says existing Node.js 20 actions keep running after the freeze. As of 11 November 2026, the linked announcement gives no shutdown date for existing Node.js 16 or 20 workflow custom code actions. The cost is elsewhere: those actions stay on a version that no longer receives security updates.

Node.js 16 actions are already in this situation. They keep running, but you cannot save changes until you move them to a newer version.

Two different things in one email

The announcement covers two products. Check workflows and website functions separately; your account may use either, both or neither.

Workflow custom code actions

These live inside workflows. They need Data Hub Professional or Enterprise (Data Hub is HubSpot’s data management product). Without Data Hub at one of those tiers, you almost certainly have none. The Action type filter described below confirms it. The notice is about Node.js. It says nothing about Python actions, which are still in beta, a test phase before general release.

Design manager serverless functions

A serverless function is a small program that HubSpot runs when a web page asks for it, for example a form that checks something before it submits. The design manager is HubSpot’s built-in editor for website templates and files, and these functions were created there. HubSpot’s migration guide says they require Content Hub Enterprise (Content Hub is HubSpot’s content and website product). Without it, you have nothing to migrate. Here the deadline is real. After 1 February 2027, calls to addresses starting with /_hcms/api/ fail, and any page or module (a reusable block of a page) that depends on them breaks. The replacement lives in a developer project and is served from /hs/serverless/. A developer project is HubSpot’s newer way of packaging code: developers build and publish it with their own tools. HubSpot cannot migrate these functions automatically. Someone must rebuild them and update the pages and modules that call them. This is developer work. Your job is to make sure someone has it in their plan before February.

What “keeps running but cannot be edited” means in practice

A frozen action keeps running. The trouble starts when something around it changes. The code needs to write to a different property. An external tool the code calls changes its address. A colleague asks for one more condition. Before the freeze, you can save that change without upgrading the action. From 17 November, the order is fixed: convert the action to Node.js 24, test it, then make the fix you wanted. Often you do all this while a process is already going wrong.

There is also no way back after the freeze. HubSpot’s upgrade guide says an upgraded Node.js 20 action may be switched back until 17 November 2026, and only if Node.js 20 still shows in the Language dropdown. From 17 November, you cannot switch it back. Node.js 16 actions cannot be rolled back at all.

Do not switch off the affected workflows. Switching off working automation because of an edit freeze trades a future risk for an outage today. Leave them on unless you have a separate reason to stop them.

Find them in the workflows list

The upgrade guide gives the path. You need permission to edit workflows in the account.

1. Go to Automation > Workflows.
2. Add the filter Action type and choose Custom code.
3. For each workflow in the list, hover over the row and click Edit workflow. Check each custom code action’s Language dropdown and flag those using Node.js 16 or 20. Python actions fall outside this Node.js upgrade.

Write one line per action, not per workflow. A workflow can hold several. For each action, record its workflow, language and version, whether the workflow is on, what the code does (the comment at the top of the code, if anyone left one), which records or external systems it changes, and who owns it now. If nobody owns it, ask the team that relies on it to name someone who can approve changes and check the results.

Copy the code of each action into a document outside HubSpot before anyone touches it. HubSpot recommends this too. If the upgraded version misbehaves, that copy may be your only reference. After the 17th, you repair on Node.js 24 from it.

I have found custom code actions that nobody in the team could explain. I started with the people who worked with the workflow. When nobody knew, I asked Breeze to explain the code and read it against what the workflow was for, until I could say what the action changed. Only then did I decide anything. An action you do not understand is hard to replace, and guessing is how a working workflow breaks. This change is about security updates, which makes the question more pressing: for every piece of code in your CRM, someone should be able to say what it changes, and where.

For each action, one of three decisions

“Leave frozen” is a legitimate choice if someone makes it. Record why the upgrade is deferred, who accepts the risk of an unsupported version and when they will review that decision. Put one named person against each action: they decide when it is upgraded and sign off the test.

If you only have time for part of the list before the 17th, start with active workflows that write to fields other teams rely on. That means owner, lifecycle stage (the field that says whether a record is a lead, an opportunity or a customer) and anything that feeds reporting or routing, the rules that decide who receives a record.

What changes in the code, in plain words

You do not need to make these changes yourself. Knowing them helps you brief whoever does and judge whether an estimate is reasonable. From the upgrade guide:

• The way the code hands back its result changes. In HubSpot’s Node.js 24 environment, the main function must be async (a way of writing code that waits for replies) and return its results, instead of passing them to the older callback() (a function the code called when it finished).
• The libraries change version. Libraries are ready-made code packages the action can use. For actions on Node.js 20, HubSpot’s own client library, the package the code uses to talk to HubSpot, moves from version 11 to 13 (Node.js 16 had version 10). Axios, a package for calling other systems over the web, moves to a newer release. A method (a named command in a library) that the code calls may no longer exist in the new version. Each call needs checking, not only the first and last lines.
• One library is gone. The old request package is not included in Node.js 24. Code that uses it has to be rewritten with axios or the built-in fetch(), which does the same job. Expect more work on those actions.

HubSpot recommends the Upgrade with Breeze button and calls it the AI-assisted way to update these actions. The button appears under the Language dropdown and opens a Breeze chat in the workflow editor. Breeze updates all the custom code actions in the workflow, not only the one you clicked. One click changes several actions, and each of them needs testing. It can save time. In the Community thread, one user asked whether it works. A partner (an agency that manages HubSpot accounts for clients) replied that they had not seen it work very well. HubSpot’s own guide says Breeze can make mistakes. Before you save, it tells you to compare the changes with your saved copy, confirm all outputs (the values the code passes to later workflow steps) are still returned and check the code’s calls to HubSpot’s API against the new library versions. The API is the interface code uses to read and write CRM data. Treat the result as a first draft. If the code was written by AI in the first place, the review checklist for AI-written workflow code applies just as well to code AI has rewritten.

Testing: what to check before you save

Each custom code action has a Test action button at the bottom. You choose a record, run the code and see the status, the outputs and the logs (the messages the code writes as it runs). One warning from HubSpot’s guide: the test applies the code’s changes to the record you select. Use a dedicated test record. Check whether the code can also change other records or external systems.

The test runs only that action, not the rest of the workflow. Test a normal case and a missing or invalid input. Compare the action’s outputs and record changes with the results you expect. Then test the later workflow steps separately: code can run without error and return an empty value that a later branch (an if/then split in the workflow) treats as “no”. For a large or critical change, use a sandbox, a separate test account that copies your account’s features, available with Enterprise subscriptions. Follow the sandbox release checklist.

Then save, and add the date and the person who signed off to your list.

When this does not apply

• The Action type filter returns nothing: no workflow action to upgrade. Website functions are a separate check. Without Data Hub Professional or Enterprise this is the likely result, but run the filter once to confirm.
• All your actions already show Node.js 24: confirm that their outputs and the later workflow steps have been tested.
• No Content Hub Enterprise: the design manager part does not concern you.

Developer-project functions are a separate check, not an exception. If you use them, ask their maintainer to check the project’s platform version (the release of HubSpot’s developer tooling it is built on) against the changelog. Projects on platform versions 2023.1, 2023.2 or 2025.1 need upgrading. HubSpot says their builds and deploys, the steps that publish new code, are already blocked.

Partner admins should check each account they manage. One partner in the Community thread was not sure they had received the notice for accounts where they were only a partner admin. Do not assume the client saw it.

If an action connects to another system, record who owns that connection and its credentials in the integration credential register.

Continue with the part you need

• Review AI-written workflow code before release
• Test a workflow change in a sandbox
• Give every integration credential an owner