Sunsetting design manager serverless functions and older Node.js runtimes for custom code actions

[SJMorris]

Originally published on our Developer Changelog:

HubSpot is sunsetting serverless functions built in the design manager, and Node.js 20 and earlier for workflow custom code actions. All of these run on runtime versions that no longer receive security updates. To keep your website features and workflows working, move your design manager serverless functions to developer projects, and update your custom code actions to Node.js 24. To make migration easier we’ve provided an AI prompt for design manager functions and a Breeze Assistant powered update capability for custom code actions.

What’s changing

Design manager serverless functions

Serverless functions uploaded to the design manager and served from /_hcms/api/ run on Node.js 18 or 20, which HubSpot can’t upgrade. HubSpot is sunsetting them in three stages:

• Starting November 3, 2026, you can no longer create new design manager serverless functions. You can still edit existing functions until November 17.
• Starting November 17, 2026, you can no longer edit existing design manager serverless functions, including staging and deploying serverless packages through the design manager private beta. Existing functions keep running.
• Starting February 1, 2027, design manager serverless functions stop running, and requests to /_hcms/api/ endpoints fail.

HubSpot can’t migrate your functions automatically, because each function’s code and the pages that call it are unique to your site. Migrating means rebuilding each function in a developer project, where it’s served from /hs/serverless/ instead of /_hcms/api/, and updating the templates, modules, and settings that call it.

The design manager serverless functions migration guide walks you through the process, from finding every function and every page that calls it to switching over one function at a time with a tested rollback path. It also includes a prompt you can give to an AI coding agent to carry out the migration with your approval at each step.

Which developer projects platform version to use

Functions in developer projects run on the Node.js version set by the project’s platformVersion, and they get Node.js security updates automatically. Build new projects on the current platform version, 2026.09. Projects already on 2026.03 and 2026.09 run Node.js 24 and don’t need to be migrated at this time. See developer platform versioning.

If you already have serverless functions in a developer project on platform version 2023.1, 2023.2, or 2025.1, those functions run on Node.js 18 or 20 and don’t get security updates. Upgrade the project with hs project migrate, then redeploy it. Builds and deploys on those versions are already blocked. Learn how to migrate an app to the latest platform version.

Workflow custom code actions

Custom code actions in workflows can now use Node.js 24, which receives security updates. Existing custom code actions that use Node.js 16 or 20 keep running. Node.js 16 is already deprecated, so you can’t save changes to a Node.js 16 action until you switch it to a newer version.

• Starting November 3, 2026, you can no longer create new Node.js 20 custom code actions.
• Starting November 17, 2026, you can’t save changes to existing Node.js 20 actions either.

Upgrading isn’t only a runtime change. Node.js 24 doesn’t support callback-style handlers, and the libraries available to your code have new versions, so you’ll need to update and test each action. Breeze can update the custom code actions in a workflow for you.

The guide to upgrading custom code actions to Node.js 24 walks you through finding the workflows that use them, updating and testing your code, checking library changes, and rolling back if you need to.

When is it happening?

• Now (November 3, 2026): you can no longer create new design manager serverless functions or new Node.js 20 custom code actions. Node.js 24 is available for custom code actions, and both migration guides are live.
• November 17, 2026: you can no longer edit existing design manager serverless functions or existing custom code actions that use Node.js 20, as is already the case for Node.js 16. Existing functions and actions keep running.
• February 1, 2027: design manager serverless functions stop running.

To the community: We value your feedback and understand this situation may have caused frustrating disruptions. Your security is our number one priority. We’ll keep the main developer changelog post updated in real time with the latest security guidance, so be sure to bookmark it.

[remingtonbegg]

would have been really nice to get a heads up as a developer (and a partner) hubspot was going to drop this gem for all customers. Like I get that they need to, but even an hour notice would have been great.

[Anton]

Fully agree to @remingtonbegg.

The Node.js vulnerability which is mentioned in the email is known for several weeks (21 October 2026).

It would have been much better to communicate this on 22 October like

Hey folks, there’s a vulnerability. We’re aware of this and we’re doing our best to close it. Update all potentially affected code as we’ll soon shut down support for following:

• Node versions: 18,20
• Projects on dev platform 2023.1, 2023.2 and 2025.1

If you’re unsure if you rely on this, reach out to your developer, partner contact, account manager or the community.

Best HubSpot

rahter than

The phone lines might be hot for a minute, but releasing a blog post, community topic (like this one) or even a portal testing tool might help.

Please remember → the majority of HubSpot clients aren’t devs.

Such an email is plain gibberish to them, might put them into panic mode and even lead them to terminate the contract.

For partners and devs who got serverless functions running, it’s a nightmare as they have to update everything asap/in the next 10-ish days.
Even with an AI migration, depending on the serverless function, clients might start lose data/money, which will put the devs under pressure.

Not great at all as it’s not a “one fits all” thing.

[jmclaren]

We hear you on the short time-frame, though there may be an important misunderstanding about it:

You have until February 1st, 2027 to migrate Design Manager Serverless functions. Existing functions will stay working until then. Migration of existing serverless functions does not require editing of the existing function as you create a new function in the process and swap the endpoint used anywhere it’s called.

