We're blocked from launching our app publicly because of this warning in General Access:
"Dynamic resource queries won't work in public apps. This app has 86 queries that select their resource dynamically. They will fail for users accessing the public app without signing in."
When testing our QA app as a public (signed-out) user, the first query in the flow (a login mutation) fails with:
{"status":403,"message":"Dynamic resource queries are not allowed in public apps.","statusCode":403,"error":"Forbidden"}
Our queries use dynamic resource mode (the Ζ button) with a JS function like:
What's strange: our original production app uses this exact same pattern and is currently live and publicly accessible WITHOUT this error. That app is sharing an older pinned release rather than the latest editor state.
Questions for the community / Retool team:
Is this restriction evaluated only at publish/release time (so older releases created before the restriction existed are grandfathered in), or enforced in real time regardless of release date?
Is "Dynamic resource queries are not allowed in public apps" a recently introduced policy? Does anyone know when it was rolled out?
We're on a non-Enterprise plan (no Source Control / Git). Besides manually disabling dynamic mode on every affected query, is there a supported way to bulk-update queries (e.g. via the Retool API)?
For apps needing to switch between environment-specific resources (dev/staging/production) in a public app without hitting this restriction β is configuring environment-specific credentials on a single resource (instead of dynamic resource mode) the recommended pattern?
Any pointers appreciated β happy to share more details if useful.
Hi WidleStudioLLP, thanks for checking! I don't think this reproduces our issue though.
You tested while signed into Retool as a builder β dynamic resource selection works fine in that case. Our issue only happens when accessing the app via the Public share link while fully signed out of Retool (our app's own "Sign in with Google" is a separate auth system, not Retool's).
Also, we're not doing dynamic SQL text β we're dynamically selecting the resource itself (via the Ζ button next to Resource ID), which Retool flags differently:
Attaching two screenshots: the General Access warning, and the actual 403 error we get when opening the public link signed out.
Could you try reproducing via an incognito window on the actual public share link (fully signed out)? That's where we consistently see the block, even though the same query works fine in the editor.
The issue is caused by dynamic resource selection, which Retool does not support in Public Apps. Since public users are not authenticated with Retool, queries using a dynamic Resource ID are blocked and return a 403 error. The recommended fix is to replace the dynamic resource with separate queries that use static resources (e.g., one for staging and one for production) and trigger the appropriate query based on the environment. Alternatively, use separate apps for each environment or avoid using Public Apps if dynamic resources are required.
I noticed that you have reached out to Support already and got an answer from the team about this!
For those who come across this thread, this info was shared:
Is the restriction evaluated at publish time or in real time?
The restriction is stamped onto an app at creation time and enforced at query execution time. So apps that existed before this restriction was introduced are not affected and continue to work as they always have. Apps created after this restriction are blocked.
Is this a recently introduced policy?
Yes, this is a security improvement that was rolled out to Retool Cloud at the end of June to address a vulnerability, and it is a permanent change.
Is there a supported bulk-update method to convert the 86 queries?
Unfortunately there is no API endpoint to bulk-convert your dynamic resource queries to static ones. (but the below suggestion in #4 below may be helpful to you in not having to touch all 86 of your queries)
Is configuring environment-specific credentials on a single resource the recommended approach?
Yes, this is the right pattern for public apps. Instead of maintaining separate resources and selecting between them dynamically at runtime, you can configure one resource and add separate credentials per environment (production, staging, or any custom environments you choose to set up). Retool will apply the correct credentials automatically based on the active environment and the queries themselves use a single static resource name.
