ToolJet shipped 20 release events in 30 days while maintaining separate beta and long-term support tracks. That is the clearest signal in the data. The project is not merely adding AI copy to a low-code product. Its recent releases show a team trying to make app generation, data access, permissions, and Git-based delivery behave like one production system.

From visual internal tools to an AI application platform

ToolJet’s official site now leads with full-stack enterprise internal apps built from natural-language descriptions. It groups app generation, AI agents, workflows, a database, and integrations into one product. That positioning is broader than the familiar low-code pitch of dragging a table onto a canvas and connecting it to SQL.

The GitHub repository provides a more useful boundary. It describes the public repository as the open-source foundation of ToolJet AI. The community edition includes a visual builder, drag-and-drop UI, a built-in database, JavaScript and Python execution, multi-page apps, collaborative editing, and connections to databases, APIs, SaaS applications, and object storage. The repository lists 60 or more responsive components and 80 or more data sources. ToolJet’s current platform overview in its official documentation lists 70 or more UI components, which suggests the product surface is still moving and that counts can vary by edition or documentation date.

That distinction matters. The open-source repository is licensed under AGPL-3.0, an OSI-approved open-source license according to the supplied ToolVitals openness record. The repository also points readers to ToolJet AI for AI-generated interfaces, query assistance, debugging, and enterprise features. Buyers should not assume every capability promoted on the main website is present on identical terms in the community edition. ToolVitals records no hosted pricing for ToolJet, but that means hosted pricing was not tracked in this payload. It does not mean ToolJet Cloud or commercial plans are free.

The underlying problem is concrete. Internal software often starts as a spreadsheet, an admin script, or a dashboard that quietly becomes operational infrastructure. Teams then need permissions, deployment controls, data connectors, auditability, and predictable upgrades. ToolJet is trying to keep the speed of visual construction while adding those controls before the app becomes another unowned production liability.

The metrics say velocity, not perfection

ToolVitals gives ToolJet a 229.1 hot score and perfect 100 scores for health, shipping, and the combined ToolVitals score. Data confidence is also 100. The repository has 38,200 GitHub stars, 30 releases in the last 90 days, and 20 release events in the last 30 days.

Those release counts are the strongest evidence. Twenty events in 30 days is roughly a release every working day, although the events are not equivalent in scope. Some are compact patches. Others collect major connector, permission, performance, and application-builder changes. Treating every release as the same unit would exaggerate output, but the frequency still shows an active delivery process.

Two fields are absent: commits in the last 30 days and active contributors. That prevents a deeper claim about how much engineering work sits behind the release count or how broadly maintenance is distributed. A repository can publish many tags from a narrow branch, automate releases, or backport the same fix across several trains. ToolVitals can confirm the events it measured. It cannot infer team size from missing contributor data.

The perfect scores need the same discipline. A health score of 100 means ToolJet satisfied the health signals in ToolVitals’ model. It does not mean the software has no defects. A shipping score of 100 captures visible delivery activity, not upgrade safety or architectural quality. A ToolVitals score of 100 is a monitoring result, not a product review score.

For a skeptical engineering lead, the useful conclusion is narrower and stronger: ToolJet is visibly maintained, has a large public audience, and publishes enough releases to make version selection a real operational decision. Before adoption, test the exact community or commercial edition you plan to run, pin an LTS image, rehearse rollback, and validate your critical connectors. High velocity reduces abandonment risk, but it increases the cost of careless upgrades.

Two release trains reveal the product strategy

The July releases show a deliberate split. Version 3.21.51-beta, published July 14, added single-app and module version pulls from Git, improved Git sync interactions, corrected branch naming in an export modal, and fixed stale app files when moving an app into a same-named folder. Version 3.21.49-beta added a Git object cache for workspace Git sync clones and fixed data-source version and naming collisions.

These are not flashy AI demonstrations. They are deployment mechanics. Pulling one application or module version matters when a workspace contains many independently changing assets. Caching Git objects matters when repeated clones become slow. Correct branch labels and collision handling matter because ambiguous state is dangerous in promotion workflows.

The official GitSync documentation frames the feature as a way to move and back up workspace applications through Git repositories. It supports cloud and self-hosted Git providers, with plan-specific availability. The GitSync API documentation also describes programmatic pushes and pulls for CI/CD on self-hosted enterprise instances. The recent beta work therefore fits a clear direction: ToolJet wants generated and visually edited applications to participate in normal delivery automation, rather than live outside it.

The LTS line carries a different burden. Version 3.20.192-lts, published July 7, added a Cascader component, an Asana data-source plugin, and a permission system for ToolJet Database. It also replaced SVGr usage with static images to reduce JavaScript bundle size, restricted avatar uploads to image files, and fixed SQL-mode queries containing both comments and ToolJet references.

