Skip to main content
This page is unlisted and can only be accessed directly via URL. It is excluded from the site navigation and search results.

“Bring Your Own Cloud” Deployment

Retool is offering a new “Bring Your Own Cloud” (BYOC) deployment option that enables our customers to provision Retool deployments in their own VPC(s) and delegate the management of those deployments to Retool’s infrastructure team. This offering is being made to select customers as part of a closed Beta Services program.

While self-hosting Retool grants explicit control of the Retool runtime version, data sovereignty/residency, and single-tenant isolation on private infrastructure, deployments can be challenging and expensive with setup and ongoing maintenance activities. They require understanding Retool’s advanced architecture for building and executing arbitrary user-generated workloads, provisioning and rightsizing network, compute, and storage components accordingly, and continuously upgrading both Retool versions and its underlying infrastructure. Ultimately, delays in setup and lack of upkeep result in organizations unable to realize the full value of their subscription.

This BYOC deployment option aims to retain all the security, reliability, and performance benefits of self-hosted deployments, while removing the associated toil. At a high level, we achieve this by using a limited-access, customer-provided service accounts and Retool-managed automation to provision, monitor, and maintain infrastructure for running Retool deployments in a customer’s VPC.

This program may be a fit for organizations that want to

  • Dedicate builder time to development and deployment of novel applications and workflows over infrastructure management
  • Minimize requests to internal DevOps teams to set up, monitor, and manage Retool deployments
  • Take advantage of new, powerful features that require changes to underlying infrastructure
  • Delegate availability, security, and infra-level performance concerns to a dedicated team that is expert in running large-scale Retool deployments

This program is not a fit for organizations that require control over the infrastructure or run in environments fully disconnected from the public internet.

The remainder of this document outlines the technical details of the Beta Services program and includes a FAQ to inform on the requirements, limitations, and benefits of this option now and in the future.

Overview​

With a BYOC deployment, the Retool team handles the provisioning and management of the infrastructure necessary to support single-tenant deployments of self-hosted Retool in a customer’s private cloud on AWS.

At a high level, the BYOC deployment option does:

  • include a relatively hands-free deployment of Retool
  • enable the Retool team to manage the deployment in its entirety, including but not limited to: version upgrades, configuration changes, right-sizing, underlying infrastructure changes/upgrades, and monitoring to enable incident response.
  • include guidance for enabling the deployment to connect to other resources in the customer’s private cloud

This option does NOT allow the Retool team to:

  • access extraneous parts of the customer’s AWS accounts
  • make out-of-band, undisclosed changes to the deployment
  • peer VPCs or make private resource networking changes
  • SSH into servers running Retool or to view query responses
  • access customer secrets used to configure Retool or customer data stored in Retool
  • elevate its own AWS or K8s access

Customer Requirements​

In addition to agreeing to the security and ownership concerns outlined below, there are only two requirements from the customer for the BYOC Beta Services program.

  • A dedicated AWS account - Customers need to set up a separate, dedicated AWS account, where Retool will be deployed. Using a separate AWS account enhances security, simplifies billing management, enables better resource management, and facilitates easier auditing.
  • Predefined, assumable IAM Roles - Customers need to grant the Retool team permissions through AWS IAM. This cross account role will be assumed for infrastructure setup. After setup completion, we'll create a lesser-privileged cross account role for long term cluster maintenance. Access to assume these roles will be strictly kept within limited staff on Retool’s infra on-call rotation, granted through Okta with MFA enabled. Retool will provide automation to provision this role and policy. Please reach out to our team for the policy details.

BYOC Architecture​

Components​

