Appsmith vs ToolJet

Appsmith and ToolJet solve the same problem from the same side. Both are low-code builders for internal tools: you drag widgets onto a canvas, bind them to the databases and APIs you already run, add JavaScript where a binding needs logic, and publish the result as an app your team logs into. Neither wants to be your system of record. The differences are in what else comes in the box, how the box is licensed, and how much of a server it needs.

What each one is

Appsmith is a Java backend with a TypeScript client. Its datasource reference lists REST and GraphQL APIs, databases including PostgreSQL, MongoDB, MySQL, Microsoft SQL Server, Snowflake, Redis and S3, a long row of SaaS integrations from Airtable to Zendesk, and OpenAI, Anthropic and Google AI, with the note that "if there isn't a supported datasource, you can connect using the REST API". Logic lives in mustache bindings, "expressed by wrapping the code inside {{ }}", and in JS Objects, each "a collection of JavaScript functions and variables". That code runs in a restricted context: it "does not have access to the global window object".

ToolJet is a TypeScript platform with a NestJS server. Its README claims "80+ Data Sources" for the Community Edition, and every app starts with four built in: the ToolJet Database, a REST API source, "Run JavaScript Query" and "Run Python Query". Two things set it apart from Appsmith. The first is that built-in database, which the docs describe as a store that lets you "Maintain tables of data" and "Edit, search, filter, sort, and filter data using a spreadsheet-like interface", with primary and foreign keys, a SQL editor and schema export; our catalog entry notes it is PostgreSQL served through PostgREST. The second is ToolJet Workflows, which "enable users to create complex, data-centric automations using a visual, node-based interface", triggered from app actions "such as button clicks or form submissions", by webhooks, or on a schedule.

Appsmith's pricing page lists workflows, custom roles and audit logs under the Commercial edition's Business plan, and SAML/OIDC SSO under Enterprise. If a scheduled job that writes back to a database is part of the tool you want, workflows ship in ToolJet's self-hosted build with no paid-tier marker in the docs, against Appsmith's Business plan.

Licences

Appsmith's public repository is plain Apache-2.0, end to end. The Docker page defaults to the appsmith-ee image, which "installs the Commercial edition", and tells you to "replace appsmith-ee with appsmith-ce" for the Community Edition. Our snippet pins appsmith-ce. The Commercial edition has a Free plan (the pricing FAQ says self-hosted instances drop to it after a Business trial) as well as paid ones, but it is a separate image and not the open-source code.

ToolJet's repository is AGPL-3.0, and its .gitmodules points server/ee and frontend/ee at ToolJet/ee-server and ToolJet/ee-frontend, separate repositories that hold the paid code. The README puts AI app generation, the AI query builder and the agent builder under "ToolJet AI (Enterprise)". AGPL is a real difference from Apache for one case: if you modify ToolJet and let people use it over a network, the licence asks you to publish those modifications. For a team running an unmodified image behind its own login, that rarely matters, but it is the clause to read.

Footprint and setup

Appsmith is one service. The Docker page says "The default Docker Compose setup runs MongoDB, Redis, and PostgreSQL inside the Appsmith container" and asks you to "Plan for at least 8 GB of RAM on the host for this all-in-one deployment". The compose is a single image, one ./stacks volume and no secrets to generate; the first boot "can take up to 5 minutes", which is why our snippet stretches the healthcheck start period. TLS is built in: set a custom domain in Admin Settings and "it will generate an SSL certificate" via Let's Encrypt, because "Appsmith uses Caddy as its internal reverse proxy".

ToolJet is two containers, its own image beside PostgreSQL, and a .env you have to fill: TOOLJET_HOST must start "with either http:// or https://", and LOCKBOX_MASTER_KEY and SECRET_KEY_BASE are secrets that upstream's internal.sh normally generates. Lose that file and the stored data-source credentials are gone. The system-requirements page asks for "4GB" of RAM and "1 vCPU" for the application server on "x86 (arm64 is not supported)"; the "8GB" and "2 vCPUs" it lists for PostgreSQL describe a separate database host. Upstream's compose pulls the rolling tooljet/tooljet:ee-lts-latest tag and tells you to swap in the exact LTS tag from Docker Hub, which is what our pin does.

In our install check (GCP e2-standard-2, Ubuntu 26.04, October 2026), Appsmith idled at ~1.1 GB of RAM and ~4.1 GB of disk; ToolJet idled at ~607 MB of RAM and ~6.2 GB of disk. So the documented floors run the other way from the measurements: Appsmith asks for the bigger host and idled heavier, with three databases running inside the one container, while ToolJet's lower idle comes with a larger image on disk. We rate Appsmith 2 out of 5 to deploy and ToolJet 3 out of 5, the extra point for the .env, the PostgreSQL service and the host-address setting that has to be right before you invite anyone.

Which to choose

Choose Appsmith if you want the plainest option: one container with nothing to generate, an Apache-2.0 repository with no separately licensed directory, built-in Let's Encrypt, and screens over data that already lives somewhere else. Give it an 8 GB host as upstream asks.

Choose ToolJet if the tool needs its own tables or its own automations: the ToolJet Database for data that has no other home, workflows triggered by buttons, webhooks or a schedule, and Python as well as JavaScript in queries. Accept the AGPL, the .env discipline and an x86-only image.

Moving between them

The data stays where it was, because both bind to your existing sources, so switching means rebuilding screens rather than migrating a database. The exception is anything you put in the ToolJet Database: that is a PostgreSQL schema you would export before leaving. Neither reads the other's app definitions.

Running Appsmith or ToolJet on a VPS

Both installs are verified on Ubuntu 26.04; the pinned compose files are on the Appsmith and ToolJet pages. Appsmith can terminate TLS itself once a domain points at it; ToolJet serves plain HTTP on port 80, so put a reverse proxy in front before real use. If you would rather start from your own data model than from screens, see Budibase vs Appsmith and NocoBase, and the whole field is on the low-code internal tools hub.