Internal tool builders in 2026: revisit Appsmith, ToolJet and Budibase before you build another admin panel

Every growing company ends up with a second, quieter product: the screens its own staff use. Support needs to look up an order and resend an invoice. Finance needs to approve a refund. Operations needs to correct a wrong weight on a shipment. At first an engineer gives somebody read access to the database, or adds three pages to an old Django admin, or exports a sheet every morning. Later that same database login has write access, the sheet has gone to the wrong person, and nobody can say who changed the payment record last Tuesday.

Low-code internal tool builders promise a way out: connect your database and APIs, drag a table and a form on a canvas, add a few queries, and publish a screen with login and roles. This post compares the three open-source builders that Indian teams most often shortlist for self-hosting in 2026: Appsmith, ToolJet and Budibase. It looks at licences and editions, architecture, query safety, access control and which parts are paid, version control, security history, AI features, upgrades and footprint. It also says plainly when you should not adopt any of them and should write a small app instead.

This topic sits close to several earlier posts. Workflow automation in 2026 is the sister post: that one is about wiring systems together behind the scenes, this one is about the screens people click. Authorization in 2026 matters because an admin panel is mostly a permission problem with a UI on top. Keycloak and its alternatives covers the identity provider that every one of these tools will eventually point at, and Vault and OpenBao covers where database passwords should really live. Schema migrations in 2026 is relevant because a low-code app that writes to your tables is one more client that breaks when a column is renamed. PostgreSQL backups in 2026 and MongoDB alternatives in 2026 matter because these builders bring their own metadata databases that need backups too, and reverse proxies in 2026 is where you will put them on the network.

We end with a light drill: no server was started, but we checked the vendors’ own sample configuration files for placeholder secrets and checked how the open and paid code is licensed. We say clearly what we did not run.

A scenario to keep us honest

Imagine a company in Moradabad that builds software for brassware and handicraft exporters in western Uttar Pradesh: buyer order tracking for European and American importers, job-work issue and receipt for artisan units and polishing workshops, piece-rate payment calculation for karigars, quality inspection records, and export documents for shipments leaving through Delhi and Mundra. The company is invented for this post. It has about 35 engineers, a platform team of two, and an operations team of about 40 people across support, finance and export documentation.

The setup today:

• One production Kubernetes cluster in a cloud region in Mumbai and a small staging cluster.
• About 20 services, mostly Python (Django and FastAPI) with two Go services for document generation.
• PostgreSQL for orders, job work and payments, Redis for caching, and an object store for inspection photos and shipping documents.
• Keycloak already runs for customer login on the buyer portal, but internal staff still log in to different tools with different passwords.
• An old Django admin with about 30 models exposed, a shared read-write database login that two senior support staff use from a desktop SQL client, and a set of Google Sheets that finance downloads every morning.

Four things push the team to revisit internal tools. First, a support executive ran an UPDATE without a WHERE clause on a staging copy, then realised the client was connected to production for a different tab, and about 300 job-work receipts got the wrong status. Nothing was lost, because the team had point-in-time recovery, but it took most of a night. Second, a large European buyer’s supplier audit asked who can change payment and inspection records, whether access is role based, and whether changes are logged. Third, the operations head has a list of 14 screens the team keeps asking for, from “approve karigar payment correction” to “mark shipment documents complete”, and product engineering has no time for them. Fourth, three engineers have proposed a tool: one likes Appsmith because of its Apache licence and Bengaluru roots, one likes ToolJet because a friend’s team in Kochi runs it, and one likes Budibase because it has its own built-in tables and simple automations.

We will come back to Moradabad in the worked plan.

The short version

• Appsmith is a mature internal tool builder with an Apache-2.0 Community edition, a recommended commercial image with a free plan, and paid Business and Enterprise tiers. The current release is v2.6.0, published on 28 October 2026. It runs as one container that bundles MongoDB, Redis and PostgreSQL by default, or on Kubernetes with Helm for production. SQL prepared statements are on by default. SAML and OIDC SSO, SCIM and CI/CD are Enterprise; audit logs, custom roles and environments start at Business.
• ToolJet is an AGPL-3.0 internal tool builder whose enterprise code lives in private submodules. The production channel is LTS; the current LTS patch is v3.20.251-lts from 27 October 2026, with a separate beta line (v3.21.86-beta on 28 October 2026). It runs on PostgreSQL plus Redis and uses PostgREST for its built-in database. Google and GitHub sign-in are configurable in the Community edition; OIDC, SAML, LDAP, audit logs, Git sync and multi-environment are on paid plans.
• Budibase is a GPLv3 platform with MPL-2.0 client libraries and paid features under a Business Source License. The current release is v3.50.0 from 19 October 2026. It runs as a set of services with CouchDB, MinIO, Redis, an nginx proxy and, in the current compose file, a LiteLLM gateway. OIDC SSO works in the open-source plan; enforced SSO, user groups, environment variables, backups and audit logs are Enterprise on self-host.
• All three have a busy 2026 security advisory history. Treat the builder as a production system with access to your most sensitive data, not as a side tool.
• Write a small app instead when the screen is customer facing, encodes core business rules, needs complex validation, or must be reviewed and tested like product code.