A standard BYOC Retool deployment will consist of the following components, diagrammed above:

  • EKS: This is the Kubernetes cluster where all Retool services will be hosted. The key services deployed on this cluster are:
    • Retool Deployments (backend, jobs-runner, workflow-backend, workflow-worker, code-executor): A set of workloads required for a Retool instance, deployed through this Helm chart.
    • NGINX: manages the Ingress of the cluster and upon request, can be configured by the Retool team to implement IP-based firewall rules.
    • cert-manager: issues and manages certificates using Let's Encrypt.
  • RDS: manages external storage for Retool, which requires a PostgreSQL database per instance to store its apps, resources, users, permissions, and internal data.
  • Elasticache: for temporary storage of query response data to improve Retool application and query performance.
  • S3: stores the Terraform state for all AWS components provisioned.
  • Secrets Manager: stores secrets managed and readable by the Retool team in a specified privileged namespace. All customer-managed secrets will be in an isolated namespace handled by an External Secrets Operator (discussed in detail below).

Network​

This diagram shows network-level isolation and the flow of traffic involved in a standard BYOC Retool deployment.

VPC Setup​

  • VPC: The Retool team will create a new VPC for the deployment. By default, the CIDR range will be 10.254.0.0/16. This is customizable (e.g. for VPC peering).
  • Subnets: The VPC will include a set of public subnets and a set of private subnets.
    • The EKS cluster and the database will be deployed in the private subnets so that their workloads are not publicly accessible.
    • The EKS cluster API itself will use the AWS default of public access and be secured through IAM/K8s admission webhooks (Kyverno policies).
    • The deployments on the EKS cluster will have egress access via the NAT gateway.
  • Availability Zones: Each set of subnets (public and private) will be created in two Availability Zones for high availability.
  • Security Groups: The standard security groups will be created to allow EKS cluster internal communication between master/worker nodes, EKS to communicate with RDS, and all inbound traffic into EKS from anywhere in the VPC.

DNS​

By default, the Retool team will create a *.retool-hosted.com DNS record to use with the customer’s deployment.

If customers do not wish to use a *.retool-hosted.com domain, they can bring their own, with a DNS A-record pointed to the IP address of the cluster (available after the Retool team’s initial setup of the cluster).

Resource connection​

There are a few options to connect to external resources so that they can be queried via the Retool deployment:

  • If the resource is publicly routable, a direct connection can be made. The egress traffic from the Retool instance will have static outbound IPs (the public IPs of the NAT gateways), so they can be allowed in IP-based firewalls.
  • If the resources are in a private network, there are two recommended paths:
    • Connect via SSH tunneling
    • Set up VPC Peering between the VPC dedicated for Retool instance and the VPC that the resources are in.

Inbound Data Flow​

The Retool instance is open to the internet at the specified domain, gated behind the configured authentication mechanism.

If requested, the Retool team can implement an IP-based NGINX firewall to restrict instance access to a subset of IP CIDR ranges (such as the ip of an internal VPN), serving all other IP’s an NGINX 403.

Outbound Data Flow​

Traffic outbound from the Retool instance needs to leave the VPC in the following cases:

  • Retool License checks: Every 6 hours, Retool connects to licensing.tryretool.com to verify your license.
  • Retool usage reporting: Retool sends application usage information to p.tryretool.com which is used to calculate billing.
  • Retool Source control: If in use, Retool’s Source Control feature needs to connect to the configured source control management provider to maintain state. Some providers can also be deployed in the VPC if necessary.
  • Retool Workflows: If in use, Retool’s Workflows feature needs to connect to Retool-managed Temporal to schedule and poll for asynchronous tasks. All coordination and orchestration happens in an isolated namespace within the Retool-managed Temporal cluster. No code results or query data is sent outside of your VPC by default.
  • Metrics and logs: Metrics and logs, aimed at measuring the health of the Retool deployment, are periodically sent to telemetry.retool.com. This is done via telemetry agents deployed in the cluster.

Data Storage​

The Retool team will not have connection or read access (enforced through customer-managed IAM policies) to any of the following data stores:

Retool Platform DB​

Required for running Retool, storing all application metadata including users, apps, workflows, resource configurations, and more. We provision an RDS instance with encryption at rest and we connect to the instance utilizing TLS. Sensitive fields within the database, such as resource credentials and intermediate Workflow results, are encrypted with a customer-managed encryption key (not accessible by Retool).

