Joget Community Edition is a visual app platform with a GPLv3 core

Three product categories in one visual environment

Joget is described as a next generation open source no-code and low-code application platform for faster, simpler digital transformation. The interesting part of the description is what it combines: the best of rapid application development, business process automation and workflow management in a simple, flexible and open platform.

Those three categories have different audiences, and putting them in one product is the central design decision. Rapid application development is about a builder making an application. Business process automation is about a process owner describing steps and routing. Workflow management is about work items with states, assignments and timers. A platform that covers all three lets the same designer, who may not write code, produce a form, a process and the workflow that moves data between them.

The stated consequence is that business and technical teams can collaborate to rapidly build full-fledged enterprise applications visually, anywhere, anytime. The bullet list behind that claim is worth reading as a feature summary. A web-based visual approach empowers non-coders to build and maintain apps. Time to market is reduced from months to weeks or days. Apps built are mobile ready and cloud ready. There are APIs for integration and a plugin architecture for extensibility. And there is an App Store for enterprise apps, called the Joget Marketplace.

That last item is the interesting one technically. A platform that treats ready made apps as a distribution channel is a platform that expects to be extended rather than merely configured, and it is the reason the repository is split into plugin modules.

A multi-module Java build, with a Jakarta migration visible in the tree

The repository layout describes the system, and it is the most technical information the README offers, since the build instructions live in a knowledge base article rather than in the repository.

The modules are named with a wflow prefix. There is wflow-app, which is the application layer, and wflow-core for the platform core. There are wflow-commons and wflow-commons-jakarta, and wflow-shark and wflow-shark-jakarta, and the difference between the two versions of each is the Jakarta EE namespace change, which is the standard way a Java project carries both the pre-Jakarta and post-Jakarta forms of the same code. There is wflow-consoleweb for the web console, wflow-wfengine for the workflow engine, wflow-jdbc for database access, wflow-plugin-archetype and wflow-plugin-base for plugin development, wflow-directory for directory and user management, and wflow-install.

The topic list on the repository matches: Java and JavaScript on the code side, Spring and Hibernate for the framework and persistence layers, and CSS for the interface.

Two observations follow. The plugin archetype and plugin base modules mean that third-party extensions are a first-class part of the source tree, with a Maven archetype for generating a new one. That is consistent with the plugin architecture and the Marketplace, and it means extension work is a supported path rather than a hack. And the presence of both commons variants tells you the platform has been carried across the Jakarta transition, which is the kind of maintenance burden a project with this many modules accumulates.

The default branch is 9.1-RELEASE, so the trunk of the repository is a release line rather than a development head.

Deployment is a menu of eleven options, and the choice is yours

One of the platform's key principles is flexibility, and the README immediately demonstrates it with a long list of deployment options: on-premise, on-demand cloud, Docker, Kubernetes, Cloud Foundry, a certified OpenShift operator, the Red Hat Marketplace, the Google Workspace Marketplace, the AWS Marketplace, the Azure Marketplace and the Google Cloud Marketplace.

The full list, as the README writes it:

On-Premise, On-Demand Cloud, Docker, Kubernetes, Cloud Foundry, Certified OpenShift Operator, Red Hat Marketplace, Google Workspace Marketplace, AWS Marketplace, Azure Marketplace, Google Cloud Marketplace.

That list is a real strategic statement. The presence in four different cloud marketplaces and in an enterprise operator catalogue means the vendor expects to be installed into environments the vendor does not control, which is the normal shape for a platform sold to enterprises with existing procurement and container platforms. For a team with a Kubernetes platform and a marketplace account, the operator route is likely to be the least surprising installation path.

For a developer, the practical consequence is that there is no single supported quick start in the repository. The README links to a Get Started page on the project site for the hosted route, and the Docker and Kubernetes guides live in the knowledge base.

The build instructions are similarly offloaded. To build from source, the README refers to a Build Source Code document hosted in the knowledge base, and contributing points at a How to Contribute guide. That is a reasonable arrangement for a project with this many modules, since the build recipe changes with the release line, but it does mean you cannot clone and build from what is written in the repository alone.

The Community Edition is GPLv3, the rest are commercial

