Our development team is experiencing a critical issue where changes made in the Retool editor are discarded upon page refresh. This is specifically affecting a large, multi-page application on our self-hosted instance (Docker) using Source Control.
When making edits -- specifically adding or copy-pasting components like containers and buttons -- the app fails to persist the state. Upon refresh, the app reverts to the last "known good" state, and the "Commit" button often shows no pending changes because the underlying save never registered.
Technical Breakdown
Upon inspecting the browser’s Network tab, we identified that when the "revert" occurs, the /save request returns a 413 Request Entity Too Large error.
Crucial Observations:
Infrastructure Limits: Our team has already increased the client_max_body_size on our proxy/ingress, but the erorr still persists.
Small Payloads: In many cases, the actual size of the payload in the failed request is small, yet it still triggers a 413 response.
Component Threshold: The app has a high component count. Adding even basic container components can trigger the failure. If we remove the new components, the app saves successfully; if we add them back, the 413 returns.
Environment Details
Deployment: Self-hosted (Docker)
Feature: Retool Source Control (Git-protected) enabled.
App Context: Complex, multi-page architecture with high component density.
Questions for Retool Engineering
Internal Middleware Limits: Is there a secondary, internal body size limit within the Retool backend or containers that is independent of the external proxy/Nginx settings?
Metadata Complexity: Since the payloads are small but the app is "large" in terms of component count, is it possible the 413 is masking a metadata validation or recursion depth error rather than a literal byte-size issue?
Any guidance on where how to resolve this internal bottleneck would be greatly appreciated. Thank you in advance.
Additionally, I’ve heard through industry/team discussions that there may be a practical or intended threshold of around 1,500 components for Retool applications.
Could the Retool team provide clarity on whether there is a documented or 'soft-cap' component limit, especially for multi-page apps?
I’d also like to clarify how modules impact these internal thresholds. When a module is placed within a parent app, how is it calculated toward the 'massive app' performance limit? Does it count as a single component in the parent app’s metadata? Or does every individual component within that module continue to count toward the total in the parent app?
If such a threshold exists -- knowing this would significantly shift architectural expectations. That knowledge would help determine if it's possible to continue building within a single app or if pivoting to a more granular, interconnected 'micro-app' strategy to avoid these persistence failures would be more ideal.
Clarification on whether the 413 error can be triggered by component count metadata complexity (even when the transfer payload is small) would be incredibly helpful for our long-term planning.
Thank you in advance for any additional information.
This usually means the save path is still hitting a body-size limit somewhere after the browser, even if the payload shown in DevTools looks small.
A couple things I’d check first:
1. Confirm every hop that handles `/save`, not just the public ingress. On self-hosted Retool it’s easy to raise `client_max_body_size` at the edge and still have another nginx / app container / LB limit behind it.
2. Compare a successful save request vs a failing one using the exact response headers. If the 413 is coming from your proxy layer, the `server` header usually gives it away fast.
3. If source control is enabled, test the same app with source control temporarily disabled in a non-prod clone. That helps separate "large app metadata / diff generation" issues from a pure transport limit.
On the architecture side, I would not assume modules count as just one cheap wrapper. In practice, once an app gets very component-dense, editor/save behavior tends to degrade before the raw request size tells the full story. Splitting the app into smaller pages or modules is often the safer path anyway.
If you can share which container is actually returning the 413, you’ll probably narrow this down a lot faster than chasing the component-count theory by itself.
I'll echo most of everything shared above, @AJVancattenburch, but might be able to answer some of your specific questions. To start, the Retool backend does enforce a 100MB request body limit, but I doubt you're approaching anything near that. Also, the hand-wavy component limit that you may have heard mentioned is almost entirely related to frontend performance and is a functional result of the math that Alice mentions here.
This certainly sounds like a classic case of an infrastructure bottleneck - usually nginx, ingress controller, or WAF - but you mention having already checked those surfaces. Have you definitively confirmed that the /save event is actually reaching the Retool backend? If you don't see it in the logs, it's definitely dying somewhere in your infrastructure.
Thank you in advance.