Apache OFBiz bundles an ERP suite on top of its own Java web framework

An ERP product that also contains the framework it runs on

Apache OFBiz is described as an open source product for the automation of enterprise processes, and it is unusual in a way that matters for anyone evaluating it. The framework components and the business applications live in the same project. The repository description names ERP, CRM, e-business and e-commerce, supply chain management and manufacturing resource planning as the application areas, and the README describes the result as a foundation and starting point for enterprise solutions.

The technical shape of that foundation is a large set of libraries, entities and services. Entities are the data model, services are the business operations, and both are described as part of a Java codebase that the project calls a top level Apache software project. The topic tags on the repository confirm the breadth: content, database, geospatial, network-server, web-framework, plugins, xml, groovy, javascript and https.

So the audience splits in two. One group wants the applications, the order management back office, the accounting back office, the e-commerce front end, and expects them to be configurable rather than rewritten. The other group wants the underlying web framework and is prepared to spend months learning its conventions before writing a screen.

The second group is the one that is often surprised, because the applications are what draw people in and the framework is what they end up fighting.

The repository layout is the architecture, and it has changed

The top level directory list explains how the system is arranged. framework/ and applications/ are the two halves, with buildSrc/ holding build logic, themes/ holding presentation, config/ holding configuration, runtime/ for runtime material, lib/ for libraries, spotbugs/ for static analysis and test-reports.gradle for test output. The Gradle files sit next to them: build.gradle, settings.gradle, dependencies.gradle, common.gradle, gradle.properties and the gradle/ directory with the wrapper.

Several files exist to support the plugin model rather than the application itself. pullPluginSource.sh and pullAllPluginsSource.sh, along with their .bat counterparts, fetch plugin sources, and setup-worktree-plugins.sh does the same for a git worktree. The presence of these scripts tells you that plugins are a first class extension point, not an afterthought, and that the framework expects to be extended by pulling in separate component directories.

There is a warning about this layout. The README states that the directory structure and repositories have changed, and directs readers to a section on repository and directory structure for details. That is a signal worth heeding: upgrading across a structural change is not a matter of swapping a jar, and the documentation itself flags that as a known rough edge rather than something it hides.

Quick start runs entirely through the Gradle wrapper

The quick start is a three command sequence from the top level directory, and the first command exists because the repository does not ship a usable wrapper until it is initialised. On a Unix-like system that is the init script.

./gradle/init-gradle-wrapper.sh

On Windows the equivalent command is init-gradle-wrapper, run in PowerShell. The README warns about a specific failure here, a message that Powershell is not recognized as an internal or external command, and points to an Apache short link for the fix, with a note about the PowerShell execution policy and setting it to unrestricted so the script can prompt once.

With the wrapper in place, the next step prepares the system and loads the data.

./gradlew cleanAll loadAll

The Windows form is gradlew cleanAll loadAll. Two things to understand before running it. The command deletes all previous data and resets the system to the initial demo data, so it is not a migration tool and must not be pointed at anything you care about. And on a first run it has to download every dependency, so the documentation asks you to be patient on a slow connection.

The system requirements are narrow: JDK 17, the full JDK rather than the JRE, with $JAVA_HOME set. On Windows, PowerShell 7.1.3 or newer is needed, and OFBiz must not be installed under a path that contains spaces.

Starting the server and reaching the back office on port 8443

The server starts with the ofbiz task.

./gradlew ofbiz

The Windows equivalent is gradlew ofbiz. One detail in the documentation stops people from panicking: the progress indicator does not finish while OFBiz is running, so an apparently stuck percentage is the normal state, not a hang.

Three interfaces are then reachable over HTTPS on port 8443. The order back office is at https://localhost:8443/ordermgr, the accounting back office at https://localhost:8443/accounting, and the administrator interface at https://localhost:8443/webtools. The credential for a fresh installation is the user admin with the password ofbiz, and it is stated plainly in the quick start.

That default credential is the first thing to change and the first thing to argue about in a review. It is documented, which is honest, and it is a fresh install default, which is also the exact case where a deployment gets exposed. The webtools administrator interface in particular is not something you want reachable with a published password.

The quick start also lists three configuration paths that the README flags for people who need them: the Eclipse project setup, the external database section for MySQL or PostgreSQL, and the section on running Gradle tasks without an internet connection for air gapped environments.

Deployment configuration is tied to the source tree, which is why Docker exists

The production setup section states a limitation outright: deployment configuration is currently tied to the source code, and the project recommends Docker if you want to separate deployment configuration from production code.

