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

Retool gives you two main deployment options on Enterprise plans: a cloud version hosted by Retool, and a self-hosted / on-premises version that you run in your own infrastructure (typically a VPC). If your organization has strict security, compliance, or data residency requirements, self-hosting Retool lets you keep data within your own environment while still benefiting from a modern internal tools platform.

This guide explains how to deploy Retool self-hosted/on‑prem, what infrastructure you need, and what information security teams typically review during a security assessment.

Overview of Retool self-hosted / on-prem

With the self-hosted plan:

You run Retool in your own VPC or data center.
Deployment is usually done via Docker (e.g., Docker Compose or an orchestration platform like Kubernetes).
You can get up and running in about 15 minutes for a basic deployment.
Retool does not require external connectivity to operate, other than a license check that runs every six hours.
Your application data, queries, and resources stay in your environment, helping you meet stringent security and compliance requirements.

Self-hosting gives your team full control over networking, access control, logging, and integration with your existing systems.

Deployment options for self-hosted Retool

Retool recommends containerized deployment. In practice, most customers choose one of the following patterns:

1. Docker / Docker Compose

Best for:

Single-node or small deployments
Rapid POCs and pilots
Simple environments

Key points:

Run Retool as one or more Docker containers.
Use Docker Compose files provided by Retool to define services (web app, database, etc.).
Attach persistent storage volumes for data and configuration.

2. Kubernetes (EKS, GKE, AKS, or on-prem clusters)

Best for:

Enterprise-scale deployments
High availability and autoscaling
Strong integration with existing DevOps practices

Key points:

Deploy Retool via Helm charts or Kubernetes manifests.
Use your standard ingress controllers, secrets management, and monitoring.
Align with your organization’s existing CI/CD pipelines and release practices.

3. Other orchestration platforms

If you use a different orchestrator (Nomad, Swarm, OpenShift, etc.), you can still deploy Retool as long as it supports running Docker containers and configuring persistent storage and networking.

Core infrastructure requirements

While exact sizing will vary by workload, a typical self-hosted Retool deployment requires the following building blocks.

1. Compute resources

VM or nodes: One or more Linux-based servers or Kubernetes nodes.
CPU and memory: Start with a modest configuration suitable for your initial user base (e.g., a few vCPUs and sufficient RAM) and scale based on load and number of builders and internal users.
OS: A modern, supported Linux distribution for running Docker and your orchestration tools.

Since Retool is container-based, you primarily need reliable compute resources that can run Docker containers with stable performance.

2. Storage

You’ll need persistent storage for:

Retool application configuration and metadata
Internal databases (if you choose to host them in the same environment)
Logs and audit trails (if stored locally rather than forwarded)

Requirements:

Persistent block or network storage (e.g., EBS, PersistentVolumes, NFS, or equivalent).
Regular backups and retention policies that align with your internal policies.

3. Networking

For a secure, self-hosted/on‑prem deployment:

VPC or private network: Run Retool in an isolated network segment (VPC, subnet, or on-prem VLAN).
Ingress: Control inbound access via a load balancer, reverse proxy, or ingress controller.
Egress: Allow outbound connectivity for:
- The periodic license check (every six hours).
- Any external APIs or databases Retool apps need to reach (if applicable).

Many organizations restrict Retool’s outbound traffic to a small allowlist of required endpoints and internal systems.

4. Database and resources

Retool connects to your existing data sources and services, such as:

Internal databases (Postgres, MySQL, SQL Server, etc.)
APIs and microservices
Third-party SaaS tools (optional, depending on your use case)

You can:

Host databases inside the same VPC/subnet as Retool, or
Connect to databases that live elsewhere in your infrastructure, provided networking rules allow it.

Because Retool runs within your environment, data flows directly between Retool and your resources without needing to leave your VPC, except for the license check.

Security and compliance considerations

Retool is designed to meet the needs of highly regulated enterprises, offering robust security, reliability, and access controls. When self-hosted:

Data residency: All data processed by your Retool apps stays in your environment.
Network isolation: You control all inbound and outbound traffic at the network and firewall level.
Access control: Integrate with SSO and identity providers, and use Retool’s role-based access controls (RBAC) to restrict who can build or use apps.
Auditability: Retool maintains audit trails so you can track who accessed and changed what.

You also control:

Logging destinations (SIEM, log storage, etc.)
Backup and recovery processes
Patch and upgrade cadence

What your security team typically reviews

To perform a security review of a self-hosted/on‑prem Retool deployment, infosec teams usually focus on a few key areas: architecture, data flows, access control, network boundaries, and compliance posture.

Below is a checklist that can help you prepare.

1. Architecture and hosting model

Security teams will want to know:

That Retool is deployed in your own VPC or data center.
Which environment types you’re running (e.g., dev, staging, prod) and how they’re segmented.
Whether you’re using Docker, Kubernetes, or another platform and how it’s managed.
How Retool components (app server, database, etc.) are laid out across nodes.

Providing an architecture diagram that shows Retool sitting inside your network, along with its connections to internal databases and services, helps speed up the review.

2. Data storage and residency

Key questions to answer:

