HubSpot Is Freezing Node.js 20 Custom Code Actions. What Should Revenue Teams Do?

What did HubSpot change for workflow custom code actions in November 2026?

HubSpot is retiring old Node.js runtimes for workflow custom code actions in stages. Since November 3, 2026 you cannot create new Node.js 20 actions. From November 17 you cannot save changes to existing ones. Those actions keep running, but you lose the ability to fix them. Node.js 24 is the supported path forward.

The notice landed on the HubSpot developer changelog under a title that sounds like it only matters to developers: "Sunsetting design manager serverless functions and older Node.js runtimes for custom code actions." Plenty of revenue teams will scroll past it. That is a mistake, because custom code actions are where a lot of quiet GTM logic lives.

I build the systems behind go-to-market for B2B teams, and custom code actions are one of my favorite tools inside HubSpot workflows. They are also one of the easiest things to forget you own. This piece covers what changed, what it means for your lead routing and enrichment logic, and the order I would work through it.

Why should a revenue team care about a developer changelog post?

Because custom code actions usually run revenue logic, not developer experiments. Teams use them to score leads, format data, call enrichment APIs, assign owners, and clean records before sales sees them. If one of those actions breaks or needs a change after November 17, nobody can edit it until it moves to Node.js 24.

In many portals, nobody on the revenue team can tell you how many custom code actions exist. They were written by a contractor, a former RevOps hire, or someone who pasted a snippet from a forum two years ago. The workflow still fires, the lead still gets routed, and the code is invisible until something goes wrong.

HubSpot states the reason plainly. The affected functions and actions "run on runtime versions that no longer receive security updates." That is a fair reason to retire them. It does mean the burden of moving code shifts to whoever owns the portal, and in many companies that is a marketing or sales ops person who never wrote the code in the first place.

What exactly happens on each date?

There are three dates. On November 3, 2026 HubSpot stopped new design manager serverless functions and new Node.js 20 custom code actions. On November 17, 2026 editing existing design manager functions and saving changes to existing Node.js 20 actions stops. On February 1, 2027 design manager serverless functions stop running entirely.

The distinction between the two products matters. Workflow custom code actions are the code steps inside HubSpot workflows. Design manager serverless functions are a separate CMS feature, served from endpoints under /_hcms/api/. HubSpot says that from February 1, 2027, those functions stop running and requests to those endpoints fail. That is a hard stop for anyone with website forms or tools wired to them.

For workflow actions, HubSpot is clear that "existing custom code actions that use Node.js 16 or 20 keep running." So your routing will not suddenly stop on November 17. What stops is your ability to change it. HubSpot also notes that Node.js 16 is already deprecated, so a Node.js 16 action cannot be saved until you switch it to a newer version.

Why is an edit freeze riskier than a hard shutdown?

A hard shutdown is loud. Everyone notices and someone fixes it. An edit freeze is quiet. The action keeps running exactly as written, including any bug, any outdated field name, and any API call to a vendor that has changed its response. You find out you cannot patch it at the worst possible moment.

This is the part of the notice I would underline for every client. Think about what actually breaks custom code in a GTM stack. An enrichment vendor renames a field. A sales leader changes territory rules. A new product line needs a new lifecycle stage. Each of those used to be a five minute edit. After November 17, each one becomes a rewrite on a new runtime, under time pressure, while leads pile up.

My rule is simple. Code you cannot edit is code you no longer control. If an action makes a revenue decision, such as who owns a lead or whether a contact counts as qualified, it should be moved before you need to change it, not after. The calm week is the time to migrate. The week a territory plan changes is not.

What does moving an action to Node.js 24 actually involve?

It is usually a small rewrite, not a copy and paste. HubSpot says Node.js 24 does not support callback-style handlers, and it notes that the libraries available to your code have new versions. So older actions that hand their result to a callback need restructuring, and every action needs testing before it goes live again.

A callback-style handler is a function that finishes by passing its output to a callback rather than returning it. A lot of older automation code was written that way, because older examples showed it. The modern pattern is an async function that returns its result. The logic inside can often stay the same, but the shape of the function changes, and that is enough to break an action if nobody tests it.

Library versions are the second trap. If an action calls an external API through a helper library, a newer version of that library may handle errors, timeouts, or response formats differently. I treat every migrated action as new code. It gets a test run against known records before it touches live leads, a habit I described in more detail in my guide on planning for a vendor API deprecation in your automations.