Where things stand on 29 October 2026

Appsmith. The latest release on GitHub is v2.6.0, published on 28 October 2026 at 11:40 PM IST. The release notes start with a warning for Enterprise users: Appsmith is moving its workflows feature off Temporal to a new engine, and runs that started on Temporal should be finished on v2.5.1 before upgrading, because a startup check can block the whole server if it finds pending approval requests. The same release carries a fix for a Node.js Brotli decoder vulnerability, requires the docker.env file to contain only literal values, and tightens several permission checks. Before that, v2.5.1 came on 21 October and v2.5.0 on 9 October. The v2.0 line started on 21 May 2026; its notes say any instance older than v1.96 must first go to v1.99, because 2.0 bundles MongoDB 7. Version 2.3 (13 August 2026) removed the old Appsmith AI datasource, which stopped working on 30 September 2026, and brought the Ask AI assistant to the Community edition.

ToolJet. ToolJet publishes two channels on GitHub. The LTS channel is the one its documentation recommends for production; the latest LTS is v3.20.251-lts, published on 27 October 2026 at 8:27 PM IST, a small patch about licence checks and a promo code. The LTS line moved fast in October: the documentation lists six LTS patches between v3.20.246-lts on 15 October and v3.20.251-lts on 27 October. The beta line is at v3.21.86-beta (28 October 2026, 12:50 PM IST). The README now describes ToolJet as a platform you can build by prompting, with an MCP server in beta so that coding agents can create ToolJet apps.

Budibase. The latest release is v3.50.0, published on 19 October 2026 at 1:39 PM IST. Its notes are mostly dependency bumps and fixes, including agent chat fixes, Redis session fixes and a change to require builder authorisation for automation tests. Tags ending in -cloud (v3.51.0-cloud.1 to .7 between 19 and 21 October) are prereleases for Budibase’s hosted service, not self-host releases.

Counting GitHub repository security advisories on 29 October 2026: Appsmith has 46 (6 critical, 22 high, 18 medium), ToolJet has 13 (1 critical, 1 high, 11 medium) and Budibase has 91 (24 critical, 53 high, 14 medium). Most were published in 2026 for all three. These numbers reflect reporting activity and disclosure habits as much as code quality, so do not read them as a ranking. Read them as a reminder of how much attack surface an internal tool builder carries.

The first question: is a low-code builder the right shape?

Before comparing products, look at the 14 screens on the operations head’s list and sort them.

• Read and look up. Search an order, see its job-work history and documents. Low risk, high volume. Any of these tools does this well.
• Small, controlled writes. Approve a payment correction, mark documents complete, reassign an inspection. This is the sweet spot: a form, a confirmation, one or two queries, and a role check.
• Bulk changes. Re-rate 500 piece-rate entries, close a batch of orders. Possible, but now you need a dry run, a preview, a limit, and an undo story. Many incidents with low-code tools start here.
• Business logic. Calculate karigar payments, apply export duty rules, decide credit limits. This logic should live in your services where it is tested and versioned. The admin screen should call an API that applies the rule, not reimplement the rule in a JavaScript box on a canvas.
• Customer facing. Buyer portal screens, anything external. Usually not a fit; you want your own design system, performance budget and code review.

If most of your list is in the first two groups, a builder will save real engineering time. If most of it is in the last two, you will spend that time fighting the tool.

A second thing to notice: the builder will hold credentials for your databases and APIs, and it will run queries on behalf of anyone who can open an app. So the real design question is not “which drag and drop is nicer” but “what can each person do through this tool, and how do we prove it”.

What each tool is

Appsmith

Appsmith is a builder for admin panels, dashboards and CRUD apps. You create an app in a workspace, add pages, drop widgets (tables, forms, charts, modals), and connect them to queries against datasources such as PostgreSQL, MySQL, MongoDB, REST and GraphQL APIs. Logic is written in small JavaScript objects and in {{ }} bindings. The server is Java (Spring), the editor is React.

