HubSpot custom code actions Node 24: what breaks, and when

Your HubSpot custom code actions on Node 20 will not stop running this month, but from 17 November 2026 you cannot save a change to them. That is the inconvenience. The outage is elsewhere: on 1 February 2027 design manager serverless functions stop answering and every /_hcms/api/ request fails. The HubSpot custom code actions Node 24 upgrade is an afternoon of code edits; replacing CMS functions is a project rebuild. Here is which of your workflows and pages break, when, and what each fix costs.

HubSpot published the schedule in a changelog post on 3 November 2026. As of 4 November 2026, the February cut-off is 89 days away.

Date	Workflow custom code actions	Design manager serverless functions
3 Nov 2026	No new Node.js 20 actions; Node.js 24 available	No new functions can be created
17 Nov 2026	Existing Node.js 20 actions can't be saved; they keep running	Existing functions can't be edited; they keep running
1 Feb 2027	No change announced	Functions stop running; /_hcms/api/ requests fail

Will your HubSpot Node 20 custom code actions stop working?

Node 20 custom code actions keep executing after both dates. The Node 24 upgrade guide says existing Node.js 20 actions "keep running", and Node.js 16 actions already behave the way Node 20 will from 17 November: they run, but you can't save a change until you switch the runtime.

That sounds safe, and for a workflow nobody touches it is. The risk is the day someone needs to change lead routing logic or fix an enrichment call that a vendor API broke. From 17 November that edit forces a runtime upgrade at the same moment, with no way back: the guide says rollback to Node.js 20.x is possible only until 17 November. Upgrading on your own schedule now is cheaper than upgrading under an incident.

The same guide notes that Node.js 16 and 20 no longer receive security updates, which is the reason HubSpot gives for the cut-off. Custom code actions themselves require Data Hub Professional or Enterprise, so no new subscription is involved on this side.

The HubSpot custom code actions Node 24 upgrade changes your code, not just the runtime

Switching the Language dropdown to Node.js 24.x is not the whole job. HubSpot's changelog puts it plainly: "Upgrading isn't only a runtime change." Three things change in your code.

How do you convert a callback to async in HubSpot custom code?

Node.js 24 does not support callback-style handlers, so exports.main must be an async function that returns its outputs. Remove the callback parameter, then replace each callback({ outputFields: { ... } }) with a return:

// Node.js 20
exports.main = async (event, callback) => {
  callback({ outputFields: { email: email } });
};

// Node.js 24
exports.main = async (event) => {
  return { outputFields: { email: email } };
};

The subtle bug is fire-and-forget work. The upgrade guide warns that code still running after return isn't guaranteed to finish, so await every API call first. If you relied on HubSpot retrying after a rate-limit error, keep throwing the error from your catch block; a thrown error still fails the execution and triggers the retry.

The preloaded libraries move, and request is gone

The Node 24 runtime pins exact library versions rather than caret ranges. The ones most likely to bite:

Library	Node.js 20	Node.js 24
@hubspot/api-client	^11.1.0	13.4.0
axios	^1.2.0	1.13.5
mongoose	^6.8.0	9.2.2
redis	^4.5.1	5.11.0
googleapis	^67.0.0	171.4.0
request	^2.88.2	Not included

Any action that calls request fails outright; HubSpot's guide points you to axios or the built-in fetch(). The jump from @hubspot/api-client 11 to 13 is two major versions, so check every client method you call against the client release notes. If you are also moving off older API versions, our note on HubSpot API deprecation and private apps covers that separate timeline.

Breeze can do the edit, but you still review it

HubSpot offers an Upgrade with Breeze button that rewrites every custom code action in a workflow to Node.js 24. The guide itself tells you to compare the result with a backup, confirm every data output is still returned, and test each action before saving. The HubSpot CLI can't update custom code actions, so this is UI work, workflow by workflow. Testing runs against a real record and applies its changes, so use a dedicated test record.

Design manager serverless functions are the real outage

Design manager serverless functions run on Node.js 18 or 20, and the changelog says HubSpot can't upgrade them. On 1 February 2027 they stop. Any website form handler, gated-content check or lookup a page makes to /_hcms/api/ returns an error from that day. HubSpot also states it "can't migrate your functions automatically, because each function's code and the pages that call it are unique to your site."

What replaces design manager serverless functions?

The replacement is an App Function inside a developer project. Per the migration guide, each function gets its own *-hsmeta.json file with "type": "app-function", the project's hsproject.json sets the platform version (2026.09 at the time of writing), and projects on 2026.03 or later run Node.js 24. URLs change from /_hcms/api/<endpoint> to /hs/serverless/<path>, so every caller in templates, modules, header HTML and rich text has to be found and edited.

The behaviour changes too. The timeout rises from 10 seconds to 15. context.secrets disappears in favour of process.env, context.limits no longer exists, context.body becomes {} rather than undefined, and only true-client-ip is passed, not x-client-ip. Projects preload no libraries, where design manager functions shipped with axios 0.19 and request. You can call HubSpot APIs with the built-in PRIVATE_APP_ACCESS_TOKEN, but it stays empty until you run hs project install-app.

Do you need Content Hub Enterprise for serverless functions?

Yes. The migration guide states that serverless functions require Content Hub Enterprise; accounts without it and without functions in active use don't need the migration at all. If you are on a lower tier and rely on these endpoints, the decision is real: keep the tier, or move the logic to an external service you host. That is the honest counter-argument to rebuilding inside HubSpot. An external endpoint escapes the tier gate, but it adds hosting, monitoring and its own runtime upgrades, and it loses the context.contact data HubSpot passes to functions for known visitors. Where that contact context drives the page, staying inside HubSpot is usually the better choice.

Projects on old platform versions are a third, quieter problem

Developer projects on platform versions 2023.1, 2023.2 or 2025.1 run functions on Node.js 18 or 20 and don't get security updates, according to the changelog. HubSpot's fix is hs project migrate, which moves a project to the latest platform version, followed by a redeploy. Projects already on 2026.03 or 2026.09 need nothing. The migration guide asks for HubSpot CLI 8.4.0 or later, and the CLI's own Node requirement is moving too; we covered that in HubSpot CLI Node 20 support ending.

What to do before 17 November, and who should do it

1. Filter workflows by the Custom code action type and list every action still on Node.js 16 or 20.
2. Back up each action's code to source control, then upgrade and test before 17 November while rollback still exists.
3. Run hs cms function list and search live pages in the browser Network tab for _hcms/api to find every serverless caller.
4. Decide per function: port to an App Function on 2026.09, retire it, or move it outside HubSpot.
5. Switch callers one function at a time, keeping the original /_hcms/api/ URLs saved for rollback.

Custom code actions are usually a job your RevOps engineer can finish in-house. The serverless migration is where teams get stuck, because it spans CLI projects, secrets, scopes and every page template that calls a function. If you are weighing whether to port those functions or rebuild them as an external integration, our API development and integrations team can scope the inventory and the move with you, in Node.js, before 1 February.