Security checklist for self-managed Retool

A checklist of security controls to apply before and after deploying self-managed Retool.

Use this checklist to apply security controls before launching your Retool instance and to maintain a strong security posture over time. For detailed configuration instructions, refer to the security hardening guide.

Pre-launch checklist

Complete these steps before your first users access the instance.

Credential rotation schedule

Rotate credentials on a regular schedule, not only after suspected compromise.

Credential	Minimum frequency	Guide
ENCRYPTION_KEY	Annually, or after suspected compromise	Rotate encryption key
SSH tunnel keys	Per your organization's policy	Rotate SSH keys
Platform database password	Per your organization's policy	Your database provider's documentation
Secrets manager service account tokens	Per your organization's policy	Your secrets manager's documentation

After rotating the encryption key, verify that Retool can still decrypt stored resource credentials before removing the old key.

Ongoing controls

• Periodically review audit logs for unexpected sign-in activity, resource access, or privilege changes. Enable LOG_AUDIT_EVENTS to stream audit events to your centralized logging system.
• Apply upgrades promptly. Security patches ship in Retool releases. Stay within 10 versions of the current release and monitor the releases page for security-relevant changes.
• Use RESOURCE_TYPES_DENY_LIST and RESOURCE_TYPES_CREATION_DENY_LIST to prevent access to integration types not approved for your environment. Refer to the resource restrictions guide.
• Disable unused features. If you do not use public app sharing, set DISABLE_PUBLIC_PAGES. If you use source control to manage app changes in production, set VERSION_CONTROL_LOCKED to prevent direct edits.