OroPlatform is a Symfony business application platform, not an app

What the platform gives a business application

OroPlatform is described as a PHP Business Application Platform, a BAP, designed to make the development of custom business applications easier and faster. It is built on the Symfony full stack web framework, and the README says it offers unlimited flexibility, high quality code and powerful features.

The features are listed, and the list is the clearest statement of what the platform is for. The user interface is intuitive and based on layouts and themes. There is advanced navigation and menu management, which is the kind of thing every internal application needs and none enjoys building. Configuration is multi layer, so an application, a bundle and a tenant can each contribute settings. There is an entity and entity fields manager, which is a user interface for the data model. Users, roles and multi scope permissions management covers access control. The REST API supports the JSON:API standard, and there are reports, workflows, data audit and many other features.

Read together, those are the parts of an enterprise application that a framework cannot infer from your domain. A team building a custom intranet, a back office or a vertical SaaS product would otherwise assemble the same set of components, and the platform's argument is that it has already assembled them and made them work together.

The relation to the other Oro products is stated too: OroPlatform is a good starting point for any kind of business application, from custom intranet apps to modern open source solutions like OroCRM and OroCommerce.

It is a package, and an application has to surround it

The installation section is short and it contains the most important operational fact about the project: OroPlatform is a Composer package that requires an application to initialise and run it.

That is a different shape from a Symfony application you clone and run. The platform provides the framework, the admin features and the extension points, and something else has to provide the application: the entry point, the configuration, the bundles to load and the database migrations for your own entities.

The README points at platform-application on GitHub as an example of such an application, and says that it simplifies initial project setup and configuration. So the intended path is to start from that skeleton, compose your own bundles into it, and treat the platform as a library.

That choice has consequences for a team evaluating the project. There is no single command that gives you a running Oro installation, and there is no admin account waiting for you. The work is in the composition, which is also where the flexibility comes from. A team that expected a turnkey business application should look at OroCRM or OroCommerce instead, since those are the products built on top of this platform.

The incompatibilities files are the real documentation

The root of the repository contains an unusual artefact: fourteen files named incompatibilities, one for each version transition the project has been through. The list runs incompatibilities-2-1.md, 2-2, 2-5, 2-6, 3-0, 3-1, 4-0, 4-1, 4-2, 5-0, 5-1, 6-0-rc, 6-0 and 6-1.

Two things are notable. First, the naming convention records the target version of each upgrade, so a reader looking at a migration from 4.2 to 5.0 opens incompatibilities-5-0.md and gets the list of things that changed. Second, the set of files covers major and minor versions alike, which means the project takes small upgrades seriously enough to document them individually.

For a platform this is the correct investment. A library that changes its API on every major release leaves its users to discover the breakage at runtime, while a platform that ships a document per version lets a team read the cost of an upgrade before scheduling it. The presence of the 6-0-rc file also shows the practice extends to release candidates, so an early adopter can read what is coming before it lands.

The CHANGELOG.md at the root is the chronological companion to these files, and the two together are the material you would actually read before touching a version pin.

The release list and the branch tell different stories

The published releases shown for this repository are v4.1.0-rc2 dated 2019-12-17, v2.0.6 dated 2017-04-14 and v2.0.5 dated the same day.

That list does not describe the current state of the code, and the repository says otherwise in two ways. The incompatibility files run through version 6.1, so the project has been developed well past 4.1. And the last push to the repository was on 2026-10-15, which is years after the newest release in that list.

The most likely reading is that the platform is released as part of the products built on it, OroCRM and OroCommerce, and that the tags visible on this repository are not the whole story. But a reader who is deciding what to install cannot infer that, and the practical advice is to look at the version the documentation site and the application skeleton point at rather than at the tag list here.

The same caution applies to a dependency constraint in your composer.json. Pinning to a tag you found in this list is a decision about a 2019 build of a platform whose own tree describes 6.1 work.

What the repository root tells you about the build

The supporting files describe a mature PHP project with a conventional layout.

There is a composer.json at the root along with dev.json and dev.lock, which is the common Composer pattern for keeping development-only dependencies out of the production install. The build/ directory holds the build configuration, bin/ holds the console entry points, and src/ is the source of the platform itself.

Testing is set up with phpunit.xml.dist and bootstrap_test.php, and the continuous integration setup is Travis, with .travis.yml at the root and travis.php.ini next to it, plus a phpunit.xml.dist that points at the test suite. Travis is not a current choice, and the same file also shows the project carries a security.md, so security reporting has a defined path inside the repository as well as in the documentation.

The .github/ directory is present, so there is GitHub configuration alongside the older Travis setup. A project that keeps both is one that has migrated rather than started fresh, which is consistent with a codebase whose version history spans the 2.x releases.

The licence, the documentation, and how to get help

The licence is MIT, with the LICENSE file at the repository root, which is the permissive end of the spectrum and is a reasonable choice for a platform that commercial products are built on.

The documentation is not in the repository. The Resources section points at the OroCommerce, OroCRM and OroPlatform documentation at doc.oroinc.com, and separately at a contributing guide and at a page for reporting a security issue. The README itself is short and largely navigational, which is what you would expect from a platform whose documentation is a site rather than a file.

The security angle deserves a mention because a platform holds a lot of state: users, roles, permissions, entities and workflow definitions. Having both a security.md in the repository and a documented reporting process means a vulnerability in the platform is expected to be reported privately rather than through a public issue, and the documentation gives that process a home.

The project also lists its intended audience indirectly through the two products it underpins. If your requirement is a customer relationship management system or a commerce backend, using OroCRM or OroCommerce directly is less work than assembling the platform yourself, and the platform becomes relevant when you need behaviour neither product covers.

Editorial conclusion

OroPlatform fits a team building a custom internal business application and wanting the parts that are tedious to assemble, namely entities and their fields, users and roles with multi scope permissions, navigation and menus, workflows and a JSON:API REST layer, already integrated with a Symfony stack. It does not fit a project that wants a small dependency, since this is a platform with an application around it, and it does not fit a team unwilling to read the upgrade notes. Before adopting it, work through the incompatibilities file for the version you would move to, start from the platform-application example rather than a blank project, and check which of the two products on top of it, OroCRM or OroCommerce, already does what you are about to build.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. oroinc/platform on GitHub
4. README
5. Releases