What This Update Actually Is
HubSpot has officially deprecated Node.js 18.x and 20.x as supported runtimes for custom code snippets inside Chatflows bots. The deprecation took effect August 31, 2026.
Here's the practical reality: any chatflow bot already running on Node 18.x or 20.x will continue to fire and execute for your visitors. Nothing breaks on the front end today. But the moment someone on your team tries to open and edit one of those custom code snippets, they'll hit a wall. The snippet is read-only until you upgrade the runtime.
The supported runtime going forward is Node.js 24.x, which is the current Long-Term Support release from the Node.js foundation.
Why HubSpot Shipped This
Node.js 18.x and 20.x have both reached end of life. That phrase sounds technical, but what it means in practice is simple: no more security patches. Any vulnerability discovered in those runtimes going forward is just going to sit there, unaddressed.
Chatflows custom code snippets often handle real business logic. They pull data, route conversations, and trigger actions in your CRM. Running that kind of logic on an unpatched runtime is a genuine security risk, not a hypothetical one.
HubSpot's move here is responsible. They're not pulling the plug on your bots overnight. They're locking edits first so you have time to upgrade intentionally, rather than discovering a security exposure after the fact.
How to Use It Step by Step
Follow these steps to upgrade your Chatflows custom code snippets to Node.js 24.x:
- Audit your chatflows first. In HubSpot, go to Automations, then Chatflows. Filter for bots that include a custom code action. Make a list of every bot using a code snippet.
- Open each affected chatflow. Click into the bot editor and locate the custom code snippet action inside the conversation flow.
- Find the runtime selector inside the snippet editor. It will show the current version (18.x or 20.x). Switch it to Node.js 24.x from the dropdown.
- Review your code for compatibility. Check for any npm packages pinned to Node 18 or 20 specific behavior, deprecated APIs, or outdated syntax. Node 24.x is largely backward-compatible, but you should verify, not assume.
- Test in a sandbox or cloned chatflow before touching production. Run through the conversation logic manually. Confirm all outputs and CRM actions fire correctly.
- Save and publish the updated chatflow. Once you've confirmed the snippet runs cleanly on Node 24.x, publish the bot and monitor it for the first 24 to 48 hours.
- Repeat for every bot on the list from step one. Don't leave any snippets on deprecated runtimes, even if those bots are lower traffic.
What It Touches in Your HubSpot Strategy
On the surface, this looks like a developer housekeeping task. In practice, it touches more of your portal than you might expect.
Custom code snippets inside chatflows are often doing the heavy lifting: looking up contact properties, routing conversations based on CRM data, firing webhooks to external systems, or passing values into workflows. If those snippets go untouched for months after this deprecation, your editing agility drops to zero when you need to adjust logic fast.
Key Takeaway
A read-only snippet isn't just an inconvenience. It's a locked door between your team and the chatflow logic that qualifies, routes, or supports your visitors. The longer you wait, the more technical debt compounds.
This update also connects to a broader pattern in HubSpot's platform: the humans building on top of HubSpot need to treat it like the software platform it is, not just a marketing tool with a chat widget bolted on. Security hygiene, runtime management, and code review are now part of owning a sophisticated HubSpot portal.
If your team is also building or deploying AI-powered support bots, it's worth reading about how HubSpot's Customer Agent Auto-Setup configures and deploys AI agents from your real portal data. Understanding where custom code-driven bots end and AI agents begin will help you make smarter architecture decisions going forward.
From a RevOps standpoint, this deprecation also signals that any chatflow touching your data layer needs a documented owner. If a custom snippet breaks or needs updating, someone needs to know it exists and have the skills to fix it.
Key Takeaway
Document every custom code snippet in your chatflows now: what it does, who owns it, and what runtime it's on. That documentation will save you hours the next time HubSpot ships a runtime change like this one.
If you're thinking about how much technical ownership your portal actually requires from your team, this is a good moment to revisit the question of when a tool stops being a tool and starts requiring real governance. HubSpot's expanding platform footprint means that question gets more pressing every quarter.
Who Should Care Most
This update is scoped to Data Hub Professional and Data Hub Enterprise. But within that group, a few specific roles need to act right now.
- HubSpot developers and technical admins: these are the humans who built the custom code snippets. They need to own the runtime upgrade and compatibility testing.
- RevOps and operations leads: they need to know which chatflows have custom code, who owns them, and whether the upgrade has happened. This is a portal governance issue, not just a dev task.
- Service and support team leads: if your help or qualification bots use custom code to route tickets or enrich contact data, any editing freeze directly delays your ability to improve those flows.
- Agencies and partners managing client portals: check every client account on Data Hub Pro or Enterprise. A missed upgrade in a client portal is a conversation you don't want to have after the fact.
If your organization doesn't have a dedicated developer but you've built chatflows with custom code snippets, this is exactly the kind of moment where a portal audit catches problems before they become emergencies.
George's Take
I've seen this pattern play out in portals more times than I can count. A team builds something powerful with custom code, it works great for a year, and then nobody touches it because it's still running. No one thinks to audit it. No one knows the runtime it's on. Then a change like this ships, and suddenly there's a fire drill because a bot that's routing leads or handling support conversations is locked and no one can update it. This isn't a dramatic failure. It's just quiet technical debt that accumulates when teams treat HubSpot as a set-it-and-forget-it tool instead of a living platform that needs regular stewardship.
“The portals that flourish long-term aren't the ones with the most custom code. They're the ones where every piece of custom logic has a documented owner and a clear upgrade path.”
This update follows a similar pattern to HubSpot's sunset of the hs-membership-csrf cookie, where a security-driven platform change required proactive action from portal owners before it became a breaking issue. The theme is consistent: HubSpot is maturing as a platform, and the humans building on it need to mature their maintenance habits alongside it.
If your portal has custom code snippets in Chatflows and you're not sure who owns them or what runtime they're on, that's the first thing to fix. Not next quarter. Now.
If you want a second set of eyes on your chatflow setup or a full portal audit to surface hidden technical debt, the Sidekick team is ready to help. Book a strategy call and let's make sure your portal is built to flourish, not just to survive the next platform update.
Frequently Asked Questions
What happens to my Chatflows bot if it still runs on Node.js 18.x or 20.x?
Your bot will keep executing, so it won't break for visitors. But every custom code snippet tied to that bot is now read-only. You can't edit, update, or save changes to those snippets until you upgrade the runtime to Node.js 24.x inside the Chatflows editor.
Which HubSpot plans are affected by the Node.js Chatflows deprecation?
This change affects Data Hub Professional and Data Hub Enterprise customers who use custom code snippets inside Chatflows bots. If you're on a lower tier and don't have custom code snippets in your chatflows, this update doesn't apply to your portal.
Is it safe to stay on Node.js 18.x or 20.x for now?
Your bot will keep running, but those runtimes no longer receive security patches from the Node.js foundation. That means any vulnerability discovered after their end-of-life date goes unpatched. Running chatflow logic on an unsupported runtime is a real security risk you should resolve promptly.
How do I upgrade my Chatflows custom code snippet to Node.js 24.x?
Open the specific chatflow in HubSpot, locate the custom code action, and look for the runtime selector inside the snippet editor. Switch the runtime dropdown from 18.x or 20.x to 24.x, review your code for any breaking changes, and publish the updated flow.
Will upgrading to Node.js 24.x break my existing custom code?
It depends on your code. Node.js 24.x is the current LTS release and is largely backward-compatible with 18.x and 20.x, but any deprecated APIs or packages pinned to older Node versions may throw errors. Test your snippet in a sandbox or staging chatflow before publishing to production.
What is Node.js 24.x and why did HubSpot choose it?
Node.js 24.x is the current Long-Term Support release, meaning it receives active security patches and maintenance from the Node.js foundation. HubSpot adopted it as the supported runtime to keep custom chatflow logic on a secure, maintained foundation after Node 18.x and 20.x reached end of life.
