Retool Modules Not Respecting Releases: What's Happening and How to Fix It

If you've built a workflow around Retool modules not respecting releases, you may have already felt the pain: you're developing what you think is a sandboxed version of a module, confident that your pinned release is protecting production — and then you find out live users have been seeing every half-finished change you saved. This isn't a misconfiguration on your end. It was a confirmed bug in how Retool handled module versioning, and this guide explains what happened, how the fix works, and what you need to do right now to protect your apps.

What Is the Expected Behavior for Retool Modules and Releases?

In Retool, Releases exist so you can develop safely. The idea is straightforward: you work on a draft, publish a release when you're ready, and any app pinned to that release stays stable while you continue iterating. This is the same mental model as versioned deployments — your staging changes don't bleed into production until you explicitly promote them.

Modules are supposed to follow the same rules. When an app embeds a module, it should load the published release of that module, not the latest auto-saved draft. If you're pinning a module to latest release, that pin should be honored. That was the promise. For a significant period of time, Retool was not keeping it.

Why Retool Module Changes Were Going Live Immediately

The core issue, confirmed by the Retool team, is that apps embedding a module were always loading the latest saved version of that module — completely bypassing any published release. This means:

• Every time you saved a change inside a module, that change was instantly visible in every production app using that module.
• The Releases tab on a module existed in the UI but had no functional effect on what apps actually loaded.
• Developers building under the assumption that releases provided a safety boundary were unknowingly modifying live apps used by real users.

The Retool team acknowledged this directly: "Releases in Modules until recently were not working." The fix was built and validated internally, but rather than rolling it out immediately to all orgs, Retool placed it behind a feature flag to allow for a controlled migration — because flipping the switch for existing orgs could immediately change which version of a module their apps loaded.

How the Feature Flag Fix Changes Module Release Behavior

Once the feature flag is enabled for your org, the behavior changes as follows:

• Flag ON: Apps load the published release of a module, not the latest save. If your module has a published release, production is locked to it until you explicitly publish a new one.
• Flag OFF (default/legacy behavior): Apps load the latest save of a module, regardless of any published releases.

This is an important distinction. If you enable the flag on an org where modules have unpublished changes that differ from the last published release, apps will immediately stop showing those draft changes and revert to the published version. Make sure you audit your modules before enabling the flag.

How to Enable Pinned Module Releases for Your Retool Org

Retool did not roll this out automatically to protect existing apps from unexpected version changes. To get it enabled, you need to request it manually. Here's the process:

• Open the Intercom chat inside your Retool instance (the chat bubble in the bottom corner of the UI).
• Confirm your identity with the support agent.
• Provide your subdomain (e.g., yourcompany.retool.com) or your self-hosted instance identifier.
• Ask them to enable the module release pinning feature flag for your org.

If you're on a self-hosted or on-premise deployment of Retool, availability of this flag may differ — check with your Retool account contact or support directly, as the rollout timeline for on-prem instances can lag behind cloud.

What to Do Before Enabling the Flag

Before you contact support and flip the switch, take these steps to avoid breaking your production apps:

• Audit every module in your org and check whether it has a published release. Go to the module editor and look at the Releases tab.
• If a module has no published release, any app using it will break or show nothing once the flag is on and Retool tries to load a release that doesn't exist. Publish a release first.
• If a module has a published release but also has significant unpublished draft changes, decide whether those draft changes should become a new release before the flag is enabled.
• Communicate the change to your team. Developers who are used to saving a module and seeing changes in production immediately will need to adjust — they now must publish a release to promote changes to live apps.

The Bigger Lesson: Module Releases Were a False Safety Net

This bug is a good reminder to verify the actual behavior of any safety mechanism you rely on — don't assume that because a UI element exists (like a Releases tab on a module), it is functionally enforced. If your deployment workflow depends on release pinning for modules, test it end-to-end in a staging org before trusting it in production.

Now that Retool has a working fix, module versioning can actually be part of a reliable release workflow. Enable the flag, publish clean releases for all your modules, and treat module promotions the same way you'd treat any production deployment — deliberately and intentionally.