Retool Security Guide: Internal Tool Protection

TL;DR

Retool talks straight to your production database. That's the whole appeal, and it's also the whole risk. Give it a database user with the narrowest permissions that still work, put your team behind SSO, set app permissions per group, and turn on audit logging. Self-hosting earns its keep once the data is genuinely sensitive. Never hand Retool admin database credentials.

Understanding Retool Security

The power and the risk come from the same place. Retool reaches your data sources directly:

  • Direct database access: Queries run against your actual databases
  • API connections: Can call your internal APIs
  • Resource permissions: Control who can use which connections
  • Deployment options: Cloud or self-hosted

Database Connection Security

If you fix one thing on this page, make it this one:

Create Dedicated Database Users

  • Don't use admin credentials for Retool connections
  • Create specific users with limited permissions
  • Grant only SELECT, INSERT, UPDATE, DELETE as needed
  • Never grant DROP, CREATE, or ALTER permissions

Critical: Give Retool admin database access and a single bad query, whether it comes from a bug or from a person, can delete or corrupt the whole database. Use the least privilege that still lets the tool do its job.

Connection Configuration

  • Enable SSL/TLS for all database connections
  • Use environment variables for credentials
  • Consider IP allowlisting for database access
  • Regularly rotate database credentials

User Permissions

Who can open what, and who can change it:

Permission Levels

  • Admin: Full access, use sparingly
  • Developer: Can build and edit apps
  • User: Can only use apps they're granted access to

App-Level Permissions

  • Restrict sensitive apps to specific groups
  • Use viewer-only access when editing isn't needed
  • Review permissions regularly

Authentication

Enable SSO

  • Use SSO (SAML, OIDC) for enterprise authentication
  • Enforce MFA through your identity provider
  • Automatic user provisioning and deprovisioning

Session Security

  • Configure appropriate session timeouts
  • Enforce re-authentication for sensitive actions

Query Security

The query is where most of your real access control lives:

Parameterized Queries

  • Always use prepared statements
  • Never concatenate user input into SQL
  • Use Retool's built-in parameterization

Data Filtering

  • Filter data by user/team in queries
  • Don't rely solely on UI hiding for security
  • Assume users can see any data the query returns

Best practice: If someone shouldn't see a column, leave it out of the query. Hiding it in the UI isn't security, it's decoration.

Audit and Monitoring

  • Enable audit logging
  • Monitor for unusual query patterns
  • Review access logs regularly
  • Set up alerts for sensitive operations

Self-Hosted vs Cloud

When to Self-Host

  • Highly sensitive or regulated data
  • Strict data residency requirements
  • Need for network isolation
  • Compliance requirements (HIPAA, etc.)

Cloud Security

  • SOC 2 Type 2 certified
  • Encrypted at rest and in transit
  • Regular security audits

Is Retool secure for sensitive internal data?

Yes, when properly configured. Retool is SOC 2 Type 2 certified and offers self-hosted deployment. Security depends on your configuration: database connection security, user permissions, and audit logging. Don't give tools more database access than needed.

How do I secure database connections in Retool?

Use read-only database users when possible. Create specific database users for Retool with minimal permissions. Enable SSL for database connections. Consider using Retool's environment variables for credentials rather than storing them in queries.

Can Retool users access data they shouldn't see?

That depends entirely on how you set it up. User groups and app permissions control who can open which apps. The part that actually decides it is the query, though. If it returns rows a user shouldn't see, no permission setting will save you.

Should I use cloud or self-hosted Retool?

Cloud is fine for most teams, and it's SOC 2 Type 2 certified. Self-host when the data is genuinely sensitive, when compliance demands it, or when it simply cannot leave your network.

Building Internal Tools?

Make sure your data connections are secure.

Tool & Platform Guides

Retool Security Guide: Internal Tool Protection