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

**URL:** <https://forum.anna.partners/t/request-to-increase-the-frontend-bundle-size-limit-for-anna-app-publishing/195>\
**Category:** Developers\
**Created:** [July 29, 2026, 1:33am UTC](https://forum.anna.partners/t/request-to-increase-the-frontend-bundle-size-limit-for-anna-app-publishing/195 "2026-07-29T01:33:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![HappyLight](https://avatars.discourse-cdn.com/v4/letter/h/7feea3/32.png) [@HappyLight](https://forum.anna.partners/u/HappyLight)\
**Post date:** [July 29, 2026, 1:33am UTC](https://forum.anna.partners/t/request-to-increase-the-frontend-bundle-size-limit-for-anna-app-publishing/195/1 "2026-07-29T01:33:01Z")

</div>

## 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:

```plaintext
✗ 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.

---

<div class="post-metadata">

**Author:** ![hunter](https://yyz1.discourse-cdn.com/flex033/user_avatar/forum.anna.partners/hunter/32/8_2.png) [@hunter](https://forum.anna.partners/u/hunter)\
**Post date:** [July 29, 2026, 8:16am UTC](https://forum.anna.partners/t/request-to-increase-the-frontend-bundle-size-limit-for-anna-app-publishing/195/2 "2026-07-29T08:16:26Z")

</div>

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:

```bash
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! 🎊