The server acts as a proxy for queries. Datasource credentials are stored on the server and added to the request at execution time, so the browser does not see them; saved secrets cannot be read back in the editor. For SQL databases, the “Use Prepared Statement” setting is on by default, so a binding becomes a parameter rather than raw text:

-- Appsmith query with prepared statements on (default)
UPDATE job_work_receipts
SET status = 'verified', verified_by = {{ appsmith.user.email }}
WHERE receipt_id = {{ ReceiptTable.selectedRow.receipt_id }}
  AND status = 'pending';

The documentation is candid that you must turn prepared statements off for dynamic table names, dynamic WHERE clauses and IN lists, and that doing so exposes you to SQL injection. Its advice is to use an API instead in those cases. That is good advice for every tool in this post.

There are two images. The documentation recommends appsmith/appsmith-ee, the commercial edition, which has a free plan and can be upgraded with a licence key. The Community edition is appsmith/appsmith-ce, built from the Apache-2.0 repository. A minimal compose file pins a tag:

services:
  appsmith:
    image: index.docker.io/appsmith/appsmith-ce:v2.6.0
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./stacks:/appsmith-stacks
    restart: unless-stopped

Binding to 127.0.0.1 and placing a reverse proxy in front is a habit worth keeping from day one.

ToolJet

ToolJet is also a builder for internal tools with a visual canvas, about 80 components and a long list of data sources. Queries run through the ToolJet server, and its README describes AES-256-GCM encryption for credentials and a proxy-only data flow. You can write JavaScript and Python inside apps. ToolJet also ships ToolJet Database, a built-in table store on PostgreSQL exposed through PostgREST, so a team can create simple tables without a separate database.

The server is NestJS on Node.js with PostgreSQL as its main store. Two keys matter from the start: LOCKBOX_MASTER_KEY encrypts datasource credentials and SECRET_KEY_BASE protects session cookies. Generate both and keep them in your secrets manager:

# values for a ToolJet .env, stored in Vault or OpenBao, not in git
LOCKBOX_MASTER_KEY=$(openssl rand -hex 32)
SECRET_KEY_BASE=$(openssl rand -hex 64)
PGRST_JWT_SECRET=$(openssl rand -hex 32)
DISABLE_SIGNUPS=true
DISABLE_TOOLJET_TELEMETRY=true

For SQL, the PostgreSQL data source has a SQL mode with named parameters (:receipt_id) filled from a Parameters section, which is the safe way to pass user input. ToolJet also rate limits data query runs by default (50 runs per second per user and app, per pod), to stop a runaway event handler from flooding your database.

Budibase

Budibase is a low-code platform with three builders under one roof: an app builder for screens, an automation builder for backend steps, and, in recent versions, an agent builder. It has its own built-in database (Budibase DB, stored in CouchDB) as well as connectors for PostgreSQL, MySQL, SQL Server, MongoDB, REST and others. Many small teams like it because they can start with built-in tables and move to an external database later.

The self-host stack is a set of services: the app server, a worker, CouchDB, MinIO for files, Redis, an nginx proxy, and in the current compose file a LiteLLM gateway with its own PostgreSQL for AI features. The sample .env makes the point that secrets must be changed:

# Budibase hosting/.env sample (as published) - every one of these must change
API_ENCRYPTION_KEY=testsecret
JWT_SECRET=testsecret
INTERNAL_API_KEY=budibase
COUCH_DB_PASSWORD=budibase
REDIS_PASSWORD=budibase

Each Budibase app has a development version and a published version. You edit the development version, preview it, and publish when ready; you can revert the development version to the last published one. That is a simple and useful mental model for non-engineers.

Side by side

Licence, editions and governance

Appsmith. The repository is under the Apache License 2.0. The repository contains ce and ee folders in the client code, and the commercial image is what the docs recommend; it runs a free plan by default and turns on paid features with a licence key validated through cs.appsmith.com, which must be reachable outbound. The pricing page on 29 October 2026 lists Free at zero, Business at USD 15 per user per month (up to 99 users) and Enterprise at USD 2,500 per month for 100 users. Appsmith is a venture-funded company founded in Bengaluru in 2019; there is no foundation.

