“Retool self-hosted” is a phrase that means four different things, and the pricing page tells you the per-user number but not the real bill. The four paths are: full Retool on-prem (the most expensive, the most flexible), an open-source Retool-equivalent like Appsmith or ToolJet (the cheapest, the least feature-rich), a lightweight framework like Windmill (the most flexible, the most code-heavy), and a platform-provided internal-tools service (the easiest, the least customizable). The right path depends on the team’s size, the data sensitivity, and how much of the Retool feature set the team actually needs.
The reason “Retool self-hosted” is a popular question is that the pricing page is a per-user number ($50/user/month for Retool’s standard self-hosted plan, with volume discounts), and the per-user number for a 50-person team is $30,000/year. For a team that is building a lot of internal tools, the per-user number is the entire IT budget, and the question is whether the team can get the same outcome for less. The honest answer is “yes, with trade-offs,” and the rest of this post is the trade-offs.
Table of contents
- The four paths, in one table
- Path 1: full Retool on-prem (or self-hosted)
- Path 2: an open-source Retool-equivalent
- Path 3: a lightweight framework like Windmill
- Path 4: a platform-provided internal-tools service
- The five questions that decide which path is right
- The real costs the pricing pages skip
- How to migrate off Retool without a rewrite
- The honest verdict on each path
- FAQ
The four paths, in one table
| Path | Approx. annual cost for a 20-person team | Operational footprint | Feature parity with Retool | Best for |
|---|---|---|---|---|
| Full Retool on-prem / self-hosted | $15,000 - $40,000 (license) + infra ($5,000 - $20,000) + maintenance (~$30,000 engineer) | High (you run the cluster) | 100% (same product) | Teams that need the full Retool feature set and have the engineering bandwidth to operate it |
| Open-source Retool-equivalent (Appsmith, ToolJet, Budibase) | $0 - $3,600 (license) + infra ($2,000 - $10,000) + maintenance (~$20,000 engineer) | Medium (you run the cluster) | 60-80% (most features, some gaps) | Teams that want to self-host and do not need every Retool feature |
| Lightweight framework (Windmill, NocoDB) | $0 - $2,400 (license) + infra ($2,000 - $8,000) + maintenance (~$15,000 engineer) | Low to medium (depends on the framework) | 40-70% (different abstraction, more code) | Engineering-heavy teams that prefer code over drag-and-drop |
| Platform-provided internal-tools service (RunxBuild, Nifty, internal) | $1,200 - $6,000 (platform fee) + maintenance (~$5,000 engineer) | Low (the platform runs the cluster) | 30-60% (depends on the use case) | Small teams that want internal tools without the operational overhead |
The cost numbers are the engineering-time-adjusted cost, not just the license. The license fee for full Retool on-prem is $15,000-$40,000 per year for a 20-person team, but the engineering time to operate the cluster is the bigger number. A team that has never operated a Kubernetes cluster should not start with Path 1.
The “feature parity” column is the percentage of Retool features the alternative has. Appsmith covers 70-80% of the common use cases. ToolJet covers 60-70% with more AI features. Budibase covers 50-60% with a built-in database. Windmill covers 40-50% with much more flexibility for engineers. The feature parity number is the part that decides whether the alternative will work for the team’s specific use cases.
Path 1: full Retool on-prem (or self-hosted)
Retool’s on-prem offering is the same product as the cloud offering, deployed on the team’s infrastructure. The license is per-user, with volume discounts for large teams. The infrastructure is the team’s choice (AWS, GCP, Azure, on-prem hardware), and the maintenance is the team’s responsibility.
The real cost of full Retool on-prem is the infrastructure plus the engineering time, not the license. The license is $50/user/month for the standard self-hosted plan, $100/user/month for the enterprise plan with SSO and audit logs, and $200+/user/month for the enterprise plan with custom SLAs. The infrastructure is a Kubernetes cluster with 4-8 vCPUs and 16-32 GB RAM, which is $500-$1,500/month on AWS or GCP, depending on the region and the reserved-instance discount.
The engineering time is the bigger number. A team that operates a Retool on-prem installation needs to:
- Provision and maintain the Kubernetes cluster (or the VM-based installation)
- Configure the database, the cache, and the storage
- Set up the SSO integration (SAML or OIDC)
- Set up the monitoring and alerting
- Apply Retool’s monthly security patches
- Back up the database and the configuration
- Handle the upgrade path (Retool ships major versions quarterly)
The total engineering time is about 0.25 FTE, or roughly $30,000-$40,000/year at a US salary. The license plus the infrastructure plus the engineering time is the real bill, and the real bill is $50,000-$80,000/year for a 20-person team.
The benefit of Path 1 is the full Retool feature set. The team gets every Retool component, every Retool integration, every Retool feature, and the team owns the data. The Retool team does not see the team’s queries, the team’s data, or the team’s usage patterns. For a team that needs the full feature set AND has the engineering bandwidth, Path 1 is the right answer.
The downside of Path 1 is the operational overhead. A team that has never operated a Kubernetes cluster should not start with Path 1. A team that has the Kubernetes experience but does not have the time should not start with Path 1. A team that is small (under 20 people) and does not have a dedicated platform engineer should not start with Path 1. The path is right for the team that has the operational expertise, the engineering time, and the budget.
Path 2: an open-source Retool-equivalent
The open-source Retool-equivalents are Appsmith, ToolJet, and Budibase. All three are self-hostable, all three have a free community edition, and all three are designed to be the open-source answer to Retool.
Appsmith is the most popular of the three. The feature set covers about 70-80% of the common Retool use cases: drag-and-drop UI builder, database connectors, API connectors, JavaScript for custom logic, role-based access control, audit logs, and SSO. The community edition is free for unlimited users on self-hosted deployments, which is the part that makes the cost the most attractive. The paid editions (cloud-hosted, enterprise features) start at $15/user/month.
ToolJet is the second most popular. The feature set is similar to Appsmith, with the addition of AI features (LLM integration, AI app builder) and a stronger focus on workflows. The community edition is free for self-hosted deployments, with a 2-builder limit on the free tier. The paid editions start at $19/builder/month, with the team plan at $199/builder/month.
Budibase is the third. The feature set is similar to the other two, with a built-in database (CouchDB) and a focus on the small-to-medium internal tools use case. The community edition is free for self-hosted deployments with up to 20 users. The paid editions start at $50/creator/month plus $5/user/month.
The real cost of an open-source Retool-equivalent is the infrastructure plus the engineering time, similar to Path 1. The license is free (or a few hundred to a few thousand per year for the paid editions), the infrastructure is $200-$800/month, and the engineering time is about 0.15 FTE, or roughly $20,000-$25,000/year.
The benefit of Path 2 is the cost. The license is free (or nearly free), and the team owns the data. The open-source license means the team can audit the code, contribute back, and avoid the vendor lock-in. For a team that is comfortable with a slightly smaller feature set, Path 2 is the right answer.
The downside of Path 2 is the feature gap. Appsmith does not have every Retool component. ToolJet does not have every Retool integration. Budibase does not have every Retool workflow. The team that picks Path 2 should expect to write some custom code to fill the gaps, and the team that picks Path 2 should be ready to contribute back to the open-source project or fork the project if the gap is critical.
Path 3: a lightweight framework like Windmill
Windmill is not a Retool-equivalent in the strict sense. Windmill is a framework for building internal tools with code, and the framework has a visual editor, a script editor, a workflow editor, and an app editor. The visual editor is similar to Retool, but the script editor is the part that makes Windmill different — the team can write the business logic in TypeScript, Python, Go, or Bash, and the framework runs the script in a sandboxed environment.
The benefit of Path 3 is the flexibility. The team can write the business logic in whatever language the team prefers, and the framework handles the deployment, the scheduling, the retry, the error handling, and the observability. The team that is comfortable writing code will find Windmill more flexible than Retool, because Windmill does not constrain the team to the framework’s component library.
The cost of Path 3 is the engineering time. Windmill requires the team to write more code than Retool, and the team that is not comfortable writing code will find Windmill harder to learn than Retool. The open-source edition is free for self-hosted deployments, the cloud edition starts at $20/developer/month, and the enterprise edition is custom.
The operational footprint is similar to Path 2 — a single host, a database, a cache, and the Windmill process. The team that has the operational expertise can run Windmill on a small VM. The team that does not have the operational expertise should use the managed Windmill Cloud.
Path 3 is the right answer for the team that prefers code over drag-and-drop, the team that has a strong engineering culture, and the team that wants the flexibility to extend the framework with custom code. Path 3 is the wrong answer for the team that wants to give the drag-and-drop experience to non-engineers, because Windmill’s drag-and-drop is less mature than Retool’s.
Path 4: a platform-provided internal-tools service
A platform-provided internal-tools service is a managed service that runs the Retool-equivalent for the team. The service handles the infrastructure, the maintenance, the upgrades, and the security patches. The team uses the service to build the internal tools, and the service is billed per user or per usage.
The honest answer for 2026 is that the “platform-provided internal tools” category is still emerging. The options are:
A Retool Cloud account. The cloud-hosted version of Retool, billed per user, with the same features as the on-prem version. The cost is the same as the on-prem license plus the cloud premium.
A managed Appsmith or ToolJet. Several vendors offer managed versions of the open-source Retool-equivalents. The cost is lower than the Retool Cloud, but the feature set is the open-source feature set, not the Retool feature set.
An internal-tools service from a platform. Some platforms (notably Nifty, Airtable Interfaces, and the internal-tools features of some cloud platforms) offer an internal-tools service as part of a larger platform. The cost is bundled with the platform subscription, and the feature set is limited to the use cases the platform targets.
A custom build on a managed application platform. A team that has a managed application platform like RunxBuild can build a custom internal-tools service on the platform. The cost is the platform subscription plus the engineering time to build the service, and the feature set is whatever the team builds. The benefit is the team owns the data, the team controls the features, and the team can extend the service with custom code.
Path 4 is the right answer for the team that does not have the operational expertise to run Path 1, 2, or 3, the team that wants a fixed monthly bill, and the team that is comfortable with a smaller feature set in exchange for operational simplicity. Path 4 is the wrong answer for the team that needs the full Retool feature set, because none of the platform-provided services match the full Retool feature set.
The five questions that decide which path is right
The decision is not “which is the cheapest” or “which is the most popular.” The decision is “which matches the team’s constraints.” The five questions that match the team to the path:
Question 1: Does the team need the full Retool feature set, or can the team live with a smaller feature set? If the team needs the full feature set, Path 1 is the only option. If the team can live with 70-80% of the features, Path 2 is a real option. If the team can live with 40-50%, Path 3 is a real option. If the team can live with 30-60%, Path 4 is a real option.
Question 2: Does the team have the operational expertise to run a Kubernetes cluster? If yes, Path 1 and Path 2 are real options. If no, Path 3 and Path 4 are the only options.
Question 3: Does the team have the engineering time to maintain the internal-tools service? A team that has 0.25 FTE to spare is in a different position from a team that has 0.05 FTE to spare. The engineering time is the biggest cost for Paths 1, 2, and 3.
Question 4: Is the data sensitive enough to require on-prem or self-hosted? For a team that handles PII, financial data, or healthcare data, the data sovereignty requirement is often the reason for self-hosting. Path 1, 2, and 3 are the on-prem options. Path 4 is the cloud option, and the data sovereignty requirement rules it out.
Question 5: Is the team building internal tools for a small number of users, or for the whole company? A team of 5 people building tools for 50 users has different needs from a team of 50 people building tools for 5,000. The cost per user is the variable that decides the answer.
The five questions are the ones that the pricing page does not ask. The pricing page asks “how many users,” and the answer is a per-user number. The right questions are the five above, and the answers are the four paths.
The real costs the pricing pages skip
The pricing page tells you the license. The real bill has four line items, and three of them are invisible on the pricing page.
Line 1: the license. Visible on the pricing page. Retool Self-Hosted Standard is $50/user/month. Retool Self-Hosted Enterprise is $100+/user/month. The open-source Retool-equivalents are free (community edition) or $15-$50/user/month (paid editions). Windmill is free (community edition) or $20/developer/month (cloud).
Line 2: the infrastructure. Invisible on the pricing page. A Kubernetes cluster for Retool on-prem is 4-8 vCPUs and 16-32 GB RAM, which is $500-$1,500/month on AWS. A single VM for Appsmith or ToolJet is 2-4 vCPUs and 8-16 GB RAM, which is $200-$500/month. Windmill is similar to Appsmith. A platform-provided service is included in the platform subscription.
Line 3: the engineering time. Invisible on the pricing page. A team that operates a Retool on-prem installation needs 0.25 FTE for the cluster, the database, the SSO, the monitoring, the patches, the backups, and the upgrades. A team that operates an open-source Retool-equivalent needs 0.15 FTE for the same work. A team that uses a platform-provided service needs 0.05 FTE for the customization and the integration.
Line 4: the opportunity cost. Invisible on every page. A team that spends 6 months learning how to operate a Kubernetes cluster for Retool on-prem is not spending those 6 months building the product. A team that spends 3 months configuring Appsmith is not spending those 3 months on the customer-facing work. The opportunity cost is the biggest cost for the small team, and it is the cost that the pricing pages never mention.
The total cost of ownership for a 20-person team over 3 years:
| Path | License | Infrastructure | Engineering time | Total |
|---|---|---|---|---|
| Retool on-prem | $36,000 | $36,000 | $270,000 | $342,000 |
| Appsmith self-hosted | $0 | $14,400 | $180,000 | $194,400 |
| Windmill self-hosted | $0 | $14,400 | $135,000 | $149,400 |
| Platform-provided | $14,400 | $0 | $45,000 | $59,400 |
The numbers are illustrative. The point is the engineering time is the biggest cost, and the engineering time is the cost that the pricing pages skip. A team that picks Path 1 because the license is “only” $50/user/month is the team that does not realize the engineering time is 75% of the total cost.
How to migrate off Retool without a rewrite
A team that is on Retool today and wants to migrate to a different path has two options: the rewrite and the bridge.
The rewrite. The team rebuilds every Retool app on the new platform. The rewrite is the most thorough option, but the cost is the engineering time to rebuild every app, and the risk is the new app does not match the old app’s behavior. A team with 10 Retool apps is looking at 2-6 months of rewrite work.
The bridge. The team uses the new platform’s API to talk to the old Retool instance. The new platform imports the data from Retool’s database, exposes the data as a REST API, and the new platform’s apps consume the REST API. The bridge is faster than the rewrite, and the risk is lower because the old Retool apps keep working.
For most teams, the bridge is the right answer. The team can migrate the data to the new platform, run the new platform alongside Retool, and migrate the apps one at a time as the team gets comfortable. The migration is a quarter-by-quarter project, not a big-bang rewrite.
For a managed application platform, the bridge is a managed Postgres database, a REST API on top of the database, and a custom app that consumes the API. The build is one or two weeks, and the migration is one or two quarters.
The honest verdict on each path
A short, opinionated summary of when each path is the right answer.
Path 1 (full Retool on-prem) is right when the team needs the full Retool feature set, the team has the operational expertise, the team has the engineering time, and the data sensitivity requires on-prem. The path is wrong for small teams, teams without Kubernetes experience, and teams that are sensitive to the engineering time cost.
Path 2 (open-source Retool-equivalent) is right when the team can live with 70-80% of the Retool feature set, the team has some operational expertise, and the team is comfortable contributing back to the open-source project. The path is wrong for teams that need the full Retool feature set and teams that do not have the engineering time.
Path 3 (lightweight framework like Windmill) is right when the team prefers code over drag-and-drop, the team has strong engineering culture, and the team wants the flexibility to extend the framework. The path is wrong for teams that want to give the drag-and-drop experience to non-engineers.
Path 4 (platform-provided) is right when the team does not have the operational expertise, the team wants a fixed monthly bill, and the team is comfortable with a smaller feature set. The path is wrong for teams that need the full Retool feature set and teams that have data sovereignty requirements.
The right path for a specific team is the path that matches the team’s constraints. The pricing page is the wrong place to start the decision. The five questions above are the right place to start the decision.
FAQ
How much does Retool self-hosted actually cost?
The license is $50/user/month for the standard plan, $100+/user/month for the enterprise plan. The infrastructure is $500-$1,500/month for a Kubernetes cluster. The engineering time is 0.25 FTE, or roughly $30,000-$40,000/year at a US salary. The total cost of ownership for a 20-person team over 3 years is approximately $340,000, with the engineering time being 75% of the total.
Is Retool self-hosted worth it?
It depends. For a team that needs the full Retool feature set, has the operational expertise, has the engineering time, and has the data sensitivity requirement, Retool self-hosted is worth it. For a team that can live with 70-80% of the feature set and has some operational expertise, an open-source Retool-equivalent like Appsmith is a better value. For a small team that does not have the operational expertise, a platform-provided service is the right answer.
Can I self-host Retool for free?
No. Retool is proprietary software, and the self-hosted license is the same as the cloud license. The only way to get the Retool experience for free is to use the open-source Retool-equivalents (Appsmith, ToolJet, Budibase) or to use a different approach entirely (Windmill, custom build on a managed platform).
What is the best open-source alternative to Retool?
Appsmith is the most popular open-source Retool alternative, with the largest community and the most mature feature set. ToolJet is the second most popular, with a stronger focus on AI features. Budibase is the third, with a built-in database. The right choice depends on the specific use case, but Appsmith is the safe default for most teams.
Can I use Windmill as a Retool replacement?
Yes, but with caveats. Windmill is a framework, not a drag-and-drop tool. A team that is comfortable writing code will find Windmill more flexible than Retool. A team that is not comfortable writing code will find Windmill harder to use than Retool. The right answer depends on the team’s engineering culture.
How do I migrate off Retool?
Two options: the rewrite and the bridge. The rewrite is the most thorough option, but the cost is high and the risk is high. The bridge is faster and lower-risk, and the migration is a quarter-by-quarter project. For most teams, the bridge is the right answer.
What is the cheapest way to self-host a Retool-equivalent?
Appsmith community edition is free for unlimited users on self-hosted deployments. The infrastructure is a single VM with 2-4 vCPUs and 8-16 GB RAM, which is $200-$500/month on a cloud provider. The engineering time is 0.15 FTE, or roughly $20,000-$25,000/year. The total cost of ownership for a 20-person team over 3 years is approximately $195,000, which is roughly half the cost of full Retool on-prem.
Can I use a managed platform like RunxBuild to build a custom internal-tools service?
Yes. A managed application platform is the right foundation for a custom internal-tools service, especially for a team that has unique requirements. The platform handles the infrastructure, the deploys, the database, the env vars, and the observability. The team writes the application code, the platform runs it. The feature set is whatever the team builds, which is the trade-off for the operational simplicity.