The licensing arrangement is the most consequential fact in the README, and it applies to the whole family of editions rather than to the code alone.

Joget Community Edition, which is what this repository holds, is licensed under the GNU General Public License version 3. Joget Professional Edition, Enterprise Edition and Large Enterprise Edition are licensed under a commercial EULA, and the repository description points at the project site for commercial licensing.

So the repository you would read to understand the product is the GPLv3 edition, and the other editions are separate products built on a similar base. That has a practical effect on evaluation. You can read the Community Edition source to see how the platform is put together, but features that only exist in the paid editions will not be in this tree, and there is no statement in the README about which those are. The edition boundary is documented elsewhere, on the product pages.

Without giving legal advice, the mechanical point about GPLv3 is well known and worth stating: distributing a modified GPLv3 program, or a work that links to it in the way the licence treats as a combined work, carries the obligation to publish the corresponding source. For an organisation that ships a Joget-based product to its own customers, that obligation is the question to take to a lawyer, and the existence of a paid edition with an EULA is precisely how the vendor offers an alternative answer. Whether the obligation triggers for a deployment inside your own network is a different question, and one that depends on facts your own counsel has to establish.

The repository description is explicit that this is the GPLv3 licensed open source repository, so there is no ambiguity about which licence the tree you are reading carries.

The ecosystem is the learning path

The resources section is unusually long, and reading it tells you what kind of project this is.

For questions there is a Community Q&A site, described as a place to ask questions, get answers and help others. For reference there is a Knowledge Base with user and developer documentation, samples and other material. For getting oriented there are video tutorials that give a quick overview and get a first app built, and the Joget Academy, which is a self-paced online learning and certification programme.

For reuse there is the Joget Marketplace, where you download ready made apps, plugins and templates. That is the marketplace referenced in the feature list, and the existence of a certification track alongside a template catalogue tells you the audience includes both business users building apps and developers extending the platform.

There is also a translation effort, with translations available for more than 20 languages, and a separate site for it. The rest of the section is conventional for a vendor with a community: an events page for webinars and conferences, a press page for releases, a reviews page for testimonials, and social links on Twitter, LinkedIn, Facebook and YouTube.

For a platform whose selling point is that non-coders build the applications, this matters. The users of the platform and the developers of the platform are different people, and the resource list is organised around both.

Where this platform is the wrong fit

Four mismatches are worth naming before you invest in an evaluation.

The first is scale and shape. Joget is a server platform with a workflow engine, a plugin architecture, a marketplace and a console, backed by Java, Spring and Hibernate. If your problem is a handful of forms and a status field, this is an operating model rather than a tool, and a hosted form builder would be a faster answer.

The second is the licensing model for delivery. A GPLv3 codebase you deploy and modify inside your own organisation is a different proposition from a permissive library, and the paid editions exist to solve exactly that. If the community edition does not carry the features you need, the decision is between a commercial licence and a different platform, and the boundary between editions is not documented in the repository.

The third is the openness of the build. Because the build instructions, the installation guides and the contribution guide are all hosted on external sites, evaluating the source requires following documentation that is updated for the current release rather than pinned to the tree. A team that wants a reproducible, self-contained build from a specific commit will not get that from the repository alone.

The fourth is release discipline. The repository publishes no GitHub releases, so there is no release feed to pin against, and the branch name 9.1-RELEASE is the only version signal visible. The last push was on 2026-10-19, so the code is being worked on, but the absence of tagged releases means you choose a commit and take responsibility for what is in it.

None of these make Joget a bad platform for its audience. They make it a platform where the decision is an organisational one as much as a technical one.

Editorial conclusion

Joget Community Edition fits a team that wants business users to build and maintain their own applications and workflow in a visual editor, and that is willing to run a Java platform with a plugin architecture and an application marketplace in exchange for that. It does not fit a team that wants a small library, or an organisation that cannot carry a GPLv3 codebase in its delivery model. Before you start, decide how you will deploy, because the option list is long and each carries a different operational cost, and check whether the features you need are in the Community Edition, since the Professional, Enterprise and Large Enterprise editions are licensed separately under a commercial EULA. The repository is not archived and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. Issues
2. jogetworkflow/jw-community on GitHub
3. Project website
4. README