I’m experiencing a consistent build failure when running hs project upload on a CMS Developer Project that contains 100 modules in src/theme/my-theme/templates/shared/.
Error message:
An error occurred while building project: my-project.
Error: Validation timed out after 30 seconds for module at `@projects/my-project/my-thme/templates/shared/` in build #532.
Key observations:
The failing module changes on every attempt — sometimes it’s header, sometimes footer, sometimes another module entirely. This confirms the issue is not with any specific module.
If I remove any one module (bringing the total to 99), the upload succeeds without errors.
Setting --http-timeout=120000 resolved the client-side upload timeout, but the server-side 30-second validation timeout persists and cannot be configured from the CLI.
The log file generated at ~/.hscli/logs/ contains no additional diagnostic information.
Environment:
CLI version: @hubspot/cli ^7.11.2
Platform version: 2026.03
Is there a documented limit on the number of modules per CMS project?
Hey! I think the “99-module limit” framing is leading you down the wrong path.
There’s no documented modules-per-project limit. I checked the project structure docs and the CLI project command reference and neither specifies a cap on module count, file count, or build-validation duration. The published CMS limits are all different in kind (HubL per-render limits, serverless caps, dynamic-page record limits). So the 99→pass / 100→fail boundary isn’t a spec’d rule you’re crossing.
Your own two observations seem to point away from a per-module timeout:
The failing module changes every run (header, footer, etc.).
Removing any one module fixes it.
If there were a real 30-second per-module validation timeout, it would fail on the same slow module every single time. The fact that it rotates and the hard count boundary. Might rather point to a total build/validation duration ceiling. Your project’s server-side build is landing right around the 30s wall; when it trips, the error just names whichever module happened to be in flight at that instant. Drop one module and total time dips back under → it passes. So it’s likely rather about total work per build, not any individual module and not the number 100 specifically.
This would also explain why --http-timeout didn’t help. That flag controls how long the CLI client waits on the socket, but it doesn’t affect how long the build server is allowed to run. There’s no CLI flag that extends the server-side validation window, which matches what you’re seeing.
What I’d actually do:
Reduce per-build work: split the theme into smaller projects/builds, or trim module complexity (heavy fields, large meta.json, expensive HubL) so total validation drops well under the wall.
Open a Support ticket and reference build #532 directly: The ~/.hscli/logs/ file is client-side only and won’t show anything useful here. Support can pull the server-side build logs for that build ID and tell you exactly what timed out. That’s the only way to confirm whether it’s a plan-specific/internal limit vs. a genuinely slow build.
I’d also separate the mitigation from the root-cause proof here. The rotating failing module strongly suggests the project is crossing a total server-side validation budget, not that module #100 is special.
For mitigation, I’d try this order:
Update @hubspot/cli to the latest version and re-run once, just to rule out a client/project packaging issue.
Split the shared modules into smaller deployable groups if the project structure allows it.
Temporarily remove the heaviest modules first: large field groups, repeated rich text fields, complex HubL, or modules with lots of defaults.
If you open Support, include the build ID, exact timestamp, CLI version, project platform version, and the 99-pass / 100-fail reproduction.
The key evidence is that any removed module makes it pass. That is the useful part for Support because it points to aggregate validation time rather than one broken module.
Just to confirm from my experience:
Marketplace themes are limited to a max. of 50 modules.
Custom themes (at least HubL themes) don’t have such a limitation.
Furthermore, custom HubL themes are being handled differently by the system, therefore they don’t have such a thing as a timeout while uploading.
As reworking your React theme to a HubL theme most likely won’t be the answer you’d love to hear/read, I’d - like @danielsinewe - recommend to split the theme into smaller parts.
A different option could be to look into all modules if they’re really required and remove those which aren’t.
Something I’ve done in the past is merging similar modules into a bigger one to save module count (in your case validation time).
Example:
If you got 3 accordion modules which differ only slightly (maybe layout), I’d add a choice option to the module like “Choose layout”; “option a”,“option b” or “option c”.
Depending on the selected option, fields might appear/disappear from the page editor and the layout would change as the individual layouts would be wrapped in an if-statement.