AI App Builder Audits · AI Development Series
ToolJet App Audit
ToolJet gives you the internal tooling without the per-user bill. The engineering questions are the same ones as any tool with a key to production.
What ToolJet actually hands you
ToolJet is an open-source internal tool platform that has become popular with engineering teams, partly on capability and partly because its pricing does not charge for every end user. It is designed to be self-hosted.
What a ToolJet application is made of
- Interface Components assembled visually
- Data sources Your Postgres, MySQL, MongoDB, REST, GraphQL and more
- Queries SQL and API calls defined per application
- Logic JavaScript and Python in queries and event handlers
- Access Groups and role-based permissions
- Hosting Self-hosted via Docker or Kubernetes, or ToolJet cloud
Structurally this is the same proposition as Retool or UI Bakery: a well-made interface layer holding a privileged connection to a database you already own. Because the schema is yours and was designed deliberately, the data-modelling problems that dominate app-generator audits generally do not apply.
What matters instead is who the database thinks is asking, whether permissions block queries or only hide controls, and — because most ToolJet installations are self-hosted — how the instance itself is exposed and maintained.
What we consistently find
These recur across internal tools built on production databases.
One connection, every user
The platform holds a single set of database credentials, usually broad. Every query anyone runs arrives under that identity, so the database cannot restrict by person, team or region.
Your database audit log shows one account doing everything, which is a poor position if you ever need to reconstruct who did what.
What it costs you: no per-user enforcement or attribution at the database level.Query-level access not matching group permissions
Groups control what applications and components a user gets. The question worth testing is whether a user in a restricted group can still trigger a query belonging to a component they cannot see.
Where the answer is yes, your permission model is describing the interface rather than governing the data.
What it costs you: users reaching queries their group was meant to exclude.Self-hosted and quietly out of date
Self-hosting is the main reason teams choose ToolJet, and updating it is nobody's explicit job. Instances drift months or years behind, and often end up reachable from the public internet so people can use them remotely.
An unpatched internal tool with production credentials, exposed to the internet, is among the more attractive things you could run.
What it costs you: a privileged, internet-facing, unpatched entry point to production.Where ToolJet is genuinely good
ToolJet is a capable, economical answer to internal tooling, and being open source and self-hostable means neither your data nor your costs are subject to somebody else's decisions. For engineering teams who want control, it is a sound choice.
Genuinely well suited to
- Internal tools where data must stay inside your network
- Engineering teams comfortable running their own services
- Admin panels, dashboards and operational tooling
- Organisations avoiding per-user platform pricing
- Replacing spreadsheets and direct database access
Where it needs engineering behind it
- Anything customer-facing or reachable from outside the organisation
- Tools performing bulk or irreversible actions on live data
- Regulated processes needing a defensible audit trail
- Instances nobody is actively patching
- Logic complex enough to deserve review and tests
The honest summary: ToolJet is a good tool and self-hosting is a legitimate choice, provided somebody owns the consequences. The tooling risks are the standard ones; the deployment risk is the one that only applies because you chose to run it yourself.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- It can write to, or delete from, your production database
- The instance is reachable from outside your network
- You are not certain when it was last updated
- It touches personal data, payroll, pricing or payments
- The person who set it up has left, or is about to
You are probably fine if
- It is read-only over data nobody would mind seeing
- It runs internally with a couple of trusted users
- It is a dashboard rather than a tool that changes things
- Everything it touches is easy to reconstruct
Questions about auditing a ToolJet build
The pattern is a single data source connection shared by everybody, with group permissions applied on top of the interface. That makes the groups a description of what people should see rather than a rule about what they can actually reach.
It is open source, self-hostable and a legitimate alternative to the commercial internal-tool builders. The risk profile is the same as its peers: it sits directly on your production data, so whatever it can do, its users can do.
Not on their own. Groups govern what appears in the app. If query-level access does not match the group, a user who can reach a query can run it regardless of which group they are in. The two need checking against each other.
Where one connection serves every user, yes. The connection holds the rights and the app decides how much of that to expose. Anything that bypasses the app, or any query left broader than the group it belongs to, is not covered.
It keeps your data under your control and removes a vendor from the chain. What it adds is responsibility for updates. Self-hosted instances drift out of date quietly, because nothing prompts you and the tool carries on working.
It can, once connections are scoped, query permissions match group permissions and the instance is current. What usually fails is the gap between those three, because each was configured separately and nobody has checked that they agree.
Aligning query and group permissions and scoping connections is configuration, so it is quick relative to the risk it removes. The audit is £495 + VAT and covers the app and the deployment together. Credited back in full if we do the work.
Only indirectly, and it is worth naming: cheaper per user tends to mean more users, and more users means a wider blast radius when permissions are not properly enforced. The saving is real and sensible. It just makes getting the permission model right more important rather than less.
Read access to the applications so we can see queries, JavaScript and group configuration, the database schema and the credentials the platform connects with, plus how the instance is deployed and who can reach it. We will not change anything.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not ToolJet expertise, it is that the thing being audited is SQL, a permission model, a production database and a deployment.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Lovable app audit
- Emergent app audit
- Replit app audit
- UI Bakery app audit
- Bolt app audit
- v0 app audit
- Base44 app audit
- Firebase Studio app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Softr app audit
- Adalo app audit
- Retool app audit
- Appsmith app audit
- Budibase app audit
- Xano app audit
- Airtable app audit
The audit
Find out what you are sitting on
The AI Code Audit is £495, fixed.
Tell us roughly what you built and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
- The query layer, including how user input reaches your database
- Whether group permissions block queries or only hide components
- What the tool can do to production data, and what is recorded
- How your self-hosted instance is deployed, exposed and patched
We reply within one working day.