ToolJet. The repository is under AGPL-3.0. The .gitmodules file points frontend/ee and server/ee at ToolJet/ee-frontend and ToolJet/ee-server, and both returned 404 from the public GitHub API in our check, so the enterprise code is not public. AGPL matters if you modify ToolJet and offer it to users over a network: you must make your changes available to those users. For an internal deployment that you do not modify, that is rarely a problem, but your legal team should know. The pricing page lists a self-hosted Free plan (2 builders, up to 50 end users, up to 10 apps), a Team plan at USD 199 per builder per month, and custom Enterprise. ToolJet is a venture-funded company; its first commit was on 31 March 2021.

Budibase. The root LICENSE file says each package has its own licence and that you can consider Budibase GPLv3 overall. Server, worker and builder packages are GPL-3.0; the client and component libraries that ship inside built apps are MPL-2.0, so your apps can be under any licence. Paid features live in packages/pro under a Business Source License with a four-year change date to GPLv3, and an additional grant that allows production use unless you modify the code to defeat licence checks. The open-source self-host plan is free; the pricing comparison on 29 October 2026 lists a workspace limit of 1 and one day of automation log retention for that plan, so read it carefully against your needs. Budibase Ltd was founded in Belfast in 2019.

The practical point: all three are open core. The free edition is genuinely usable, but the features an auditor asks about first (SSO enforcement, groups, audit logs, environments) sit mostly on the paid side.

Architecture and deployment

Appsmith. One container runs the Java server, the editor, a bundled Caddy proxy and, by default, MongoDB, Redis and PostgreSQL. MongoDB is the primary store for apps, workspaces and configuration. PostgreSQL is used by Keycloak when you enable SAML SSO and by the workflows engine. For production the docs recommend Kubernetes with the Helm chart, a MongoDB replica set (the chart supports the MongoDB operator), and external Redis and PostgreSQL if you prefer managed services. The 2026 advisories about the bundled Caddy admin API and supervisord interface (both fixed) are a reminder that an all-in-one image has internal ports you should not forget.

ToolJet. A ToolJet server (plus optional separate workers for workflows) talks to PostgreSQL for application metadata, a second database for ToolJet Database, PostgREST in front of that second database, and Redis. External Redis is required when you run more than one pod or separate workflow workers. The system requirements page asks for x86 only (arm64 not supported), PostgreSQL 16 recommended and Redis 7 required.

Budibase. The compose file defines app-service, worker-service, minio-service, proxy-service, couchdb-service, redis-service, litellm-service and litellm-db. These can be split across hosts as long as they can reach each other, and the README lists Kubernetes as well as Docker as deployment options. CouchDB is the heart of the platform metadata and built-in tables, so your team needs at least basic CouchDB backup and restore skills.

Data sources and query safety

All three run queries on the server, not in the browser, and all three keep datasource credentials on the server. That is the good part. The risk is that a builder can write any query the datasource login allows, and an app user triggers it.

Appsmith uses prepared statements by default for PostgreSQL, MySQL, SQL Server and Oracle, and the docs list exactly where they must be off. ToolJet supports named parameters in SQL mode and throttles query runs. Budibase connects to SQL and NoSQL sources and adds its own internal DB; its 2026 advisories include SQL injection through the MySQL multipleStatements setting, PostgreSQL search_path injection, NoSQL operator injection through published app query templates (rated 10.0 by the GitHub CNA and 9.8 by NVD, fixed in 3.39.12), and many SSRF reports in REST and AI features. All of those are fixed in current versions, but they show the classes of bugs to test for.

Three rules work for every tool:

1. Give each builder a dedicated database role per app or per domain, never the application owner role. Grant only the tables and columns it needs.
2. Put risky writes behind an API or a stored procedure that validates input, applies limits and writes an audit row.
3. Restrict outbound network access from the builder host so that a REST datasource cannot be pointed at internal metadata endpoints.

A simple PostgreSQL role for the Moradabad support app looks like this:

CREATE ROLE tool_support LOGIN PASSWORD :'pw' CONNECTION LIMIT 10;
GRANT SELECT ON orders, job_work_receipts, shipments TO tool_support;
GRANT UPDATE (status, verified_by, verified_at) ON job_work_receipts TO tool_support;
ALTER ROLE tool_support SET statement_timeout = '5s';

Column-level UPDATE grants and a statement timeout do more for safety than any canvas setting.

Access control, SSO, audit and which parts are paid

Appsmith. The pricing page lists three standard roles on Free, custom roles and audit logs on Business, and SAML, OIDC and SCIM on Enterprise. Google and GitHub OAuth are listed for Free and Business. If your company standardises on Keycloak with OIDC, that puts you on Enterprise or behind an authenticating proxy.

