Cloudflare Free deployment is approaching Worker and static asset size limits

[LJAYi]

Problem

The v1.3.3 Cloudflare build is now very close to both size limits on the Workers Free plan.

Measured by the deployment workflow with wrangler deploy --dry-run --minify:

• Worker gzip: 2854.75 KiB / 3,000,000 bytes (~97.4% of the Free limit)
• dist/web/catalog/apps.json: 24.54 MiB / 25 MiB (~98.2% of the per-asset limit)
• Static asset count: 11 / 20,000

The application builds cleanly and all tests pass, but a downstream deployment guard had to be temporarily relaxed to install v1.3.3. The next catalog/provider growth is likely to make Cloudflare Free deployments fail.

Findings

1. The catalog is combined into one large asset

catalog/apps/ already contains one JSON file per provider, but scripts/copy-catalog-assets.ts combines all 1,194 providers and 12,743 actions into a single /catalog/apps.json. src/server/cloudflare/catalog-assets.ts then reads that one asset during Worker initialization.

This creates an avoidable 25 MiB single-file bottleneck.

2. The Worker embeds every executable action ID

registry.cloudflare.generated.ts contains both the lazy executor import map and arrays for every action ID. The generated action arrays contain 12,743 repeated <service>.<action> strings.

The Wrangler esbuild metafile attributes about 460 KB of minified output to registry.cloudflare.generated.ts. The current generator already treats every definition action of an included provider as executable, so the same execution status can be represented by provider service IDs and expanded from the loaded catalog at startup.

3. Provider executors remain the long-term Worker-size driver

The metafile attributes roughly 10.3 MB of the 11.9 MB minified Worker output to provider modules. Removing the repeated action registry should recover immediate headroom, but executor sharding or more generic runtimes may eventually be needed as the catalog continues to grow.

Proposed backward-compatible changes

A. Shard the Cloudflare catalog asset

• Write a small versioned manifest plus deterministic catalog chunks (for example, target <= 4 MiB each) instead of one monolithic apps.json.
• Load the manifest and chunks through the existing ASSETS binding.
• Keep an apps.json fallback in the loader during the transition if desired.
• Preserve the existing in-memory CatalogStore and public /api/providers / /api/actions/:id response formats.

A small fixed number of chunks avoids both the 25 MiB file limit and excessive Worker subrequests.

B. Generate executable services instead of executable action arrays

• Keep the lazy executorModules registry.
• Stop emitting every action ID into the generated registry.
• Pass the registry service keys to createCatalogStore.
• Derive the exact executableActionIds set from catalog actions whose provider service is present.

This should be semantically equivalent to the current generator while removing thousands of repeated strings from the Worker bundle.

Questions

1. Would maintainers prefer these as one Cloudflare-size PR or two smaller PRs?
2. Is a versioned index.json plus ~4 MiB chunks acceptable for the internal Cloudflare catalog asset format?
3. Is service-level executable marking acceptable given that the current registry generator already marks every definition action for an included provider as executable?

I can prepare a draft implementation with size measurements, compatibility tests, and before/after Wrangler output.

[l1shen]

Thanks for the detailed analysis and data. We reviewed the current implementation and agree that both findings are accurate.

We would prefer to split this into two PRs:

1. Remove the executable action ID arrays from the generated registry.
2. Add a manifest and chunking for the Cloudflare catalog.

Service-level executable marking is acceptable. The current generator already marks every action from each provider included in the registry as executable, so we can use Object.keys(executorModules) as the service set, derive the exact executableActionIds after loading the catalog, and continue passing them to createCatalogStore. This preserves the existing runtime semantics and public response shapes.

Based on an initial measurement of the current generated file, this should remove roughly 378 KB of minified JavaScript and reduce the final Worker gzip size by an estimated 65–80 KiB. Please include the actual before-and-after Wrangler output in the PR.

A versioned index.json with deterministic catalog chunks is also acceptable. Each chunk should be kept at roughly 4 MiB or less based on its final UTF-8 byte size, and new builds should no longer emit the complete apps.json. The loader may retain an apps.json fallback for the transition, but new assets do not need to contain both formats. The existing CatalogStore and public API response shapes should remain unchanged.

The longer-term provider executor size issue can be handled separately and does not need to expand the scope of these two PRs.

Please start with the executable services PR, then follow up with the catalog chunking PR.

[LJAYi]

Thanks again for reviewing the proposal and confirming the implementation direction. I split the work into the two requested PRs:

1. fix: reduce executable registry size #237 removed the generated executable action ID arrays and was merged. The measured Worker reduction was 368.79 KiB minified and 76.71 KiB gzip.
2. fix(cloudflare): shard catalog assets #243 implements the versioned index.json and deterministic catalog chunks. It is now ready for review, with CI and CodeRabbit passing and no remaining actionable comments.

On the current catalog with 1,210 providers and 12,894 actions, the legacy apps.json is 26,030,332 bytes (24.8245 MiB), leaving only about 180 KiB before Cloudflare’s 25 MiB per-asset limit. The new build produces 7 chunks, with the largest at 4,192,730 bytes (3.9985 MiB), and no longer emits the complete apps.json.

The additional Worker cost is small: approximately 1.97 KiB minified and 0.75 KiB gzip. The loader retains the legacy apps.json fallback while preserving the existing CatalogStore, executable-action resolution, and public API response shapes.

#243 is ready for maintainer review and will close this issue once merged.