That is the honest framing of the trade-off. In a conventional ERP deployment you would expect configuration to sit outside the artefact, so the same build can be promoted from a test environment to production by changing files. Here, the documented remedy is to containerise the whole thing rather than to externalise the configuration, which moves the problem rather than removing it.

The repository supports that path. It contains a Dockerfile, a DOCKER.adoc, a docker/ directory and a .devcontainer/ directory, and the README links to the trunk Docker documentation for the full instructions. The Dockerfile itself pins its base image by digest, using eclipse-temurin:17 with a long sha256 value, installs git because OFBiz build tasks need it, and initialises the Gradle wrapper during the build so the distribution is fetched at image build time. It then copies the source directories in one at a time, buildSrc/, applications/, config/, framework/ and the rest, and uses a locked cache mount for the Gradle home directory to avoid re-downloading dependencies between builds.

Pinning the base image by digest rather than by tag is worth copying into your own images, because it is the difference between a reproducible build and a build that changes under you.

Security signals in CI rather than in a promise

The project publishes several automated signals in the README, and they describe a different posture from a typical application repository. There is a Java CI with Gradle workflow, a CodeQL analysis workflow, and an OpenSSF scorecard workflow, plus an OpenSSF best practices badge for the project. There is a services health badge, and a separate Apache CI badge that covers the trunk framework and plugins builds.

The CodeQL badge carries a maintainer note in the file itself explaining that a failing CodeQL workflow has to be deleted so the badge does not stick on a failure, and the Apache CI badge note explains that all branches handled by the Apache infrastructure scripts need to pass for the badge to stay accurate. Those comments are a small window into how the project manages its own indicators, and they are worth reading if you are planning to replicate the setup.

Security policy and legal files sit alongside them. The tree contains a SECURITY.md for reporting issues, a NOTICE file, a LICENSE file, an APACHE2_HEADER used for source headers, a CONTRIBUTING.md, an INSTALL file, a VERSION file, an OPTIONAL_LIBRARIES file listing optional dependencies, and OFBiz-Online-Documentation.adoc for the online documentation. The presence of APACHE2_HEADER and a pre-commit configuration at .pre-commit-config.yaml suggests header checks are enforced mechanically rather than by review.

When OFBiz is the wrong tool

There are three clear cases where this project does not fit, and it is better to name them than to describe the feature list.

The first is a service that is not an ERP. OFBiz ships an entire business application suite, with order management, accounting, an e-commerce front end and manufacturing planning. If you need a REST API for a narrow domain and nothing else, the size of the thing you are adopting is the dominant cost, and the configuration work is real.

The second is a team that wants a small, familiar web framework. The framework in OFBiz is tied to its entity engine, its service layer, its screen definitions, its themes and its plugin loader. You cannot lift the web layer out and leave the rest behind, because the applications and the framework are the same tree, so adopting the framework means adopting the ERP conventions with it.

The third is a deployment where configuration must live outside the source, or where the build must be reproducible without a full Gradle dependency download. The project itself points at Docker for the first case, and the quick start says a first run has to download all dependencies, which is awkward in a locked down build environment. The README also notes a separate section on running Gradle tasks without an internet connection, and a caution that users in China may hit network or proxy issues, which it says is unrelated to OFBiz itself.

Trunk development, no GitHub releases, Apache-2.0 licence

The repository has no GitHub releases. The default branch is trunk, the version badge points at the trunk branch, and the VERSION file at the top level holds the version string. That combination tells you the model: you follow the trunk branch, or you take a tagged download from the Apache site, and the git repository itself is not the place where versioned artefacts are published.

The repository is not archived, and the last push was on 2026-10-19, so trunk is moving. Apache projects of this kind usually run their release cadence through the Foundation's own infrastructure rather than GitHub releases, and the presence of the ci2.apache.org badge for the trunk framework and plugins builds fits that pattern.

The licence is Apache-2.0, which is the permissive Apache licence including the patent grant, and the NOTICE file means downstream distribution has obligations around attribution. The README links the licence text and the project documentation page, and the Licence badge points at the same licence file.

For a team planning a long lived deployment, the practical upgrade question is where the released artefacts live and how the trunk branch relates to them, and the answer is on the Apache site rather than in this repository's release list, which is empty.

Editorial conclusion

Apache OFBiz is the right choice for a team that wants a full business application suite already built on a framework it can extend, and the wrong one for a team that only needs a web framework or a light API service. Verify three things before you commit: that JDK 17 and the Gradle wrapper steps work in your environment, that the cleanAll loadAll task is acceptable for your data since it resets to demo data, and whether your deployment needs the Docker path, because the project states that deployment configuration is tied to the source tree.

Frequently asked questions

Official sources

1. apache/ofbiz-framework on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README