ToolJet. The Community edition supports password login with an account lock after five failed attempts, Google and GitHub SSO through environment variables, signup restriction and session expiry (default ten days). The README puts RBAC with custom groups, SCIM, audit logs and row, component, page and query level access control in the enterprise list, and the pricing page puts SSO integration, custom groups and audit logs on paid tiers.

Budibase. The open-source plan supports OIDC SSO and role-based access within apps. Enforcing SSO (blocking password logins), user groups, SCIM and audit logs are listed for Enterprise. Budibase documents an SSO maintenance mode environment variable for self-host lockout recovery, which you should know about before you need it.

If the buyer audit asks “who changed this payment record”, the honest answer on a free edition is usually “our database audit trigger says so”, not “the builder’s audit log says so”. That is fine. Put the audit in the database or the API, where it does not depend on the builder edition.

Git, version control and environments

Appsmith has Git sync: apps are serialised into a repository, with branches and pull requests. The pricing page lists three Git repositories on Free and unlimited on Business, with branch protection, custom environments and CI/CD on paid tiers. Git integration has also been a source of advisories in 2026 (path traversal and symlink issues in Git import, command injection in a Git path), all fixed, so keep the version current if you use it.

ToolJet has app versions inside the product. Git sync, multi-environment (development, staging, production) and CI/CD APIs are on paid plans; configuring Git sync through environment variables is marked beta in the docs.

Budibase does not document Git sync. It has the development and published split, export and import of workspaces (optionally password encrypted), and backups created on publish (backups are a paid feature). Its CI/CD guide uses export and import API endpoints, which the docs say are not available on free or open-source tiers. Note that exports include datasource configuration and credentials unless you move secrets into environment variables, which are also a paid feature.

For the Moradabad team, this means: on any free edition, plan for “one production instance, careful publishing, and exported app definitions kept in a private repository”, not for a full promotion pipeline.

Security history

All counts are GitHub repository advisories on 29 October 2026.

• Appsmith: 46. Notable ones include CVE-2026-22794 (password reset and verification links built from an unvalidated Origin header, account takeover, fixed in 1.93), CVE-2026-24042 (public apps could execute unpublished edit-mode actions, fixed after 1.94), CVE-2026-30862 (stored XSS in the table widget, fixed in 1.96), CVE-2026-55454 (bundled Caddy admin API reachable through SSRF inside the container, fixed in v2.1), and GHSA-fqwc-g9wm-5895 (symlinks in Git import allowing file read and write, fixed in 2.3). Two more were published on 28 October 2026.
• ToolJet: 13. The most serious is CVE-2026-55413: a builder on the free tier could overwrite a shared marketplace plugin with server-side JavaScript, giving remote code execution on the instance; fixed in 3.20.178-lts. Eight advisories in August 2026, grouped under CVE-2026-73068, were cross-workspace authorisation bugs in ToolJet Database routes. One from 13 October 2026 is a signup bypass when signup is disabled.
• Budibase: 91. The list includes CVE-2026-54350 (anonymous NoSQL operator injection through published app query templates, 10.0 from the GitHub CNA), CVE-2026-35216 (unauthenticated remote code execution through a webhook trigger and the bash automation step), CVE-2026-46425 (SCIM endpoints without role checks), CVE-2026-41428 (authentication bypass through an unanchored regex in the public endpoint matcher), CVE-2026-42239 (session cookie set without httpOnly), and many SSRF reports across REST datasources, OAuth2 token URLs and AI table generation.

The patterns repeat across all three: SSRF through datasources, broken object-level authorisation between workspaces or tenants, privilege escalation from builder to admin, and stored XSS through names and widgets. Your defences should match: restrict egress, keep builders and viewers separate, give few people builder rights, and patch on a schedule. For all three, subscribe to the repository’s security advisories, not just releases.

AI features

Appsmith brought its Ask AI assistant to the Community edition in v2.3 and retired the older Appsmith AI datasource on 30 September 2026. It documents Appsmith Agents, built from an agent query plus a chat widget, with knowledge sources indexed into a vector store and function calls that can run your Appsmith queries.

ToolJet puts AI app generation, an AI query builder, AI debugging and an agent builder in its enterprise feature list, priced in AI credits. It also ships an MCP server in beta so that coding agents can build ToolJet apps; the pricing page says that path does not use ToolJet AI credits. Bring your own LLM keys is listed for Enterprise.

Budibase has an agent builder with tool calling, knowledge sources and evals, and the self-host compose now includes a LiteLLM service, which means one more service with its own master key and database.