Elasticache Caches for Performance (optional)​

Supports caching Retool internal API results and customer-generated query results for improved performance. We provision Elasticache instances to encrypt data at-rest and encrypt data in-transit through TLS.

Retool DB (optional)​

Supports Retool DB feature, where customer data can be stored within a standalone RDS instance. We provision an RDS database with encryption at rest and make connections with TLS providing encryption in-transit.

Retool Storage (optional)​

Supports Retool Storage feature, where customer data can be stored within a customer-configured S3 resource. Data is encrypted server-side by AWS upon storage on disk.

Retool RPC (optional)​

Supports Retool RPC feature, which uses Elasticache to store a queue of RPC function calls. We provision an Elasticache with data encryption at rest and connect using TLS to enable data encryption in-transit.

Secrets​

For secrets required by the Retool application (e.g. Encryption key, RDS credentials, etc.), Retool will install an External Secrets Operator to manage secrets. This operator is responsible for reading secrets from a customer-managed AWS Secrets Manager namespace and creating corresponding Kubernetes secrets, which will be read as needed by the Retool deployment. This operator will be granted an in-account IAM role to access AWS secrets manager and fetch specific secrets; this role will be separate from any cross account roles, which do not have such access.

The Retool team will not have read access to secrets in AWS Secrets Manager (via IAM) or in the Kubernetes Cluster (via Kyverno policies). The External Secrets Operator does not log or expose fetched secrets. Additionally, no secrets will be passed to the Terraform state used by the Retool team to manage infrastructure.

Operation​

Setup​

In the new AWS account, the customer will first provision a cross account IAM role that will be used to setup and maintain infrastructure according to customer specification. This role's attached policy will have a AWS permission boundary to prevent privilege escalation pathways and block access to secrets, database execution, and logging. Please reach out to our team for the policy details.

Maintenance​

The Retool team will take care of maintenance operations related to the health and availability of the deployment, including but not limited to:

  • Retool version upgrades
    • Unless otherwise specified, these will happen at a quarterly cadence and to the latest stable release, without downtime.
  • Retool infrastructure configuration changes such as:
    • Changing any environment variables and scaffolding secret references
    • Enabling new features by making the necessary infrastructure changes
  • Scaling the deployments to ensure optimal runtime capacity
  • Upgrades/maintenance to underlying infrastructure including
    • Kubernetes version upgrades
    • Nginx version upgrades
    • Database maintenance/upgrades

Availability Monitoring​

As part of a standard deployment, Retool will configure a telemetry collector that uses a secure TLS connection with short-lived client certificates when sending data to Retool. Data is securely stored on Amazon S3 buckets in us-west-2 and not shared with any other third-parties or subprocessors.

Using metrics and logs collected from the cluster, Retool’s observability systems will detect and alert upon failed deployments or unexpected downtime due to infrastructure issues. The Retool team will remediate accordingly upon detection. Customers can also consume these metrics and logs to monitor and alert with existing tooling.

All other questions about Retool can be raised through regular support channels.

Security​

Policies and Practices​

The deployment will be managed largely through infrastructure as code, executed by a select few members of Retool’s infrastructure team. Retool uses Okta as our single-sign-on provider and requires the use of phishing-resistant hardware MFA. Access to these privileged accounts is logged and reviewed regularly via AWS/VPN access logs, and session duration is limited to 12 hours.

Access​

Once authenticated, the Retool team will be able to:

  • Assume a limited IAM role in the dedicated AWS account set up by the customer that has the ability to:
    • Read, create, and manage all the infrastructure pieces necessary to spin-up the Retool deployment (terraform state buckets, VPC, EKS cluster, some additional IAM roles)
    • Connect to the EKS cluster backing Retool workloads for the purposes of triaging issues and right-sizing deployments

