Everything a HubSpot portal does beyond showing a page runs as a serverless function. Filling an intake form with what the CRM already knows is one. So is listing a client’s open requests, or saving their reply. Those functions run on HubSpot’s terms: a hard time limit per call, a per-minute budget shared by every function on the account, rules about what code they may use, and a platform that changes underneath them twice a year.
The portal’s ceiling isn’t set by what your business needs. It’s set by your marketing vendor’s roadmap.
What do serverless functions do in a HubSpot portal?
They’re the portal’s back end. A HubSpot page can show content and read some CRM data on its own, but anything that has to happen on the server, with credentials the browser must never see, needs a function. On the CMS, that’s a Content Hub Enterprise feature. 1 Source 1 HubSpot Developers, “Serverless functions reference” (CMS), read October 30, 2026: 10 seconds of execution time and 128 MB of memory per function; “Each account is limited to 600 total execution seconds per minute,” for example 60 executions of 10 seconds or 6,000 of 100 milliseconds, with calls over the limit returning a 429 response; 50 secrets and 100 endpoints per account; nodejs20.x only; logs kept 90 days. HubSpot Developers, “HubSpot CMS overview”: “Serverless Functions are a Content Hub Enterprise feature.”
In a typical custom portal that means a lookup when a page loads, a write when someone submits something, and a call to another system now and then. Each is short. Together they’re the portal.
What limits does HubSpot set?
HubSpot now runs two kinds of functions with two sets of rules: functions built for the CMS, and functions in apps built on its newer developer platform (version 2026.03 and later). 2 Source 2 HubSpot Developers, developer platform “Serverless functions reference” and “overview,” read October 30, 2026: “Functions have a 15 second execution timeout”; functions “may experience cold starts after periods of inactivity”; “Apps using OAuth for authentication cannot use 2026.03 serverless functions”; “An Enterprise subscription is required to install an app with serverless functions”; public endpoints are “Content Hub Enterprise only.”
| Limit | CMS functions | Developer platform 2026.03 | What it decides |
|---|---|---|---|
| Time per call | 10 seconds | 15 seconds | Any job longer than that can’t run in one call |
| Memory | 128 MB | Not stated in the reference | How much data one call can hold |
| Shared budget | 600 execution seconds a minute, per account | Not stated in the reference | How busy the whole portal can get |
| Over the limit | Calls refused (429) | Clients see errors | |
| Secrets and endpoints | 50 secrets, 100 endpoints per account | How many integrations and routes the portal can have | |
| Runtime | Node.js 20 only | When the language version moves, you move | |
| Other rules | No third-party packages in design-manager functions | May cold-start; apps using OAuth can’t use functions | What code your developers can reuse |
| Subscription | Content Hub Enterprise | Enterprise to install; public endpoints Content Hub Enterprise | What the portal costs before it does anything |
None of these is unusual for a serverless platform taken alone. The difference is that you didn’t choose them, can’t raise them, and share them with everything else on the account.
What happens when a portal hits them?
The shared budget is the one that surprises people. Take a busy Monday morning. A CRM lookup that takes five seconds, called 120 times in a minute, spends all 600 seconds. Every other function on the account, in this portal or anywhere else on the site, starts getting refused until the minute rolls over. The client trying to submit a request sees an error, and nothing in the portal was broken.
The time limit shapes what the portal can do at all. Ten seconds is generous for a lookup and nowhere near enough for the jobs firms eventually want: assembling a client’s documents into one file, importing a spreadsheet of records, copying a week of portal messages to a compliance archive. Those have to run somewhere else, which on HubSpot means a second system the portal now depends on. On the newer platform there is another wrinkle. HubSpot warns that functions “may experience cold starts after periods of inactivity,” so the first click of the morning can be the slowest.
The client trying to submit a request sees an error, and nothing in the portal was broken.
Your developers write more of it by hand
Functions built in HubSpot’s design manager can’t use third-party packages at all; HubSpot’s docs say “including third-party dependencies is not supported.” Functions built as developer projects can declare packages, but in both cases one function “cannot import other functions,” so shared code gets copied or bundled into every function that needs it. 3 Source 3 HubSpot Developers, “Serverless functions overview” (CMS), read October 30, 2026: for design manager functions, “including third-party dependencies is not supported”; for project-based functions, package.json “configures dependencies needed to execute the function”; functions “cannot import other functions,” so code has to be in one file or bundled.
The cost isn’t technical so much as human. Work that would take an afternoon with common, well-tested building blocks takes longer when it has to be written or packaged specially for HubSpot. Fewer developers know how, and the ones who do are the same people who know the rest of your portal. That’s how a portal ends up depending on one person.
Why does the platform keep changing?
Because HubSpot ships a new version of its developer platform every March and September, and old versions stop working on a schedule: 18 months after release a version is unsupported, and “if you try to upload a project using an Unsupported version, the resulting build will fail.” 4 Source 4 HubSpot Developers, “Developer platform and API versioning,” read October 31, 2026: 2025.2 “Released on Sept 2, 2025,” raising the minimum Node.js version to v22, without serverless function support for apps; 2026.03 “Released on March 30th, 2026,” which “re-introduced serverless function support for apps built on the developer platform”; 2025.1 “was sunset on August 1, 2026.” Versions ship every March and September; “18 months after a version originally went into GA, the version will be considered unsupported,” and “If you try to upload a project using an Unsupported version, the resulting build will fail.” For portals that rely on functions, the last year went like this:
- September 2, 2025: HubSpot released platform 2025.2, without serverless functions for apps. Projects that needed functions had to stay on 2025.1.
- December 1, 2025: HubSpot announced that 2025.1 would be retired on August 1, 2026, “due to the underlying Node.js v20 deprecation” by its cloud provider, and that the next version would bring functions back. 5 Source 5 HubSpot Developer Changelog, “Upcoming Deprecation: HubSpot Projects v2025.1 to be deprecated August 1, 2026,” posted December 1, 2025, updated March 12, 2026: the change is “due to the underlying Node.js v20 deprecation by AWS Lambda”; “Starting on the sunset date, you will no longer be able to build or deploy projects using Platform v2025.1”; v2026.03 “will reintroduce serverless app functions.”
- March 30, 2026: Platform 2026.03 re-introduced serverless functions, with a 15-second limit and no support for apps that authenticate with OAuth.
- August 1, 2026: 2025.1 was sunset. From that date, HubSpot said, “you will no longer be able to build or deploy projects using Platform v2025.1.”
That’s one forced migration inside a year, on dates set by HubSpot and, behind HubSpot, by its cloud provider. HubSpot’s own CMS guide hasn’t caught up either. As of October 31, 2026, its serverless overview still told developers that functions aren’t supported on 2025.2 and “you’ll need to use version 2025.1 to build and deploy serverless functions,” the version it had sunset three months earlier. 6 Source 6 HubSpot Developers, “Serverless functions overview” (CMS), read October 31, 2026: “serverless functions are not supported in version 2025.2 of the developer platform”; “Instead, you’ll need to use version 2025.1 to build and deploy serverless functions.” The page did not mention 2026.03 or the August 1, 2026 sunset of 2025.1.
A portal that runs a business process can’t treat its platform’s version history as weather. Each change is unplanned work, scheduled by someone else, and somebody has to notice it’s coming.
What a back end you control gives you
The same portal on a back end you control runs on limits you choose. Long jobs run as long as they need, in the background, while the client gets on with their day. A busy Monday scales up instead of refusing requests. Your developers use the same well-tested building blocks as everyone else, so the work goes faster and more people can do it. Logs stay as long as your compliance team wants, rather than the 90 days HubSpot keeps. Upgrades happen when you schedule them, tested on a full copy of the portal first.
What you gain is a roadmap set by the business. The next feature becomes a question of value and budget, not of what this year’s platform version allows. HubSpot can still be your CRM. It just stops being the place the portal’s logic has to live.
The data side of the same problem is in Is HubDB a Database? HubDB vs Custom Objects for Portals, and the testing side is in Does HubSpot Have a Sandbox? Not One That Copies Your Portal. For the full set of trade-offs, start with Can You Build a Customer Portal on HubSpot?, then Custom Client Portal or HubSpot? 5 Options Compared. We first called these functions “throttled, sandboxed” in our look at HubSpot’s Content Hub. This is the evidence. Platforms that set your code’s rules are what the Five Locks calls the Code Lock.
The research is free. So is the diagnosis. 60 seconds →