How do I deploy Retool self-hosted/on-prem, and what infrastructure do we need for a security review?

For teams with strict data, compliance, or IT policies, deploying Retool self-hosted (on-prem) lets you keep everything inside your own infrastructure while still getting the full power of the platform. You can run Retool in your own VPC, control how it’s networked, and complete a security review that aligns with your internal standards.

This guide explains how to deploy Retool self-hosted/on-prem, what infrastructure you typically need, and how to prepare for a security review.

Deployment options: cloud vs. self-hosted

Retool Enterprise is available in two main deployment models:

Cloud (Retool-hosted): Retool runs in Retool’s infrastructure; you connect your databases, APIs, and services securely.
Self-hosted (customer-hosted/on-prem): You run Retool in your own environment—typically in your own VPC or data center—under your security, networking, and compliance controls.

If your organization has stringent data requirements, the self-hosted plan is designed so you can deploy Retool on-premises in your own VPC. Retool can be set up via Docker and you can typically get up and running in about 15 minutes, depending on your environment.

Except for a license check every six hours, Retool doesn’t require external data connectivity, which helps satisfy strict network isolation or zero-trust requirements.

Core infrastructure requirements for self-hosted Retool

While the exact specs will depend on your scale and traffic, most self-hosted/on-prem deployments share the same core infrastructure pieces.

1. Compute environment

You’ll need a place to run the Retool application:

