ToolJet

What is ToolJet?

ToolJet is an open-source low-code platform for building internal tools. It connects to databases, APIs and SaaS sources, and supports self-hosting so sensitive business data stays within your infrastructure.

Best for

Teams that need internal tools quickly without vendor lock-in

Why choose ToolJet

ToolJet occupies a similar space to Appsmith — build internal tools visually, connect them to your data, host it yourself — and it is the stronger choice for some teams because of its connector list and its emphasis on granular permissions. It supports a wide range of databases and APIs, handles the standard grid-form-chart vocabulary of internal tooling, and can be self-hosted on modest infrastructure. For a small operations team that needs dashboards and admin screens fast, it removes weeks of front-end work.

Replaces

• Retool
• Appsmith
• Budibase

Key features

• Visual app builder
• Many data source connectors
• Self-hosted deployment
• Granular permissions

What to watch out for

The category's shared limitation applies: visual builders get you a long way and then start resisting. Complex conditional logic, unusual layouts and heavy custom interaction end up requiring code, and at that point you are maintaining an application inside a platform. Self-hosting means you handle upgrades, backups and the security of a tool with broad database access. The commercial edition holds some enterprise features, so verify that the community build covers the governance you need.

How to deploy

• Docker
• Kubernetes

Getting started

Deploy via the official Docker setup with an external Postgres database rather than a container-local one — every app and connection lives in that database. Create a restricted database user for each connection rather than reusing an admin credential; this tool can read anything you point it at. Build one real screen end to end, including a write-back action, before designing your permission model, since seeing the whole flow makes the access decisions obvious. Document your naming convention for queries and components from the first app; retrofitting structure later is the expensive part.

Typical setup

The usual deployment is Docker Compose on an internal server, next to the databases the organisation already runs, with an external Postgres for the application's own data. Teams build a handful of operational screens — inventory, support, approvals — and give access by group. Because it can reach many data sources, most careful installations maintain a task-specific database user per connection and keep the instance behind the corporate VPN.

Who should look elsewhere

Not for customer-facing products, for the same reasons as any internal tool builder: the trust model assumes internal users. It is also the wrong choice for teams with no engineering capacity at all, because the long tail of requirements will eventually need code, and someone has to own the instance, its upgrades and its database access.

Project health

• GitHub stars: 41,018
• Last code push: 2026-09-30
• Open issues: 1,283
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.