Split Architectures for Internal Tools

Self hosting is a pricing and product consequence of where internal tool builders sit in the stack, they are not just reading analytics, they are sitting next to the systems that can refund orders, change account status, update records, and trigger scripts against production data. Once a tool has that level of access, large companies often want the app builder inside their own VPC, behind their own VPN, or at least want execution to happen in their own cloud.

• Retool’s core use case is putting an admin panel on top of production databases and APIs, for support teams, ops teams, and other employees who need to search records, edit fields, and kick off actions. That is exactly the kind of workflow that raises security review, because the tool is directly connected to live systems, not a copied dataset.
  2 sacra 3 sacra
• Retool turned self hosted deployment into a formal product. Its current self hosted offering lets companies run Retool on their own infrastructure, and its pricing page says organizations with stringent data requirements can deploy it on premises in their own VPC, with only periodic external license checks.
  4 retool 5 retool
• The main alternatives frame the trade off differently. Airplane keeps the control plane in its cloud but lets customers run an agent in their own environment for execution. Appsmith pushed earlier around open source and self hosting, arguing that teams do not want to expose databases to a third party just to build internal apps.
  1 sacra 6 retool

Going forward, internal tool platforms will keep moving toward split architectures, where cloud software handles collaboration and product updates, while customer owned infrastructure handles the risky part, which is touching production data and running write operations. That makes security posture part of product design, not just an enterprise add on.