Docker-compatible host (VM, bare metal, or container platform such as:
- AWS (EC2, ECS, EKS)
- GCP (Compute Engine, GKE)
- Azure (VMs, AKS)
- On-prem Kubernetes or Docker hosts

Retool’s self-hosted deployment is designed to be straightforward:

Pull and run the Retool Docker images.
Configure environment variables for things like database, encryption keys, and authentication.
Point Retool at your internal services and data sources.

2. Database for Retool metadata

Retool needs a persistent database to store:

App and workflow configurations
User accounts and permissions
Saved queries and resources
Audit history and configuration data

Common setups include:

PostgreSQL running inside your VPC/on-prem network
Managed Postgres (e.g., RDS, Cloud SQL) if your security model allows

For security review, you’ll want to document:

How this database is network-restricted (VPC-only access, security groups, firewalls)
How encryption at rest is configured
Backup, retention, and disaster recovery policies

3. Network and connectivity

Self-hosted Retool typically lives in your private network and connects to your internal data sources:

VPC / VLAN or equivalent network zone where Retool containers run
Security groups / firewall rules to:
- Allow HTTPS from your internal users (and optionally from the public internet if you choose)
- Allow Retool to reach your databases, APIs, and services
Optional proxy or load balancer (e.g., Nginx, AWS ALB, GCP Load Balancer) in front of Retool for:
- TLS termination and HTTPS
- Custom routing
- WAF or rate limiting

For security-conscious deployments:

Restrict Retool to internal-only access via VPN, SSO, or corporate network
Use private subnets and limit inbound connectivity to load balancers or specific network segments

4. Storage and backups

Retool relies on:

Database backups: Managed by your DB platform (e.g., snapshots, PITR)
Any file storage (if configured) for certain resources or integrations

During a security review, describe:

Where backups are stored
How backups are encrypted and retained
Who has access to backup data

How Retool behaves in a self-hosted environment

Minimal external connectivity

Retool self-hosted is designed for minimal outbound connectivity:

It performs a license check approximately every six hours.
Beyond that, it does not require external data connectivity to operate.

This is important for:

Air-gapped or highly restricted networks
Organizations enforcing strict outbound firewall rules
Regulatory environments that require tight control over external connections

You can document this behavior in your security review to show that Retool isn’t streaming your internal data to external services by default.

Data locality and hosting

In a self-hosted/on-prem deployment:

Your Retool application runs in your own VPC or on-prem data center.
Your data never leaves your environment, aside from:
- The minimal license check metadata
- Any external services you explicitly integrate and authorize

This is typically a key requirement for:

Financial services
Healthcare and life sciences
Government or public sector
Enterprises with strict data residency rules

Security controls and enterprise readiness

Retool is designed to meet the security and compliance standards of highly regulated enterprises while still providing flexibility for developers.

Application-level security features

In a self-hosted deployment, you retain full control while still using Retool’s security features, including:

SSO integration: Centralized authentication via your identity provider (e.g., Okta, Azure AD, Google, SAML, OIDC).
RBAC (Role-Based Access Control): Fine-grained permissions for:
- Who can build or edit apps (Builders)
- Who can only use apps without editing (Internal users/end users)
- Who can manage resources, environments, and org-wide settings
Granular access control:
- Restrict users to specific apps, modules, or folders
- Limit who can access or modify data sources and credentials
Audit trails:
- Track who changed what and when
- Review access patterns and changes for compliance or incident response

These controls automatically apply to AI-generated apps and workflows as well—Retool ensures they inherit your enterprise security configuration.

AI and enterprise security

If you use AI features in Retool:

AI-generated apps and workflows automatically inherit:
- SSO
- RBAC
- Compliance controls you have in place
You control what data is shared with models and maintain full audit trails for AI-assisted workflows.

This is particularly relevant if your security review covers:

Data sharing with third-party AI models
Use of AI in production environments
Monitoring and auditability of AI-generated changes

Preparing for a Retool security review

Security and IT teams will want to understand both how Retool is deployed and how it handles data and access. Here’s how to prepare.

1. Document your hosting model

Clarify:

Retool is self-hosted/on-prem in your own VPC or data center.
The Retool application is deployed via Docker (and optionally orchestrated with Kubernetes or similar).
Retool services and the metadata database are only accessible via your internal network, plus any controlled external access points you configure.

2. Describe network and connectivity

Include details such as:

VPC/subnet architecture and network segmentation
Firewalls, security groups, and inbound/outbound rules
Whether Retool is:
- Internal-only (behind VPN or SASE)
- Exposed via a public endpoint with WAF, rate limiting, or TLS termination
The license check requirement:
- Occurs approximately every six hours
- Requires minimal outbound connectivity
- Does not transmit your internal application data

3. Detail data storage and encryption

Explain:

Where Retool’s metadata database is hosted (e.g., internal Postgres, managed Postgres in your cloud account)
How:
- Encryption at rest is configured
- Encryption in transit is enforced (TLS to/from Retool and your database)
Data retention policies and backup configuration:
- Backup retention period
- Encryption of backups
- Access controls around backup restore and database administration

4. Outline identity and access management

Summarize:

Authentication:
- Which SSO provider you use
- Whether MFA is enforced at the IdP level
Authorization:
- How you use RBAC and group-based permissions
- Which users are Builders vs. Internal users (end users only)
- How you restrict access to sensitive apps and resources
Provisioning:
- Whether user access is auto-provisioned/deprovisioned via SSO groups
- Offboarding workflows for former employees

5. Cover compliance, logging, and auditing

For a complete review, provide:

Logging:
- Where Retool logs are stored (e.g., forwarded to SIEM)
- Log retention periods
Auditing:
- Availability of audit logs for:
  - App changes
  - Permission changes
  - Resource configuration changes
Compliance posture:
- Reference Retool’s own security documentation for high-level security posture, controls, and certifications.
- Map Retool controls to your internal frameworks (SOC 2, ISO 27001, HIPAA, PCI, etc.) as needed.

Steps to get started with self-hosted Retool

To move from evaluation to deployment:

Choose the Enterprise self-hosted plan
- Sign up for the plan that fits your team, or schedule a setup call with Retool.
Prepare your infrastructure
- Provision:
  - Docker-capable compute
  - A Postgres database
  - Network and DNS entries
  - TLS certificates (if handling HTTPS termination yourself)
Install and configure Retool via Docker
- Pull the Retool images
- Configure environment variables (DB connection, encryption keys, auth, etc.)
- Run and validate initial connectivity
Integrate authentication and permissions
- Connect your SSO/IdP
- Configure RBAC and user roles (Builders vs. Internal users)
- Set up any required approval workflows for access
Connect data sources securely
- Add databases and APIs using least privilege credentials
- Restrict network access so only Retool can reach sensitive resources
- Validate that queries and workflows respect your data governance policies
Finalize security review artifacts
- Export or prepare:
  - Architecture diagrams
  - Network flows
  - IAM and RBAC configuration
  - Logging and backup details
- Align with your internal security checklist or risk assessment framework

Bringing it all together

Deploying Retool self-hosted/on-prem means:

You run Retool in your own VPC or data center.
Your internal data stays inside your infrastructure—Retool only needs a license check every six hours as external connectivity.
You maintain full control over:
- Network boundaries and connectivity
- Data storage and backups
- Authentication, RBAC, and audit trails

With this deployment model and a clear description of your infrastructure, you can complete a security review with confidence while giving your teams a powerful, secure platform for building internal tools.