Where is Retool’s application data stored (e.g., internal Postgres in your VPC)?
Are backups stored in-region and within your control?
Do any Retool-related logs or exports leave your environment?
What are your data retention, backup, and deletion policies?

With self-hosted Retool, you can state clearly that application data stays inside your infrastructure, which is often critical for compliance.

3. Connectivity and external dependencies

Security reviewers will check:

Which external endpoints Retool must reach:
- The license verification endpoint (every six hours).
- Any optional integrations with third-party APIs or services.
Whether outbound traffic is constrained via firewall rules or proxies.
That Retool does not require broad outbound Internet access to function.

Documenting the specific URL(s) or IPs required for the license check and any other external services is important.

4. Authentication and authorization

Retool supports enterprise-grade authentication and access controls:

SSO / Identity integration:
- Use your existing SSO (SAML, OAuth, OIDC, etc.).
- Centralize user provisioning and deprovisioning.
Role-based access control (RBAC):
- Define builders (users who can edit apps and workflows).
- Define internal users (end users who cannot edit apps).
- Restrict access to apps, data sources, and environments.

Your security team will want to see:

How you handle user access lifecycle (joiners/movers/leavers).
How roles and permissions map to internal policies.
Whether you enforce MFA through your identity provider.

5. Application security controls

Security reviewers often ask about:

How secrets (API keys, database credentials) are stored and encrypted.
How query access is restricted (e.g., allowing read-only vs. read-write).
Whether you can enforce safe patterns (e.g., using parameterized queries, limiting who can edit production apps).

Retool lets you centralize resources and queries so that app builders reuse approved, secure building blocks instead of connecting to databases ad hoc.

6. Logging, monitoring, and audit trails

For compliance and investigations, your team will review:

What activity logs Retool produces (logins, edits, access to specific apps/resources).
Where logs are stored and for how long.
How logs integrate with your SIEM or monitoring stack.
Whether audit trails are immutable and complete enough for your needs.

Retool’s audit logs help you demonstrate control and oversight over internal tool usage.

7. AI and data protection (if you use Retool AI features)

If you adopt AI features within Retool, enterprise protections still apply:

AI-generated apps and workflows inherit your existing security: SSO, RBAC, and compliance.
You control what data is shared with models and from which sources.
All AI-related activity stays auditable within your Retool environment.

Your security team may want to understand:

Which models are used (internal vs. external).
What data is allowed to flow to AI providers, if any.
How you configure guardrails and access controls for AI features.

Steps to prepare for a security review

To make the security review smoother, you can prepare the following:

Architecture diagram
Show:
- Retool deployment (containers, nodes, clusters).
- VPC or network boundaries.
- Connections to databases, APIs, and external services.
- Ingress/egress paths and load balancers or proxies.
Infrastructure summary
Provide:
- Hosting platform (cloud provider or data center, Kubernetes vs. VMs).
- Network segmentation details (subnets, security groups).
- Storage and backup strategy.
Security configuration overview
Document:
- SSO integration and MFA enforcement.
- RBAC model (roles, permissions, environments).
- Secrets management approach.
Data and logging policies
Clarify:
- Where Retool stores data and logs.
- Retention and backup policies.
- Any exports to external tools (e.g., SIEM, monitoring).
External dependencies
List:
- License check endpoints.
- Any third-party services or APIs used by Retool apps.
- Network rules or allowlists in place.
Compliance documentation
Reference:
- Retool’s official security documentation (for controls and certifications).
- Any internal security standards you map Retool to.

Getting started with a self-hosted Retool deployment

To move from planning to implementation:

Select your plan
Sign up for a plan that includes self-hosted deployment (typically Enterprise) or schedule a setup call with Retool to discuss your requirements.
Choose your deployment model
Decide whether you’ll start with Docker Compose for a quick pilot or go directly to a production-grade deployment on Kubernetes or another orchestrator.
Provision infrastructure
Set up:
- Compute, storage, and networking in your preferred environment.
- Network rules to support Retool + license checks.
- Access to your internal databases and services.
Install and configure Retool
- Follow Retool’s self-hosted installation instructions.
- Integrate SSO and configure RBAC.
- Connect your data sources and define environments (dev/stage/prod as needed).
Run an internal security review
Share:
- Your deployment architecture and security configuration.
- Retool’s security documentation and any relevant whitepapers. Address questions from your infosec, compliance, and IT teams.
Onboard builders and internal users
- Invite team members to your Retool organization.
- Assign roles (builder vs. internal user).
- Start building and rolling out apps within your controlled environment.

Summary

Deploying Retool self-hosted/on‑prem starts with choosing the self-hosted Enterprise plan and running Retool in your own VPC or data center using Docker or an orchestrator like Kubernetes. The platform requires only minimal outbound connectivity for a periodic license check and otherwise runs entirely within your infrastructure.

For a successful security review, be prepared to show:

Your hosting model and network design.
How and where data is stored and backed up.
SSO, RBAC, and audit logging configurations.
External dependencies and any AI-related data flows.

This combination of self-hosted deployment controls, enterprise-grade security features, and clear documentation allows Retool to align with the requirements of highly regulated organizations while giving developers the flexibility they need to build internal tools quickly.