Version 3.20.191-lts added Databricks to the data-source list and updated the Redis APT repository to its official source with package-security improvements. Version 3.20.190-lts tightened who could change application visibility, fixed keyboard access to disabled widgets, corrected date sorting, and repaired expression parsing. Version 3.20.189-lts added native AI data-source support for OpenAI plugins and OpenAPI specifications, richer query execution metadata, a DynamoDB overhaul, and Databricks schema exploration.

Read together, these releases show four priorities: more connectors, stronger permissions, safer application behavior, and better promotion through Git. AI support is one layer in that stack, not the whole stack. The releases spend at least as much attention on table behavior, query correctness, repository state, package sources, and access boundaries as they do on agent features.

That balance is healthy for an enterprise app builder. Generated software still fails through ordinary causes. A permission is too broad. A query references the wrong endpoint. A disabled control remains keyboard-accessible. An app pulls stale files. ToolJet’s recent notes show the maintainers working on those boring failure modes, which is more informative than another prompt-to-dashboard demo.

Security claims still need deployment-level verification

ToolJet’s official security documentation says the server proxies data-source traffic without storing returned data, keeps credentials away from the frontend, and encrypts data-source credentials with AES-256-GCM. Its access-control documentation describes permissions across applications, data sources, workflows, folders, and workspace constants. Recent LTS changes around ToolJet Database permissions and application visibility line up with that stated model.

That is evidence of security design, not evidence that every deployment is secure. Self-hosted operators control TLS termination, secrets, network paths, database hardening, image updates, backups, identity-provider configuration, and upgrade timing. Commercial compliance statements also need to be checked against the exact service and contract in scope.

A serious evaluation should include attempts to cross workspace and folder boundaries, inspection of browser network traffic, secret-rotation tests, connector-specific authorization checks, and restore drills. It should also verify whether the GitSync, SSO, audit, and fine-grained permission features required by the team are included in the chosen edition. The release notes provide reasons to test these areas. They do not replace the tests.

Where ToolJet sits beside faster and larger projects

ToolJet’s 20 release events in 30 days exceed LangChain’s 17 and OpenClaw’s 16 in the supplied comparison set. Kilo Code recorded 29, while Composio and ClickHouse each recorded 57. ToolJet is therefore shipping quickly, but it is not an outlier once compared with highly active developer infrastructure projects.

The star comparison adds scale without deciding quality. ToolJet’s 38,200 stars are far below LangChain’s 141,697 and OpenClaw’s 382,829, above Composio’s 29,222 and Kilo Code’s 26,149, and below ClickHouse’s 48,620. Stars mix age, audience size, category popularity, and marketing reach. They are useful as evidence that a project has attracted attention, not as a procurement ranking.

The more relevant comparison for an internal-tools buyer is not raw popularity. It is whether ToolJet’s combined builder, database, connector, permission, and deployment model removes enough custom engineering to justify adopting a platform. A team seeking an LLM application framework may prefer LangChain. A team primarily integrating agent tools may compare Composio. ToolJet is aimed at teams that need operational applications with interfaces, data access, workflows, and governance in one place.

What ToolVitals cannot infer

ToolVitals can measure visible stars, releases, activity signals, website health signals, SSL signals, and uptime observations when those collectors are available. This payload gives high-confidence scores and release counts, but no 30-day commit count or active-contributor count. It does not measure code quality, test depth, upgrade pain, user satisfaction, support response, revenue, customer retention, or whether a generated application works well under real load.

It also cannot tell whether 20 releases created value for a particular team. Frequent releases may indicate responsive maintenance. They may also create version churn, backport complexity, or pressure on self-hosted operators. The beta and LTS split is encouraging because it gives those concerns an explicit shape, but buyers still need to inspect release compatibility and migration guidance.

For ToolJet’s maintainers, the opportunity is to make that split even easier to evaluate. Release notes already identify fixes and contributors. Clearer upgrade-risk labels, edition availability, migration requirements, and links to tests or documentation would turn a long change list into an operational decision record. The product story says AI can take an idea to production. The release process should make the path from one production version to the next just as legible.

Recommendation

If your team repeatedly builds authenticated internal applications that combine forms, tables, dashboards, database access, SaaS connectors, and approval workflows, evaluate ToolJet on its LTS track. Its 20 release events in 30 days, 30 releases in 90 days, active GitSync work, and recent permission changes support a concrete case that the platform is being maintained around production concerns, not only AI demos.

Run a scoped pilot with one real workflow. Use the exact data source, identity provider, permission model, and deployment target you expect in production. Compare the time saved against the cost of platform ownership and edition-specific features. Choose the beta line only if you need a named capability and can absorb regression testing. For production self-hosting, follow the repository’s own recommendation and start with LTS.

Sources