The main Appsmith alternatives for developer teams split three ways: open-source low-code builders, code-first or config-first stacks, and backend or governed platforms. If self-hosting is why you picked an open-source builder, check which edition holds single sign-on, audit logs and permissions before you migrate, because the open core and the enterprise edition aren't always the same product.
Most internal tools start life as a developer's side job: an admin panel over the orders table, a refunds screen for support, a dashboard somebody asked for late on a Friday. Then the side job becomes the thing half the company opens every morning, and the platform it was built on starts to matter far more than anyone planned.
If you're weighing up a move, you're usually after one of three things: a builder that's easier to run on your own servers, a stack your developers can keep in Git like the rest of the codebase, or tighter control over who can see and change what. The nine options below are listed in no particular order and grouped by how they expect you to build, because that's what decides whether a migration takes a week or a quarter.
Three ways to build self-hosted internal tools
Open-source low-code builders. This is the nearest like-for-like swap: drag components onto a canvas, bind them to a query, ship. ToolJet is the most direct match, with a visual builder plus AI and coding agents, and a long list of places you can run it, from its own cloud to Kubernetes inside your network. Budibase leans towards processes: apps, automations and agents that wrap around systems you already have. NocoBase pitches itself as a foundation for whole business systems, with permissions and workflows in the open-source core rather than bolted on later.
Code-first and config-first stacks. These need developer skills, and that's the point. Windmill starts from scripts and turns them into workflows, apps and data pipelines, with collaboration through Git. Refine is a React framework for admin dashboards, CRMs and B2B apps, so what you build is ordinary code your team owns. Lowdefy sits in between: you describe the app in YAML config instead of dragging boxes around, which suits teams who like reviewing changes as text.
Backends and governed platforms. Directus isn't an internal tool builder in the usual sense. It's a backend and headless CMS that puts an admin app and REST and GraphQL APIs over any database, which is often all an internal tool turns out to be. Superblocks is led by governance: business teams build, IT controls auth, integrations, access and auditing from one place. Retool is the big established brand of the category, and it now mentions self-hosting on its own site.
The nine builders side by side
| Tool | Kind of tool | Good for |
|---|---|---|
| Budibase | Open source process and app platform | Apps and automations around systems you already run |
| Directus | Database-first backend and admin app | A backend and admin app over an existing database |
| Lowdefy | Config-first open-source web stack | Apps described in YAML config, not drag and drop |
| NocoBase | Open-source business system platform | Business systems with permissions and workflows built in |
| Refine | React framework for admin apps | Admin dashboards and CRMs your developers write in code |
| Retool | Established internal tool platform | Internal apps wired to databases, APIs and LLMs |
| Superblocks | Governed enterprise app platform | IT-controlled app building across a large company |
| ToolJet | Open-source internal tool builder | Self-hosting on Docker, Kubernetes, a VPC or on-premise |
| Windmill | Code-first workflows and internal apps | Scripts, workflows and data pipelines kept in Git |
Each builder in one line
Alphabetical, in no particular order.
Budibase
Best for: Teams that want apps, automations and agents built around existing systems, with a self-hosting route on its page next to the hosted one.
Directus
Best for: Developers who want a self-hostable backend and headless CMS over any database, with a no-code admin app and REST and GraphQL APIs on top.
Lowdefy
Best for: Developers comfortable in YAML who'd rather define full-stack web apps in config files that connect to any data source.
NocoBase
Best for: Building and evolving business systems on an open-source core that ships with permissions and workflows already in place, according to its page.
Refine
Best for: React developers building admin dashboards, CRMs and other B2B apps in code, with a section on its page about publishing on your own infrastructure.
Retool
Best for: Teams that want the big, established name in internal tools, connecting to any database, API or LLM, with an AI app builder and a self-hosting mention.
Superblocks
Best for: Larger companies where business teams generate apps on company data while IT keeps auth, access controls and auditing in one central place (vendor wording).
ToolJet
Best for: A visual builder, AI or coding agents for internal tools, run on its own cloud or self-hosted on Docker, Kubernetes, your VPC or on-premise.
Windmill
Best for: Engineers who write scripts first and want workflows, apps and data pipelines on one open-source platform with Git-based collaboration (vendor claim).
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
What self-hosting hands back to your team
Here's the part that tends to surprise teams halfway through a migration. Self-hosting is the reason most developers pick a tool from this list, and it's a good reason: your data stays on your servers, and you're not waiting on someone else's roadmap. But the moment you run it yourself, a set of jobs moves onto your desk. Upgrades are yours to schedule and test. Backups are yours to run and, more to the point, to restore. Auth setup is yours, and so is uptime when the support team can't load the refunds screen.
The second surprise is editions. An open-source core doesn't mean every feature is open source. Single sign-on, audit logs and granular role permissions often sit in commercial or enterprise editions, even when the builder itself is free to self-host. Those are exactly the features a security review asks about once an internal tool touches customer data, so they're the worst ones to discover late.
Before you move a single app, check these on every shortlisted builder:
- Which edition includes single sign-on with the identity provider you already use.
- Whether audit logs and fine-grained permissions are in the open-source core or a commercial edition.
- How upgrades are released, and whether your current install can jump straight to the newest version.
- Who on your team owns backups, restores and the on-call rota for the tool once it's live.
Plain advice for developers picking a self-hosted builder
Start with how your team likes to work, not with the feature grid. If your developers are happy on a canvas and want to ship screens fast, stay in the open-source low-code group. If they'd rather everything lived in Git and went through code review, the code-first and config-first stacks will feel far more natural, and you won't spend months fighting a visual editor. If most of what you need is a clean admin layer over a database, look at the backend option first, because you may not need an app builder at all.
Then rebuild one real app, not a demo, on your top two choices, and run each on your own infrastructure for a fortnight. Count the hours spent on upgrades and auth, not only on building. If self-hosting turns out not to matter after all, my wider list of hosted internal tool alternatives covers more options. And if the real request is charts over a database, open-source BI tools may do the job with far less building.
Do you make an internal tool builder? Tool makers can ask to be considered for a featured place on this list.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
What's the difference between open-source and self-hosted?
Open source describes the licence of the code. Self-hosted describes where it runs. A tool can be open source and still offered as a hosted cloud, and some closed tools can be installed on your own servers. Check both separately.
Do code-first internal tool platforms need developers?
Yes. Script-first platforms, React frameworks and config-first stacks all expect someone who can write and review code or YAML. That's the trade: more control and version history in exchange for less drag and drop.
Which features tend to sit in enterprise editions?
Single sign-on, audit logs and granular role permissions are the usual ones. Each vendor draws the line differently, so read the edition comparison on its own site before you plan the migration.
Can I export my apps from one builder into another?
Rarely in a usable form. Each builder stores apps in its own format, so expect to rebuild screens and logic. Your data and queries move more easily, because they live in your database, not in the builder.
Should we self-host or use the vendor's cloud?
Self-host if data has to stay on your servers or inside your network and you've got someone to run upgrades and backups. Otherwise the vendor's cloud takes those chores off your plate.
Is a headless CMS a real alternative to an internal tool builder?
Sometimes. If your internal tool is mainly forms and tables over a database, a backend with a ready-made admin app can cover it. If you need custom screens and workflows, a builder is still the better fit.