While assuming a maintenance role, the Retool team will explicitly NOT have access to:

  • view or affect any resources in different AWS accounts other than the one explicitly granted access to by the customer
  • peer VPCs or make private resource networking changes
  • SSH into the underlying machines backing the Retool deployment
  • view customer-managed secrets stored in Kubernetes Secrets and any connected AWS Secrets Managers outside of the Retool-specified namespace.
  • connect to or read user data in Postgres, Elasticache, S3 and future data stores for Retool features capable of storing customer data
  • view any customer data in transit
  • elevate its own AWS or K8s access

FAQ​

What are the AWS costs associated with this deployment?
The baseline recommended footprint for a Retool BYOC deployment includes an EKS cluster with three m5.xlarge nodes and a single-AZ RDS instance. This configuration supports most use cases at low-to-moderate usage volume. Use cases with atypically high query volume, high workflow usage, or or large user counts may need more resources and carry higher cost.

The above baseline configuration carries AWS costs around $9.5k/year (at list price for us-west-2). The ultimate spend in your AWS account may be lower if you have AWS discounts.

Note: A Retool BYOC deployment has costs for Retool itself as well as costs the customer would incur with AWS directly, since the AWS account involved is owned by the customer. The above cost estimates are about the AWS costs alone. For Retool pricing, please contact your Retool salesperson.

How available is the Retool Deployment?
We are targeting BYOC Beta Services Program deployments to have 99.99% uptime year-round via monitoring and alerting on cpu, memory, and key performance metrics. These deployments can expect zero downtime infrastructure maintenance, instance customizations, and version upgrades and are on a high-urgency escalation path for alerting.

Although the BYOC Beta Services program doesn’t support disaster recovery from the unlikely event of an AWS regional outage, all relevant workloads are deployed in multiple AWS availability zones, providing resiliency against zone outages.

How customizable is the Retool deployment? What about support for multiple instances?
Unless specified otherwise, the BYOC Beta Services program will support all feature customization enjoyed by Retool self-hosted customers, with the infrastructure treated as a black box.

This includes supporting multiple instances of Retool running on different domains, although likely subject to higher infrastructure costs.

What kind of data is collected by the metrics and logs? Does it contain PII?
The types of data collected are the following:

  • container metrics
    • includes cpu, memory, resource limits, network usage
  • Retool runtime metrics
    • includes frontend performance measurements, backend request counts and latency measurements, and internal performance measurements for some code paths
  • container logs
    • includes request logs, error logs, and info logs
    • specifically does not include audit logs or debug level logs

Container metrics and Retool runtime metrics contain no PII. Container logs and billing metrics contain user emails, but do not contain contents of Retool apps or the queries/responses of resource queries initiated by Retool apps.

Is any data stored by Retool deployments viewable by Retool staff?
No. Retool deployments can store customer-generated data, but this data is not accessible to the staff managing deployments. It is ultimately up to the customer to decide what kind of data they would like to store in Retool, and have sufficient protections of that data within their organization using Retool platform controls (group access) and infrastructure controls (AWS).

How do I get started with the program? What are the next steps?
To get started with the program, simply reach back out to our team. We will set up an initial call to review your networking requirements to make a recommendation on how to connect to any resource within your organization. Next, we will forward instructions on how to provision IAM permissions in a new AWS account.

What is the roadmap for the BYOC deployment?
Through this Beta Services program, we will be partnering with customers to design a best-in-class managed deployment experience with clear interfaces to plug into the rest of their infrastructure. If the program has sufficient demand and brings positive customer experiences, we foresee customers managing all their deployments across from a Retool-provided UI as a single pane of glass and we expect to transfer our cross-account permissions to open-source in-cluster management services. In addition, we will extend the program to include Azure and GCP-hosted customers.

What will happen when the Beta Services program ends?
The BYOC Beta Services program is will run at minimum through your contract term. Participating customers will have 6 months notice when we make pricing public for GA.

Appendix​

AWS Cost Calculations for a Standard Deployment​