How do you find every custom code action in your portal?

Start with a list, not a fix. Open every active workflow, note each custom code step, and record what it does, which secrets it uses, which runtime it is on, and what happens to revenue if it stops. Most teams discover more actions than they expected, and some they cannot explain at all.

I do this in a spreadsheet with one row per action. The columns are the workflow name, the action's purpose in one plain sentence, the runtime version, the external services it calls, the secrets it reads, the owner, and a risk rating. The risk rating is the only column that requires judgment. An action that assigns lead owners is high risk. An action that formats a phone number for a report is low.

If you already keep a map of your tools and data flows, add these actions to it. If you do not, this is a good excuse to start one. My walkthrough for writing a GTM stack inventory in a spreadsheet covers the structure I use, and custom code actions belong on the data flows tab because they move and transform records between systems.

Which actions should you migrate, retire, or replace?

Sort every action into one of three groups. Migrate the ones that make revenue decisions and that you understand. Retire the ones nobody can explain and nothing depends on. Replace the ones that would be simpler as a native workflow step or an external tool. This triage usually shrinks the migration list.

Retiring is underrated. Most portals carry some automation debt, steps that once solved a problem that no longer exists. If you cannot find anyone who knows why an action exists, turn off the workflow branch in a test, watch for a week, and see whether anyone notices. Silence is often the answer.

Replacing is a judgment call. Some logic belongs in code because native workflow steps cannot express it cleanly. Other logic was written in code only because the person who built it was comfortable with JavaScript. If a branch or a built-in workflow action can do the job, the native option is easier for the next person to maintain. For heavier logic that calls several outside services, a workflow tool like Zapier, Make, or n8n may be the better home. Integrations that already run on Zapier, like the HubSpot automations I built for Kismet Health, sit in a different layer from in-portal custom code, so they need their own review rather than this one.

What about website forms and tools that call design manager functions?

Treat them as the most urgent item. HubSpot says design manager serverless functions stop running on February 1, 2027, and requests to their endpoints fail. Anything on your website that posts to those endpoints, such as a custom form handler or a pricing calculator, needs a new home before then.

HubSpot's direction is developer projects. Its changelog says projects already on platform versions 2026.03 and 2026.09 run Node.js 24 and do not need to be migrated at this time, and that older projects should be upgraded with the hs project migrate command and redeployed. That is a developer task. If you do not have a developer, budget for one now rather than in late January.

This is also a good moment to ask whether that logic belongs inside HubSpot at all. On the Webflow sites I build, I prefer form handling that runs through native form settings or a dedicated automation, with HubSpot as the destination rather than the processing layer. There is no single right answer, but a forced migration is the cheapest time to reconsider the architecture, because you are paying to touch the code anyway.

Is this part of a larger cleanup at HubSpot?

It appears so, though I would not overstate it. The same developer changelog carries a September 15, 2026 post titled "Legacy APIs and Apps: What's Going Unsupported and When." Read it directly before planning, because older integrations and private apps may need their own review alongside this runtime change.

I am not going to summarize the dates in that post here, because I would rather you read HubSpot's own wording than my paraphrase of a schedule that affects your stack. The general lesson is the one that applies to every platform I work with, from HubSpot to Webflow to Clay and Apollo. Vendors retire old pieces on their timeline, not yours. Teams that keep a living inventory and a short migration habit absorb these notices in an afternoon. Teams that do not end up paying for an emergency.

If your actions read API keys or tokens, the migration is also a chance to tidy them. Moving runtimes is a natural point to rotate old keys and remove the ones nobody uses. My notes on where API keys should live in a no-code automation stack cover the habits I apply across tools.

What should you do next?

This week, list every custom code action and design manager function in your portal. Rate each one by revenue risk. Migrate the high risk actions to Node.js 24 before November 17 if you can, and test each one against known records. Then schedule the design manager work well before February 1, 2027.

If you only have an hour, spend it on the inventory. Knowing what you have is the difference between a planned migration and a panic. If you have a day, migrate the single action that assigns lead owners or sets lifecycle stages, because that is the one you will most likely need to edit in the next quarter.

If you want a second pair of eyes on your HubSpot workflows, or help moving custom code to Node.js 24 without breaking routing, reach out through pravinkumar.co. I build websites and the automations behind them for lead generation, and this is exactly the kind of quiet risk I like to catch early. Let's chat.