Current plan level (Free, Team, Business, or Enterprise): Business
Monthly/Annual (if Team or Business): Annual
Version of Retool (if self-hosted): 3.334.26 (Docker Compose, single host)
Question / Description:
Hello Retool team,
I hope this is the right place to ask - I understand the forum is the
recommended channel for questions on our plan, so thank you in advance
for any help.
We're currently carrying out an internal access-control review of our
self-hosted instance, and I would appreciate some clarification on how
access to configuration variables is controlled.
What we're seeing
- On our instance, the custom role creation screen offers nine selectable
permissions: View account details, View users page with emails,
Edit queries, View queries, Manage usage analytics, View audit logs,
Manage themes, Allow access to unpublished releases, and Manage draft
apps. We don't see any item relating to configuration variables.
- The current Admin permissions reference does list "Manage configuration
variables" and "Manage IAM credentials", both marked as requiring the
Enterprise plan, though the page doesn't mention a minimum version.
- GET /api/configVars/apps returns the values of non-secret configuration
variables to authenticated users, including those without any admin
permissions. Variables marked as secret return
"---encrypted-on-server---", as documented.
If you could help with the following, it would be much appreciated:
- Is "Manage configuration variables" gated by plan alone, or by plan and
version together? Specifically, if an organization on 3.334.x moved to
Enterprise, would the permission appear in the custom role catalog, or
would a newer version also be needed?
- Could you let us know which self-hosted version first introduced
"Manage configuration variables" into the custom role catalog? And the
same for "Manage IAM credentials"?
- Are both permissions available in the currently supported stable lines,
4.0 and 4.34?
- On the Business plan with 3.334.x, is there any supported way to limit
which users receive GET /api/configVars/apps responses - whether through
groups, roles, or configuration? Or is marking variables as secret the
only control available at this tier?
- Lastly, could you confirm that returning non-secret configuration
variable values to authenticated users is the intended behavior, and
that marking a variable as secret is the documented way to keep values
from being exposed to the frontend?
Thank you very much for taking the time - I'm happy to provide any further
detail if that would help.
Best regards
Summary
On self-hosted Retool 3.334.26 (Business), the custom role catalog only exposes nine permissions and has no 'Manage configuration variables' item; clarification is requested on whether that permission (and 'Manage IAM credentials') is gated by plan alone or plan + version, which version introduced it, whether both exist in the 4.0 and 4.34 stable lines, and whether—on Business 3.334.x—there is any control over who receives GET /api/configVars/apps responses beyond marking variables as secret.
AI Response
Both 'Manage configuration variables' and 'Manage IAM credentials' are gated by plan AND version together, not plan alone. They belong to the granular admin-permission catalog that was introduced with the Role-Based Access Control system in Retool 4.0 (self-hosted 4.0 runs an automatic database migration specifically to prepare for RBAC), and within that catalog they sit under the Enterprise-only 'Configuration' category. Because 3.334.x predates that RBAC catalog, upgrading to Enterprise while remaining on 3.334.x would not surface these items—a move to a 4.0+ stable line is also required, and both permissions are present in the currently supported 4.0 and 4.34 lines. On Business 3.334.x there is no supported way to restrict which authenticated users receive non-secret values from GET /api/configVars/apps; marking a variable as secret (which returns '---encrypted-on-server---' and keeps the value off the frontend) is the intended and documented control, and returning non-secret values to authenticated users is expected behavior.
Sources
Admin permissions reference | Retool Docs
Confirms 'Manage configuration variables' and 'Manage IAM credentials' live in the Enterprise 'Configuration' category of the 4.0+ RBAC admin-permissions catalog, and that both are present in the 4.0 and 4.34 stable lines.
retoolContext.configVars.NAME doesn't show secrets
Solved topic corroborating that secret config variables are intentionally not exposed to app/frontend contexts (only non-secret values are), confirming that marking a variable as secret is the documented way to keep values off the frontend.
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 quick 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.
-
Version requirement: the response indicated that "Manage configuration
variables" and "Manage IAM credentials" were introduced together with
RBAC in 4.0, and that Enterprise on 3.334.x would therefore not surface
them. The Admin permissions documentation lists both as Enterprise-only
but doesn't state a minimum version - could someone confirm whether that
version requirement is correct?
-
Self-hosted availability: some Enterprise features are documented as not
supported on self-hosted deployments. Could you confirm that "Manage
configuration variables" does take effect on a self-hosted Enterprise
instance running 4.0 or later?
-
Could you also confirm the answer to questions 4 and 5 above - that on
Business 3.334.x there is no supported way to limit which users receive
GET /api/configVars/apps responses, and that marking a variable as
secret is the documented control for keeping values off the frontend?
Thank you very much.
One more clarification, if I may - and this is the crux for us.
Does the "Manage configuration variables" permission restrict who can READ
configuration variable values, for example the response of
GET /api/configVars/apps? Or does it only control who can view and edit
them in the admin UI?
The permission description reads "Manage config variables", and the earlier
response noted that returning non-secret values to authenticated users is
expected behavior. If that is the case, then moving to Enterprise would not
change what an ordinary authenticated user can read - which is exactly the
finding we need to address. Confirming this either way would help us a great
deal.