Hello Retool team,
Following on from a separate question I posted recently - we're continuing
an internal access-control review of our self-hosted instance, and I would
appreciate clarification on two behaviors we've observed.
Our environment
- Self-hosted Retool (Docker Compose, single host)
- Version 3.334.x
- Business plan
What we're seeing
- When a query defined inside an app fails, the HTTP response returned to
the browser includes the raw database error message, which can contain
SQL fragments and table or column names. Turning off "Show notification
on failure" suppresses the in-app notification only - the response body
itself is unchanged.
- For users who can open an app, the app definition delivered to the
browser includes the text of the queries defined within that app, so the
SQL is visible to a user who only needs to run the app.
If you could help with the following, it would be much appreciated:
- On the Business plan with 3.334.x, is there any supported way to prevent
raw database error details from being included in the query responses
returned to the client?
- If not, is such a control available in the currently supported stable
lines, 4.0 and 4.34? And is it gated by plan, by version, or both?
- On the Business plan with 3.334.x, is there any supported way to prevent
the text of app-level queries from being delivered to the client for
users who only need to run the app?
- The documentation describes Enterprise object-level permissions as not
being supported on self-hosted deployments. Could you confirm whether
that is correct, and if so, whether there is an equivalent mechanism
available for self-hosted instances?
- Where these controls aren't available at our tier, would configuring
resources with least-privilege database credentials be the recommended
mitigation? We'd like to be sure we're following the approach Retool
recommends, rather than restructuring our apps unnecessarily.
Thank you very much for your time - I'm happy to provide further detail if
that would help.
Best regards
Summary
On a self-hosted Business instance (v3.334.x), raw database error messages (including SQL fragments and table/column names) are returned in query failure response bodies, and the app definition delivered to the browser exposes the full text of app-level queries to anyone who can run the app. Clarification is requested on whether supported controls exist to suppress these—by plan or version—whether object-level permissions apply to self-hosted, and whether least-privilege database credentials is the recommended mitigation.
AI Response
There is no documented setting that strips raw database error details or query text from the payload delivered to the client; the 'Show notification on failure' toggle only suppresses the in-app notification, as observed, and no affirmative supported control for redacting the response body could be found. The mechanisms Retool documents for limiting what app users can actually reach are resource permission levels (Use/Edit/Own) and, more granularly, Access policies, which enforce table-, column-, and row-level restrictions on every query run against a PostgreSQL resource—moving access decisions out of individual apps/queries and into the resource itself. Access policies are documented as rolling out on both cloud and self-hosted and are the closest equivalent to object-level data controls for a self-hosted deployment, though these are 4.34-line capabilities rather than 3.334.x. Because anyone connecting to the database directly with a resource's credentials is not subject to access policies, configuring each resource with least-privilege database credentials remains a sound and recommended foundational mitigation regardless of tier or version. Note that these permission and access-policy features are documented at the Business/Enterprise level on the 4.34 stable line, so upgrading from 3.334.x would be required to use them.
Sources
Access policies | Retool Docs
Documents Access policies, which enforce table/column/row-level data access on every query against a PostgreSQL resource (rolling out on self-hosted) and notes that direct database connections bypass them—supporting least-privilege credentials as a mitigation.
Manage permissions for resources | Retool Docs
Explains resource permission levels (Use/Edit/Own) and object permissions via roles on the Business/Enterprise 4.34 line, the supported way to control who can run or edit queries against a resource.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a 
, 
, or 
. Or by marking this post as the "Solution"! Let us know if you have any feedback here. 
Thanks for the detailed response.
I understand this thread received an automated AI response, so I'd like to
ask whether someone from the Retool team could confirm a few points. We
need to cite this in a formal internal compliance review, so a confirmation
from Retool itself would be very helpful.
Most of our resources are Microsoft SQL Server, not PostgreSQL, so the
first question matters most to us.
-
Access policies are described in the documentation in terms of
PostgreSQL resources. Do access policies apply to SQL Server resources
as well? If not, is there an equivalent table/column/row-level control
for SQL Server on any current line?
-
Could you confirm that access policies and resource permission levels
are available on the Business plan (4.34 line), or whether Enterprise is
also required?
-
The response noted that access policies are "rolling out" on self-hosted.
Could you confirm their current status on self-hosted 4.34 - generally
available, or still gated?
-
Could you confirm that on Business 3.334.x there is no supported way to
prevent raw database error details, or the text of app-level queries,
from reaching the client - and that "Show notification on failure"
affects only the in-app notification, not the HTTP response body?
-
Most importantly for us: the response described configuring each resource
with least-privilege database credentials as a sound and recommended
foundational mitigation regardless of tier or version, since direct
database connections bypass access policies. Could you confirm that this
is the approach Retool recommends for our tier? We would rather follow
your recommendation than restructure our applications.
Thank you very much.
On 3.334.x this is architectural, not a config gap: query execution results (including error payloads) are sent to the browser so the client can render them, and the app definition (with query text) is served to any user who can open the app — there's no server-side redaction step in between. "Show notification on failure" is purely a UI toggle on top of a response that already contains the raw error. That behavior hasn't fundamentally changed in 4.0/4.34 either; what did move is more granular resource-level and (on Enterprise) object-level permissioning, but neither retroactively strips error detail or query text from the payload delivered to a user who can run the app — those controls gate who can edit/see the app in the builder, not what's in the runtime response.
So yes: least-privilege DB credentials per resource is the right mitigation, and it's the one Retool support will point you to. Concretely: separate resource connections per app/environment scoped to only the tables/views/procedures needed, use a DB role with no access to system catalogs or error-verbose modes, and where possible wrap raw queries in views or stored procedures so the SQL text exposed client-side isn't your actual schema. For the error messages specifically, some teams add a query transformer/postProcessing step that catches failures and returns a sanitized message instead of letting the raw DB error bubble to the client — that's app-level work, not a platform toggle.
Confirmed on the Enterprise-only object-level permissions point: that's real, and there's no self-hosted Business equivalent — it's plan-gated, not version-gated, so upgrading to 4.34 alone won't get you there.