Open-source alternatives to Retool: 3 internal tool builder tools compared
Moving internal tools off a hosted builder means the database credentials, the app definitions and the upgrades all land on your infrastructure, and the three projects here make very different assumptions about who will hold that. appsmithorg/appsmith is the one most readers should look at first, because it is Apache-2.0 and Docker is the path the project itself recommends.
What Retool does, and why people look elsewhere
Retool is a hosted low-code builder for internal tools: drag-and-drop UI components wired to databases and APIs with JavaScript.
- per-user pricing that includes the people who only use the tools
- apps and query logic live on Retool's servers unless you pay for the self-hosted edition
- proprietary app format
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| appsmithorg/appsmith | Apache-2.0Permissive: commercial use allowed | Commits in the last six monthsLast push November 6, 2026 | TypeScript | 41,186 | See analysis |
| ToolJet/ToolJet | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last six monthsLast push November 6, 2026 | JavaScript | 41,202 | Command documented |
| Budibase/budibase | Custom licenceCustom licence: read the LICENSE file | Commits in the last dayLast push November 7, 2026 | TypeScript | 28,394 | See analysis |
Each alternative in detail
appsmithorg/appsmithPlatform to build admin panels, internal tools, and dashboards. Integrates with 25+ databases and any API.
- Best for
- You need admin panels, internal dashboards and service management tools over data you cannot move to a vendor cloud, and you are willing to run Docker or Kubernetes. The repository describes integrations with more than 25 databases and any API, and Docker is marked as the recommended installation method.
- What you give up
- Our analysis of Appsmith is direct that this is the wrong tool if you need pixel-level control over the front end, because a low-code builder produces a component layout rather than a designed interface. It also needs someone to own upgrades and backups, and there is a telemetry decision to make: read the telemetry page before you set APPSMITH_DISABLE_TELEMETRY rather than assuming what that flag does.
ToolJet/ToolJetToolJet is the open-source foundation of ToolJet AI - the enterprise app generation platform for building internal tools, dashboard, business applications, workflows and AI agents 🚀
- Best for
- You want a self-hostable builder with 60+ responsive components, a built-in no-code database, 80+ data sources, JavaScript and Python running inside apps, and AES-256-GCM encryption with proxy-only data flow. The community edition covers all of that.
- What you give up
- Our analysis of ToolJet says the feature you may actually want is not in the community edition: AI app generation, AI query building, AI debugging, the agent builder, GitSync and CI/CD are all placed in ToolJet AI, the enterprise edition, along with row-level access control and embedded apps. The data source list is also a gap, because the README names the count of more than 80 without listing them, so you have to check your stack by hand.
- First install step
- Full setup guide
docker run \ --name tooljet \ --restart unless-stopped \ -p 80:80 \ --platform linux/amd64 \ -v tooljet_data:/var/lib/postgresql/13/main \ tooljet/try:ee-lts-latest
Budibase/budibaseAI agents, automations and apps that run your operations. Model agnostic.
- Best for
- Your internal tools are really request handling: approvals, routing, intake forms and the automations behind them. The README describes agents that create records, route approvals, update apps and notify teams, plus a public API that can use Budibase as a backend.
- What you give up
- The licence is split in a way that needs a compliance review. Our analysis of Budibase puts the core under GPL v3 with paid features under the Business Source License, and notes that packages/pro/license.md is where you confirm which features in your use case fall under the BSL, because the README does not itemise the boundary. It is also aimed at internal operations rather than customer-facing products.
Three shapes of internal tool: panels over data, connectors everywhere, or request routing
Retool is a hosted low-code builder for internal tools: drag-and-drop UI components wired to databases and APIs with JavaScript. People look elsewhere for three reasons. Per-user pricing that counts the people who only use the tools, not the people who build them. Apps and query logic live on Retool's servers unless you pay for the self-hosted edition. And the app format is proprietary, so a tool you built cannot be opened without the product that made it.
The three projects here each attack a different kind of internal tool.
appsmithorg/appsmith is the closest in shape to what Retool does. The README describes custom applications for dashboards, admin panels, customer 360 views, IT automation and service management, and the repository description puts the integrations at more than 25 databases plus any API. The install paths are Docker, which the README marks as recommended, Kubernetes and an AWS AMI. It is TypeScript, and the analysis notes the release branch is where the shipped code lives, which matters if you are pinning a version. The same README also introduces Appsmith Agents, an agentic layer that works inside those tools with private data.
ToolJet/ToolJet is the widest connector story. The community edition lists 60+ responsive components, a built-in no-code database, multi-page apps with multiplayer editing, 80+ data sources across databases, APIs, cloud storage and SaaS tools, JavaScript and Python inside apps, and a plugin and connector model through the ToolJet CLI. It is also the only one of the three that puts deployment targets on a cloud provider's marketplace, with entries on AWS and Azure.
Budibase/budibase starts from the request rather than the screen. The README describes agents that take action across a business, creating records, routing approvals, updating apps and notifying teams, alongside app building and workflow automations, and it publishes a public API described as a way to use Budibase as a backend. It also has a user and group portal model, where a group manager administers their own users.
Left out, and worth saying why: the spreadsheet-plus-scripting tools that people reach for when the internal tool is really a report, and the general low-code platforms aimed at customer-facing products rather than staff tools. Both exist; neither is what someone is leaving a hosted internal-tool builder for.
Choosing by scenario: a solo operator, a small team, a company with residency needs, a team embedding a tool in a product
What the tool is for decides which of the three fits, and the differences show up earlier than the licence conversation does.
A solo operator who needs one admin panel over one database should look at appsmithorg/appsmith. Docker is the recommended path, the connector list is broad, and nobody has to be trained on a platform. The cost our analysis names is front-end control: if the tool has to look like a designed product rather than a working panel, a component builder is the wrong instrument.
A small team with several internal tools across several systems should look at ToolJet/ToolJet. The data source count is the reason, and so is Code Anywhere, which puts JavaScript and Python inside an app rather than only in a query. The same small team should read the feature split first, because our analysis of ToolJet places AI app generation, GitSync and CI/CD in the enterprise edition, and those are exactly the features a growing team tends to want next.
A company with data residency requirements finds all three acceptable on the data question and different on the licence question. appsmithorg/appsmith is Apache-2.0, which is the simplest review of the three. ToolJet's community edition is AGPL-3.0, which is comfortable for internal use and needs a decision if you modify it. Budibase splits its core GPL v3 from a Business Source License tier.
A team embedding an internal tool inside a product it sells is the case none of these three is built for. Budibase's public API is the closest of them to an integration surface, and our analysis of Budibase is explicit that organisations building customer-facing products add a compliance review to the list of things to check. This is the scenario where staying with a hosted builder is often the honest answer.
What each one asks you to run
The install commands on this page are inconsistent in an informative way: two are deployment commands and one is a development command.
ToolJet/ToolJet has the most complete command on the page. It runs a container, restarts unless stopped, publishes port 80, pins the platform to linux/amd64, and mounts a named volume at the PostgreSQL data path. So the quick start is a real database in a container, and that volume is your instance. Two things are worth noticing. The README recommends the LTS tag over the latest one for anyone upgrading, for stability and security patches. And the tag in the command is an ee-lts one, so the edition a given image contains is worth checking against the edition you intend to run, given that our analysis places the AI features in the enterprise edition.
appsmithorg/appsmith has no install command in our analysis, and the README sends you to a table of installation guides rather than pasting one. What the analysis tells you to do is verify the Docker path against the current installation guide, and check which database connectors your data actually needs before you commit, because the connector you discover is missing after building the app is an expensive way to find out.
Budibase/budibase shows yarn setup, which is a development command from a monorepo rather than a deployment. The README is more useful here: it lists Docker with a single ARM compatible image, Docker Compose, Kubernetes, Digital Ocean and Portainer as the supported self-hosting routes, and a public API with general and interactive documentation.
The pattern across all three is the same. A low-code builder is not a stateless web app, because it holds database credentials, app definitions and workflow state. Whatever you pick, the thing to back up is the database volume, and the thing to plan for is the upgrade of the platform underneath it.
Licences: one Apache-2.0, one AGPL-3.0, and a GPL core with a source-available tier
This is the part of an internal-tool decision that most often needs a second conversation, and the three here are genuinely different.
appsmithorg/appsmith is Apache-2.0. A company can read it, run it, modify it and host the modified version for internal use, and there is no copyleft obligation to reason about. For a tool whose database credentials and query logic are the sensitive part, that is the straightforward answer.
ToolJet/ToolJet's community edition is AGPL-3.0, and the AGPL clause that matters is the network one. If you run a modified ToolJet and staff reach it over a network, the source obligation applies to those users. Internal use without modification is the ordinary case and is unremarkable, but a team that forks a builder to add one connector has changed its own review process, and that is worth doing before the fork rather than after.
Budibase/budibase is the one to read carefully. Our analysis of Budibase puts the core code under GPL v3 and the paid features under the Business Source License, and points at packages/pro/license.md as the place to confirm which features in a given use case fall under the BSL, since the README does not itemise the boundary. A Business Source License is source-available with a time limit rather than open source, so the honest description of Budibase is GPL v3 with a source-available tier on top, and a legal team should be told that rather than discovering it.
One point applies to all three. A permissive licence on the builder does nothing about where your production database credentials live, and that is the question a reviewer should ask first.
Bottom line
Pick appsmithorg/appsmith for admin panels and internal dashboards over data you cannot move, ToolJet/ToolJet when the breadth of data sources and running JavaScript or Python inside an app matters, and Budibase/budibase when the tool is really an approval and intake workflow with agents behind it. Before committing, check that your database connector is actually supported, decide whether you are running an LTS or a beta tag, and read the licence file that covers the features you plan to use, especially the BSL boundary in Budibase.
Sources
Was this useful?