ToolJet, Appsmith, Budibase, Lowdefy: open-source Retool alternatives by repo data

My open-source alternatives directory's Retool page lists four repositories. The numbers here are from the 2026-10-13 refresh. Stars, forks, language and license come from saas.json. Release data and open items come from evidence.json, generated at 07:51 UTC that day.

The table

"Open items" is GitHub's open issue count, which also counts open pull requests.

All four were pushed on Oct 13, the day of the refresh, and none is archived. So the "last push" column tells you nothing here, which is the problem I wrote up separately in what I learned about pushed_at.

The top two are tied

ToolJet leads Appsmith by 30 stars out of about 41,000. That's a tie. The page template has a rule for it: if the second-place repo is within 5% of the leader, the page names both and tells readers to treat them as equals on stars and decide on license and fit. A code comment from 2026-09-05 recorded this exact pair at 40,846 vs 40,814. The gap was 32 then and 30 now. So neither project is pulling ahead on attention, and stars won't settle this choice.

What does differ:

• License. ToolJet is AGPL-3.0. Appsmith is Apache-2.0. If you plan to modify the tool and offer it to people over a network, AGPL obliges you to release your changes. Apache-2.0 doesn't. For a purely internal deployment this matters less, but legal teams tend to ask.
• Backlog. Appsmith carries 4,515 open items to ToolJet's 858. With this many users I don't read either number as a quality grade. It does mean a bug you hit in Appsmith may join a long queue.
• Release habit. ToolJet cut 66 releases in 12 months and its latest tag ends in -lts. Appsmith cut 20. As I found in release counts measure tagging habits, that tells you how a project tags, not how much it ships.

One oddity: GitHub reports ToolJet's primary language as HTML. That's GitHub's automatic language detection reading the file mix. ToolJet isn't an HTML project in any useful sense, so don't filter on that column.

Budibase's license needs a closer read

The GitHub API returns NOASSERTION for Budibase. That means GitHub's license detector couldn't match the file to a single SPDX id. I read the LICENSE file by hand on 2026-09-05. The repo calls itself GPLv3 "overall". The paid features in packages/pro are under the Business Source License, and packages that ship inside generated apps are MPL-2.0.

So "Budibase is open source" is true for the core, with a source-available paid layer on top. That's a common setup, and it's why my directory shows a split-license note instead of a single badge. I've run into other license values the GitHub API can't display verbatim.

Budibase also has the most releases in the set, 76, with its latest on Oct 12. Its repo description now leads with "AI agents, automations and apps that run your operations". The page's editorial note puts it as covering similar ground to the top two "with more of a business-process-automation slant".

Lowdefy is the small, config-first option

Lowdefy is much smaller: 3,010 stars and 17 open items. Its description is "Build apps that AI can generate, humans can review, and teams can maintain. Config that works between code and natural language." If your team would rather review YAML-style config than drag components around, it's the one to try. Its backlog is also small enough to read through in an afternoon before you commit.

Before you migrate off Retool

The page's own comparison note is blunt about gaps. Retool's catalog of native integrations is broader than any of these, its AI query and component generation has no open-source match, and on enterprise depth (audit logs, fine-grained permissions) Appsmith and ToolJet still trail it. Condensed migration tips from the same page:

1. Export each Retool app as JSON, but document every query separately first. The query library doesn't export cleanly.
2. Check your specific connectors against Appsmith's and ToolJet's integration lists.
3. Recreate resource connections (database credentials, API keys) in the new tool.
4. Run both tools in parallel and audit each internal tool before moving users over.

I tried to add a "What real users say" section from Hacker News and Reddit comments, as I do for these comparisons. Both sources refused connections from my collection environment today, so this post has no reader-voice data rather than a padded version of it.

Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.