Request to Increase the Frontend Bundle Size Limit for Anna App Publishing

[HappyLight]

Background

We are developing a ppt-app based on Anna App. The app’s home page includes a template selection feature that allows users to choose from multiple visual style presets. Each template contains several preview images. In the current implementation, these images are included as frontend static assets and packaged together with the frontend application in the bundle.

We chose this approach for several practical reasons:

• Images are published together with the app, simplifying deployment and version management.
• Template preview images do not depend on an additional runtime service or cross-origin requests.
• The frontend can load the static assets directly, without routing requests through an additional application API when users open the home page.
• Template previews are read-heavy and rarely modified. Keeping them fixed within the build artifacts makes their behavior more predictable.

As the number of templates and preview images per template increases, the frontend bundle also becomes larger. Template preview images now account for a substantial portion of the build output.

Issue

When publishing the app with anna-app apps publish, the platform returns the following 422 validation error:

✗ request failed (422): {"detail":[{"type":"less_than_equal","loc":["body","total_size_bytes"],"msg":"Input should be less than or equal to 52428800","input":276465952,"ctx":{"le":52428800}}]}

Based on this error, the total_size_bytes limit for a publish request appears to be 52,428,800 bytes (50 MiB). The current total app size is 276,465,952 bytes, so the app cannot be uploaded.

Impact

This limit prevents apps containing a large number of image assets from being published. For apps centered around template catalogs, asset libraries, or example galleries, it is common for static resources to reach tens or even hundreds of MiB.

Moving all images out of the frontend bundle would require additional infrastructure and logic for image hosting, runtime downloads, caching, version synchronization, and asset availability. This would significantly increase architectural and operational complexity and could also affect the loading speed and reliability of template previews on the home page.

Request and Suggestions

Would the Anna platform consider increasing or removing the size limit for an app’s frontend bundle—or, more precisely, the publish request’s total_size_bytes limit?

We would appreciate support through at least one of the following options:

1. Increase the default publishing limit to support apps containing a larger number of static image assets.
2. Provide a higher quota for reviewed apps or apps that explicitly declare the purpose of their bundled resources.
3. Provide an Anna-managed static asset or CDN solution, allowing apps to use large image assets without requiring a separately hosted service while retaining versioning and caching capabilities.

If the current limit must remain in place for performance, storage cost, or security reasons, we would appreciate an officially recommended approach for splitting and hosting these resources. Ideally, the guidance would also clarify caching behavior, release versioning, offline or poor-network behavior, and any applicable asset size limits.

Additional Information

• App type: Anna App
• Publishing command: anna-app apps publish
• Primary large assets: Template preview images
• Current publishing package size: 276,465,952 bytes
• Platform limit shown in the error: 52,428,800 bytes

Thank you for helping us understand the rationale behind this limit and the recommended implementation approach for apps with a large volume of static assets.

[hunter]

Hi @HappyLight!

Thank you for the wonderfully detailed report — the exact 422 payload, the size numbers, and your architecture reasoning made this a joy to work on. And you’re right on every point: template previews are a legitimate use case for bundled static assets, and the platform’s bundle pipeline was already built to handle much more than the old limit allowed.

Fixed — limits raised & smarter uploads

This shipped in platform v1.1.0-beta.104 together with CLI @anna-ai/cli@0.1.42:

Limit	Before	Now
Total bundle size	50 MiB	1 GiB
Single file size	10 MiB	50 MiB
Files per bundle	—	2,000

Your 276 MB ppt-app bundle will now publish without any workarounds. Just update the CLI:

npm i -g @anna-ai/cli@latest   # ≥ 0.1.42
anna-app apps publish

Bonus: content-addressed deduplication

Since large bundles are mostly stable assets (exactly your case — read-heavy, rarely modified), we didn’t just raise the number. Bundle storage is now content-addressed:

• Re-publishing is fast — files the platform has already seen (by SHA-256) are skipped automatically; only new/changed files upload. The CLI (≥ 0.1.42) handles this transparently.
• Cutting a new version is (nearly) free — unchanged assets are referenced, not copied, so iterating on a 276 MB app doesn’t multiply storage per version.
• Assets keep serving from versioned, immutable URLs with edge caching — your “no extra runtime service, no cross-origin requests” approach continues to work exactly as before.

A generous per-developer storage quota applies across your apps; with dedup you’re very unlikely to notice it.

A few friendly tips for image-heavy apps

• WebP/AVIF for previews — template preview grids typically shrink 5–10× with no visible quality loss, which also means faster first paint for your users.
• Very large single assets (> 50 MiB) — e.g. model files or media packs — are better shipped via Executa binary distribution rather than the UI bundle.
• We’ve published an official static assets guide covering caching behavior, version semantics, and size recommendations — worth a look for template-catalog apps like yours.

Thanks again for pushing the platform forward — reports like this one directly shape what we build. Happy publishing!