AI that generates queries against your production database deserves the same caution as a new junior engineer with write access. Use it on staging data, review the generated queries, and keep the database role narrow so a bad suggestion cannot do much harm.

Operations and upgrades

Appsmith released v2.4 to v2.6.0 between 9 September and 28 October 2026, often a week or two apart, and some releases have upgrade checkpoints: v1.99 before 2.0, finishing Temporal runs on v2.5.1 before 2.6.0, and literal values in docker.env from 2.6.0. appsmithctl backup covers MongoDB, configuration and Git data but not the PostgreSQL used for SAML SSO and workflows, which you must back up separately. Pin the image tag; the docs say so too.

ToolJet separates LTS from beta. Use LTS in production and expect frequent patch releases; six LTS patches in twelve days in October 2026 means you need an easy, tested upgrade path rather than a quarterly ritual. Back up both PostgreSQL databases.

Budibase shipped a new minor release almost every Monday from v3.42.0 (17 August 2026) to v3.50.0 (19 October 2026). Upgrades mean pulling new images for several services. Back up CouchDB, MinIO and Redis configuration; on the open-source plan, the in-product backups feature is not available, so plan volume or database level backups.

For all three: run a staging copy, upgrade staging first, click through the five most used apps, then upgrade production.

Footprint

Appsmith gives a baseline of 2 vCPU and 8 GB RAM for evaluation and low traffic, with at least 10 to 15 GB of free disk. On Kubernetes it asks for 1.33 or newer, app pods with at least 6 GB of memory and at least two nodes of 2 vCPU and 8 GB.

ToolJet lists 1 vCPU, 4 GB RAM and 8 GiB disk for the application VM, x86 only, plus PostgreSQL 16 (it recommends 2 vCPU, 8 GB and 20 GB disk for the database) and Redis 7.

Budibase does not give a fixed number in the compose guide beyond what Docker needs; the stack is eight services in the current compose file. Size it from a pilot.

None of these are tiny. A builder that will serve 40 operations staff is a real service with real memory needs, so budget for it like one.

A worked plan for Moradabad

1. Sort the 14 screens. The team finds nine read-and-lookup or small-write screens, three bulk-change screens and two that are really business logic (payment recalculation and duty rules). The two logic screens go to the product backlog as API endpoints first.
2. Fix the database access problem before any tool. Remove the shared read-write login. Create tool_support, tool_finance and tool_exports roles with table and column grants and a statement timeout. Add an audit trigger on payment and inspection tables that records the database role, the application user passed as a session variable, old and new values.
3. Decide identity. Staff must log in with Keycloak through OIDC. That rules out Appsmith’s free and Business tiers for direct OIDC and points either to Appsmith Enterprise, to ToolJet paid tiers, or to Budibase open source (OIDC in the free plan, though without enforcement).
4. Decide licence posture. Legal is comfortable with Apache-2.0 and GPLv3 for internal use, and with AGPL-3.0 as long as the team does not modify ToolJet. Budibase’s BSL pro package is only relevant if they buy Enterprise.
5. Pilot two tools for two weeks. The team picks Appsmith Community and Budibase open source for the pilot, because both can run on a staging VM with no licence. Each engineer builds the same three screens: order lookup, payment correction approval and shipment documents checklist.
6. Score the pilot on boring things. How long the payment correction screen took, whether the database role was enough, how a bad input was handled, how the app was exported to git, how long an upgrade took on staging, and what the auditor would see.
7. Choose. In this invented story the team chooses Appsmith Community for now: the Git sync with three repositories covers their small app count, prepared statements by default suit their PostgreSQL-heavy work, and the all-in-one container is easy on staging. They put Appsmith behind their existing reverse proxy with Keycloak in front through an authenticating proxy, accept form login only for two break-glass admins, and keep audit in the database. Budibase is a close second; they would have picked it if they needed built-in tables for the export documentation team. ToolJet stays on the watch list for when they need paid multi-environment.
8. Lock down the host. Bind to localhost behind the proxy, restrict egress to the database, two internal APIs and the licence endpoint if they ever move to the commercial image, and block the cloud metadata address.
9. Set ownership. One platform engineer owns the instance and upgrades; each app has a named business owner and a named engineering reviewer. Only six people get builder rights.
10. Write the runbook. Backup with appsmithctl plus a nightly MongoDB dump, restore test once a quarter, upgrade staging within a week of each release, and read the advisories list every Monday.

When each is better