What is currently blocked today is the creation of new custom code actions that would be affected, and creation of new design manager serverless functions that would be affected. You are still able to create new serverless functions that are on the proper versions.

Regarding the feedback on the communication handling I’ll relay it internally.

[jmclaren]

Advanced notice for partners is good feedback that I will take to the team that owns this change that can help us handle future communication better.

[remingtonbegg]

Also worth noting, I’m not sure that I got notice for accounts that I was a partner admin in, only the super admin ones.

That would be really important, and maybe even something that would be great to show up in partner clients, so that we could communicate with clients proactively.

[jmclaren]

Notice for accounts you are a partner admin in is really good feedback I will also raise this with the team.

[remingtonbegg]

That’s not what this notice says. This notice says that you need to fix the vulnerable code or otherwise shut them down. But the truth is, you can’t fix the code in the current serverless functions in the design manager the way that they live today.

Am I missing something here. I really hope I am because there is a lot of unhappy customers that are all freaking out and we’re working on explaining the details to them as well as architect fixes at scale (that we didn’t have ANY notice about as partner)

[mike-thomas]

I’ve gotta say I’m disappointed with the handling of this.

Basically HubSpot’s response to a security threat is to… do nothing!

The best thing about this platform, and the tune we sign to big up HubSpot against the competition is that your customers don’t have to rely on mere developers for the the security of the platform. They can (or have been able to) rely on your team of Site Reliability engineers.

It’s not that Node or AWS are to blame either. It’s that you don’t want to do the work. Turning it off in 90 days is not the answer, and pushing it onto partners and customers to deal with is just… well. It feels pretty bad.

[Anton]

Hey @jmclaren,

please don’t get me wrong.
I know the team is working hard on this topic, I just have some pain points.

1. Timing
   The vulnerability is known for over 2 weeks and went through the media. Why is was this email sent out now and not on the day it was “discovered”?

2. Tone
   The received email is super technical. Somebody who’s not in the tech space will most likely just panic from all the technical terms and start forwarding this email from left to right and/or reach out to the devs or partners.

3. Statement
   The email starts with “we recommend to take it down even while we’re not sure if there’s a exploit”. A non technical user might not even know where to find serverless functions. Even if they find it, they might not know what it’s being used for. Maybe something small which haven’t been used in quite a while, but maybe something important which might break things big times. If something big/important should break because it was taken down, this will end up in a big pile of mess. People will refer to this email like “It was recommended by HubSpot, so I did what they recommended” … Only because the Design Manager still doesn’t have CRUD settings like most other HubSpot features. And the recently deleted files is hidden in a menu.

4. AI
   I can’t stress this enough, but recommending AI to rewrite/update a serverless function might be super counter productive.
   A developer can (or at least should) know what to prompt and what to look out for, but this email was sent out to any super-admin. And we all know chatbots. Unless they’re configured differently, they’ll end with a recommendation/question to keep the person in the convo.
   This can lead to many bad things as well as a quite bloated and bad solution.
   Just think about it. The receiver of the email might not even know what this serverless function does and just prompt right away.
   The recommended prompt is far from being a good one imo. Sounds more like “Update everything - make no mistakes”.
   What about checking what might be affected by updating the change? What about keeping the code clean? What about stress testing? What about not putting credentials into public code? … Those are things a super-admin might not even think about.
   I know HubSpot puts quite a lot of effort into defining guard-rails, and agent instructions, but in a situation where the email starts with “Put it down”, people might prompt something like “ignore everything - solve it” which might bypass all your guard-rails and prevention methods.

I think it would be a great thing to send such emails and notifications to partners as well as developers only. Not just every super-admin or contact person.
Why I’m mentioning developers seperatly?
Because not every HubSpot developer works for a partner and if such information will be provided mainly to partners, they might miss out on that.

Last but not least - just an idea for improvement:
Sending out the affected HubIDs in such an email is great, but if you’re managing X portals, you might not even know which one might be affected.
What do you do? In best case, you head over to app.hubspot.com and search for the HubID, and proceed.
I think a very helpful addition would be something like an additional coloumn on this page which would have space for an indicator, icon or something which would allow people with many portal see right from this page which portal requires some love
In this case it could display a tooltip with some text/description and some links.

best,
Anton

[MichaelMa]

Is upgrade with Breeze for workflows working? I get the following when I tried to use it:

[MichaelMa]

I’m really confused on how HubSpot expects people to update all their stuff.

We have some child themes based off of some Marketplace themes that we bought. We added our own custom serverless functions to it. If the seller doesn’t update the theme to the new endpoint, does that mean the themes are effectively broken (for their serverless functionality)?

Do we have to create a fake project theme to create new endpoints to use in our child theme? Would that even work? So many questions.

[remingtonbegg]

Hey Michael,

Technically the serverless functions themselves need to be migrated, then the urls have to be pointed to those new functions. We’ve put together a free audit to review the details and give you the steps needed. If interested hit me up in a DM or reachout to Impulsecreative.com

[remingtonbegg]

I’ve not seen it working very well, personally.