Self-hosted Retool requirements

Learn about deploying and managing self-hosted Retool.

Deploying Self-hosted Retool on your own infrastructure lets you build applications with data in your virtual private cloud (VPC) or behind your virtual private network (VPN). Businesses in the healthcare and finance industries often deploy Retool to remain compliant.

You can deploy self-hosted Retool on almost any Linux-based VM cloud provider using Docker Compose. The available deployment methods vary in complexity and scalability, so you should choose an option that lets you get started quickly, is provisioned appropriately, and sets you up for long-term success.

VM configuration

Choose between a single VM deployment or an orchestrated container deployment method based on your background and use case.

Single VM deployments

Use a Docker Compose-based method to deploy Retool if you and your team:

• Are currently evaluating Retool or deploying Retool for the first time.
• Have less experience with Docker or DevOps concepts.
• Need a lightweight, low cost, and low maintenance deployment method.
• Want to deploy Retool on a small-scale or single-server environment.

Retool images run on Linux machines using x86 processors—arm64 is not supported. You must ensure the VM meets the following recommended requirements:

• Ubuntu 22.04 or later.
• 16GiB memory.
• 8x vCPUs.
• 60GiB storage.
• curl and unzip software packages installed.

The 60 GiB of storage is required to support the PostgreSQL container included by default in Retool's deployment configuration files.

Orchestrated VM deployments

If you're evaluating a large production use case or need any of our Enterprise plan features, please book a call.

More complex and scalable deployment methods, such as Kubernetes or Elastic Container Service (ECS), might be appropriate if you and your team:

• Already use the chosen deployment method.
• Have experience with Docker or DevOps concepts.
• Require scalability, high availability, and resilience.

When deploying Retool using container orchestration tools such as Kubernetes, your cluster should contain at least one node that matches the specifications above. Refer to deployment guides and your provider's documentation for more detail.

Storage database

By default, many of the deployment guides include a containerized instance of PostgreSQL alongside Retool, but it is possible and recommended to externalize the database to support a stateless deployment.

The minimum recommended version for the PostgreSQL database is version 13. Your PostgreSQL database must also enable the uuid-ossp module and use the Read Committed isolation level.

The storage database, whether it's the containerized instance of PostgreSQL or an externalized database, can contain many different tables to support deployment functions. The following table includes a list of those most commonly used.

Retool strongly recommends against performing manual edits to these databases. Doing so can damage the instance.

Table	Includes data relating to
app_observability_provider_configs	Observability setup and streaming details.
audit_trail_events	Events that feed audit logs on user instances with the /audit endpoint.
grid_managed_cluster_resources	Retool Database when linked to an external PostgreSQL database.
grid_managed_clusters	Retool Database when linked to an external PostgreSQL database.
organizations	Spaces within the organization.
page_saves	Changes made to specific apps since they were created.
resources	Resources, including full setup and configuration information.
users	All enabled and disabled users.
user_task_instance	Workflows that include user task blocks.

Full list of external database tables