• Appsmith is better when your apps sit mostly on SQL databases and REST APIs, you want an Apache-2.0 base, you value Git-based app versioning, and you can run MongoDB (bundled or managed) without fuss. Its release notes are also unusually clear about upgrade checkpoints.
• ToolJet is better when your team prefers a Node.js and PostgreSQL stack you already know how to run, you like a clear LTS channel, and you expect to pay for multi-environment, Git sync and fine-grained access control. It also suits teams that want to build apps from a coding agent through MCP.
• Budibase is better when non-engineers need to start with simple built-in tables and forms, when OIDC in the free edition matters, and when light automations in the same tool are welcome. It suits departments that do not yet have a proper database for their data.

When not to adopt an internal tool builder

• The screen is customer facing, or will become a product.
• The logic is core to the business and needs unit tests, code review and versioned deploys. Put it in a service and give the builder an API to call.
• You need strong guarantees on bulk changes, such as a preview, approval and rollback for 10,000 rows. Write a small job with a dry-run flag.
• You have only one or two screens. A small FastAPI or Django view with your existing login is less to run than a new platform with its own databases.
• Nobody will own the instance. An unpatched builder with production credentials is worse than no builder.
• What you really need is automation between systems. That is the subject of the workflow automation post, not this one.

A small app is often the right call. A hundred lines of Django with a model form, a permission decorator and an audit row can be the safest payment correction screen you will ever ship.

A short history

Internal tools used to be built by hand: Rails scaffolds, Django admin, PHP pages behind a VPN, and later Microsoft Access and Excel macros on the business side. Around 2017 to 2019 hosted products such as Retool showed that a canvas of tables and forms on top of SQL and APIs could cover most admin screens.

Budibase started first among our three; its repository was created in June 2019 and the company is based in Belfast. Appsmith followed, founded in Bengaluru in 2019, with the repository created on 30 June 2020 and v1.0 tagged on 17 August 2020. ToolJet made its first commit on 31 March 2021, tagged v2.0.0 in January 2023 and v3.0.0-ce-lts in November 2024.

By 2026 all three have added the same layers on top of the canvas: workflows or automations, AI assistants, agent builders and, in ToolJet’s case, an MCP server for coding agents. At the same time, almost all of their published security advisories date from 2026, whatever the mix of reasons behind that. The lesson of the history is steady: the canvas is the easy part, and access control is the hard part.

Decision guide

• Your staff log in with OIDC and you will not pay: Budibase open source, or any tool behind an authenticating proxy.
• You want Git-based versioning of apps on a free edition: Appsmith, within three repositories.
• You need dev, staging and production promotion: plan for a paid tier on any of the three.
• You need built-in tables for a department without a database: Budibase, or ToolJet Database.
• Your platform team knows PostgreSQL and Node.js but not MongoDB or CouchDB: ToolJet will feel most familiar.
• You need ARM hosts: not ToolJet (x86 only by its requirements page); Appsmith documents AMD and ARM.
• The screen holds core business rules: none of them; write the API and maybe a small UI.

Checklist

• Screens sorted into lookup, small write, bulk change, business logic and customer facing.
• Shared database logins removed; one narrow role per app or domain with column grants and a statement timeout.
• Audit for sensitive tables in the database or API, independent of the builder edition.
• SSO plan decided, with the edition it needs written down.
• Licence read by legal: Apache-2.0, AGPL-3.0 or GPLv3 plus BSL pro.
• Image tag pinned; no latest in production.
• All placeholder secrets replaced and stored in a secrets manager.
• Builder bound to localhost or a private network behind a reverse proxy with TLS.
• Egress restricted; cloud metadata address blocked.
• Builder rights limited to a small named group; signups disabled.
• Backups of the builder’s own databases tested with a restore.
• Staging instance, upgraded first.
• Security advisories for the repository watched weekly.
• Each app has a business owner and an engineering reviewer.

Common mistakes

• Using the application owner database login. Every bug in the builder then has full write access to your data.
• Turning off prepared statements to make a dynamic filter work. Build the filter in an API, or use safe patterns such as = ANY(...) for lists where the database supports it.
• Leaving sample secrets. Budibase’s sample .env ships testsecret and budibase; ToolJet’s example has an all-zero lockbox key. They are samples, not defaults to keep.
• Treating builders as viewers. In all three tools, a builder can see and change queries. Builder to admin escalation has been a repeated advisory theme. Give builder rights sparingly.
• Forgetting the builder’s own data stores. MongoDB, CouchDB, PostgreSQL and MinIO hold your apps and sometimes your credentials. Back them up and restrict them.
• Running latest. Upgrade checkpoints, like Appsmith’s Temporal transition in v2.6.0, will surprise you on a restart.
• Exporting apps with credentials and sharing the file. Budibase’s docs warn about this directly; the same care applies to any export.
• Putting business rules in canvas JavaScript. It works until two apps calculate the same payment differently.
• Exposing public apps without thinking. Several 2026 advisories involved public or anonymous app access. Keep apps private unless they must be public.

