Clarification on the "Manage configuration variables" permission - plan vs. version requirement (self-hosted 3.334.x)

[Resource_Bot]

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.