access_control_list_members
access_control_lists
access_levels
api_keys
app_metadata
app_themes
approval_task_executions
approval_task_items
approval_task_votes
appstore_tags
async_jobs
bad_passwords
block_saves
blocks
blueprints_appstore_tags
blueprints
branches
commits
component_metadata
config_var_values
config_vars
custom_component_collection_revision_files
custom_component_collection_revisions
custom_component_collections
custom_domains
dg_activity
dg_bulk_edit
dg_grid
dg_single_edit
email_verification_tokens
embeds
environment_config_vars
environments
event_workflows
experiment_audiences
experiment_strategies
experiments
external_embed_sessions
external_users
features
flow_input_schemas
flow_queries
flow_stages
flow_task_histories
flow_task_inputs
flow_tasks
flows
folder_favorites
folders
form_fields
forms
grid_field
grid_group_access
grid_table_group_access
grid_table_user_access
grid_user_access
grid_view
group_folder_defaults
group_pages
group_resource_folder_defaults
group_resources
group_workflows
groups
iam_credentials
instrumentation_integrations
language_configuration_save
language_configuration
mobile_settings
notification_applications
notification_subscribed_devices
notification_topic_subscriptions
org_image_blobs
organization_email_domains
organization_user_attributes
page_docs
page_favorites
page_onboarding_state
page_save_playground_query_saves
page_user_heartbeats
pages
partially_registered_users
personal_access_tokens
plan_features
plans
playground_queries
playground_query_saves
query_metadata
recently_visited_apps
resource_folders
resource_preview_hints
retool_databases
retool_db_migrations
retool_db_provision
retool_files
retool_managed_note_comment
retool_managed_note
retool_rules
retool_table_events
retool_tables
role_pages_members
role_pages
secrets_manager_configs
SequelizeMeta
sessions
source_control_deployment_settings
source_control_deployments
source_control_protection_status
source_control_provider_configs
source_control_relationships
source_control_repo_migration_logs
source_control_repo_migrations
source_control_settings
source_control_user_info
source_control_uuid_mappings
ssh_keys
startup_programs
storage_blobs
tags
temporal_cloud_settings
temporal_cloud_tls_configs
themes
tracked_property_usages
translations
user_groups
user_invite_groups
user_invite_suggestions
user_invites
user_login_ip_addresses
user_session_states
user_viewed_features
vectors
vscode_sessions
vscode_types
workflow_aggregate_usage
workflow_block_result_location_enum
workflow_block_results
workflow_block_runs
workflow_compression_scheme_enum
workflow_custom_url_path
workflow_release
workflow_run_logs
workflow_run
workflow_save
workflow_tracked_property_usages
workflow_trigger
workflow
workspaces

Network requirements

Retool Self-hosted organizations must ensure that their deployments allow access to Retool's IP addresses or domains. If you make use of outbound firewall rules, include the following IP addresses or domains in its allowlist. These allow your deployment to connect to Retool's license check, user authentication, and usage reporting services.

CIDR IP addresses

35.92.202.168/29
44.211.178.248/29

Individual IP addresses

35.92.202.168
35.92.202.169
35.92.202.170
35.92.202.171
35.92.202.172
35.92.202.173
35.92.202.174
35.92.202.175
44.211.178.248
44.211.178.249
44.211.178.250
44.211.178.251
44.211.178.252
44.211.178.253
44.211.178.254
44.211.178.255

Domains

licensing.tryretool.com
invites.tryretool.com
email-service.retool.com
p.tryretool.com
specs.tryretool.com

HTTP proxy connections

Retool supports connections to the internet through a HTTP proxy. Add HTTP_PROXY=http://example.com:8080 to your deployment's docker.env file with the required URL and port number.

License checks

Retool uses HTTP to connect to licensing.tryretool.com on port 443 to verify your license. License checks are made at least once a day.

Inviting users

Retool connects to invites.tryretool.com and email-service.retool.com on port 443 when inviting users. Retool verifies the users are authorized under your current billing plan, and then sends an invite to their email address.

Usage reporting

Retool sends application usage information to p.tryretool.com on port 443, which is used to inform product decisions.

Usage categories

The categories of usage information sent to Retool includes, but is not limited to, the following:

• Page views, along with the page URL.
• Query saves, including the query name and type.
• Component creation and the component type.
• Query preview, including the query name and type.
• Adding a resource, including the resource name and type.

Events are also sent with the hostname, public IP address, browser user-agent string, and the user's email address.

Retool AI

Self-hosted customers can deploy and embed Retool AI within apps and workflows. When a user performs any action with Retool AI, the input is shared with the applicable third-party LLM provider, listed in our Subprocessors page. Inputs are deleted within 30 days.

You can configure a direct connection to a supported AI platform by providing an API key. You also have the option to use a Retool-managed OpenAI connection. If enabled, AI requests are proxied through Retool The Retool-managed OpenAI connection is disabled by default. Contact your Retool account representative or our support team to gain access.

For production use cases, we recommend you provide an API key and directly connect to an AI platform.

When Retool AI is used to build or configure a query, application, or workflow (e.g., prompting Ask AI to help write queries), any inputs or outputs that correspond to the categories above may continue to be used to inform product improvements. Retool does not use any inputs submitted to, or outputs generated from, Retool AI that is embedded within a deployed application or workflow (e.g., text stored in Retool Vectors). These inputs and outputs are treated as "Customer Data" in according with the Customer Terms of Service, Security Practices, and Data Processing Addendum.