The drill we ran

This time the drill was deliberately light. All three tools ship mainly as Docker images with several supporting databases, and our rules for the box do not allow privileged Docker, system services or package installs, so we did not start Appsmith, ToolJet or Budibase. Everything below is a static check of files the vendors publish.

1. We downloaded Budibase’s hosting/.env, ToolJet’s .env.example and ToolJet’s .gitmodules from their default branches on 29 October 2026.
2. We wrote a 20-line Python script that flags any variable whose name contains KEY, SECRET, PASS, PASSWORD or TOKEN and whose value is empty or a known placeholder. It flagged 26 lines in total. In Budibase’s sample, API_ENCRYPTION_KEY and JWT_SECRET were testsecret, and INTERNAL_API_KEY, COUCH_DB_PASSWORD, REDIS_PASSWORD, the MinIO keys and the LiteLLM master and salt keys were budibase. The file itself says these should be updated. In ToolJet’s example, LOCKBOX_MASTER_KEY was 64 zeros, SECRET_KEY_BASE was a replace-me string and PGRST_JWT_SECRET was empty.
3. We read the licence field in each Budibase package. Server, worker, builder and backend-core are GPL-3.0; client, bbui, frontend-core, string-templates and sdk are MPL-2.0; the pro package says UNLICENSED in package.json while its licence file is the Business Source License.
4. We checked ToolJet’s enterprise submodules. Both ToolJet/ee-frontend and ToolJet/ee-server returned 404 from the public GitHub API, which confirms that a build from the public repository does not contain enterprise code.
5. We confirmed with pgrep that no drill process was left running.

What we did not run: any of the three servers, any UI, SSO, query execution, permission test, upgrade or backup. If you repeat this drill on your own machine with rootless Docker or a VM, the next useful steps are to start each tool on loopback, create a viewer user, and try to run an unpublished query and a REST call to 169.254.169.254 from a viewer session.

Unlearn, re-learn

• Unlearn “low-code means low risk”. Re-learn that a builder holds your database credentials and runs queries for many people; it deserves the same care as your main API.
• Unlearn “the free edition is the product”. Re-learn to list the features your auditor will ask for and check which edition has them before you build 20 apps.
• Unlearn “access control lives in the tool”. Re-learn to put the hard limits in the database role and the API, so a tool bug or a wrong click cannot go beyond them.
• Unlearn “we will upgrade when something breaks”. Re-learn that 2026 brought dozens of advisories to these tools, and a staged upgrade every few weeks is the normal cost of running one.
• Unlearn “one more screen is quicker in the builder”. Re-learn to ask whether the screen is a lookup, a small write or business logic, and to write a small app when it is the last.

Sources

• Appsmith: Appsmith repository, v2.6.0 release, v2.0 release, v2.3 release, LICENSE (Apache-2.0), Docker installation, Kubernetes installation, Deployment architecture, Infrastructure and capacity planning, Self-hosting best practices, Query settings, Prepared statements, Security, Appsmith Agents overview, Pricing, Security advisories, CVE-2026-22794 at NVD, CVE-2026-24042 at NVD, CVE-2026-30862 at NVD
• ToolJet: ToolJet repository, v3.20.251-lts release, v3.21.86-beta release, LICENSE (AGPL-3.0), .gitmodules, Deployment versions, System requirements, Environment variables, PostgreSQL data source, Pricing, Security advisories, CVE-2026-55413 at NVD
• Budibase: Budibase repository, v3.50.0 release, LICENSE, Pro package licence (BSL), docker-compose.yaml, Docker compose guide, OpenID Connect, Enforce SSO, SSO maintenance mode, Export and import workspaces, Integrating with CI/CD, Pricing, Security advisories, CVE-2026-54350 at NVD
• Related posts on Revisit.Tech: workflow automation in 2026, authorization in 2026, Keycloak and its alternatives, Vault and OpenBao, schema migrations in 2026, PostgreSQL backups in 2026, MongoDB alternatives in 2026, reverse proxies in 2026