crm-application is the OroCRM sample app, not the product itself

Ten repositories, one product in different boxes

The readme for this repository opens with a question that is really a taxonomy: what is included? The answer is that this sample application includes OroCRM Community Edition without the eCommerce and marketplace modules.

And then it lists the other distributions, which is the most useful thing in the readme. There is crm-enterprise-application for the Enterprise Edition without the eCommerce and marketplace modules. There is a set of OroCommerce Enterprise distributions: the full one, one without CRM modules, one with additional marketplace modules, and the Community Edition. There is orocommerce-application-de and orocommerce-enterprise-application-de, the German-localized versions. There is platform-application, the OroPlatform Community Edition without the eCommerce, CRM and marketplace modules. And there is oromarketplace-application, described as a legacy version, 4.2 compatible, of the Enterprise Edition with additional marketplace modules.

That list is a product decision expressed as a set of repositories. Oro sells the same platform in different boxes, and each box is a separate application distribution with its own composer manifest and its own dependency set, so choosing an edition means choosing a repository rather than ticking a module.

The platform underneath is OroPlatform, and the naming makes the layering visible: platform, then CRM, then the commerce and marketplace modules on top, then localisation as a separate distribution. The topics on the repository list application, crm, customer-retention, orocrm, oroplatform-application, php, symfony and symfony-application, and the repository is a Symfony application throughout.

The audience is a developer or a business evaluating Oro as a self managed CRM. OroCRM is described as open-source and built with flexibility in mind, customizable and extendable to fit any business needs, and the Community Edition is described as a fully functional application which can be used as is or customized to meet your business needs.

What a local OroCRM stack actually needs

The compose file in the repository is the clearest description of what this application expects to run against, and it is a Symfony server stack rather than a CRM specific one.

There is a Postgres service on postgres:18.3, labelled with the Symfony server prefix ORO_DB, with the database credentials as environment variables and a volume for the data directory. A second detail is easy to miss and is worth noting: the compose file mounts config/uuid-ossp.sql into the database entrypoint directory, so the uuid-ossp extension is installed on first initialisation, which is a requirement the schema depends on rather than a nicety. The healthcheck runs pg_isready against the application user and database, with a 40 second start period.

Redis runs on redis:8.4.2-alpine with the ORO_REDIS label, which is the cache and queue layer that a Symfony application of this kind expects.

MailCatcher runs on the schickling/mailcatcher image with ports 1025 and 1080, which is the standard local SMTP catcher. It is labelled ORO_MAILER. In a development environment this is how the application sends mail without sending it to anybody, and it is the kind of detail that tells you the developers run this stack on a laptop rather than in a demo environment.

Gotenberg runs on gotenberg/gotenberg:8.23.2 on port 3000 with a healthcheck against its own health endpoint, labelled ORO_MAILER as well, and Gotenberg is a PDF generation service. That is the document side of a CRM, generating PDFs for quotes, invoices or reports, running as a separate container that the application calls.

So the deployment surface is four services, and none of them is exotic. The interesting question is not what runs but how it is wired, and the Symfony server labels answer it: the compose file is designed to work with the symfony server integration, where the service prefix is how the local tooling recognises the database, the cache and the mailer.

A webpack frontend with a pinned Node and pnpm enforced

The frontend is a webpack build, and the package.json at the root tells you how strict the environment is.

The file carries a warning in its own description field: the file is generated programmatically and all manual changes in the dependencies section will be lost. That is a warning to contributors, since editing the dependency list by hand will be overwritten when the manifest is regenerated from the composer side.

The engines field pins node to >=v24.11.0 and <25, and pnpm to >=v10.7.0. And the preinstall script runs npx only-allow pnpm, which means an install with npm or yarn fails immediately and loudly rather than producing a subtly different tree. The .nvmrc and .php-version files at the root carry the same pins for the other runtimes.

The build scripts are a thin layer over webpack. The build script runs webpack in production mode, the watch script runs webpack in watch mode with progress and logging flags, and there are two narrower targets, build-css and build-js, each skipping the other half of the bundle through an env flag, which is the usual trick for a fast iteration loop when you are only changing styles or only changing scripts. The prewebpack hook runs check-engine, so a wrong Node version is caught before the bundler starts rather than during.

The lint scripts are interesting because they are mostly templates. The lint script itself does not lint anything: it echoes an instruction to configure your own command based on a template that runs eslint and stylelint over a vendor path, and the lint-oro script is the one that actually lints the Oro code, with separate eslint and stylelint invocations against .eslintrc.yml and .stylelintrc.yml, and a stylelint configuration for CSS specifically alongside the one for SCSS. The frontend dependencies are the Oro-maintained forks of a couple of Backbone and Autobahn packages, which is a detail worth knowing if you plan to upgrade them.

Three test layers, one of them behavioural

The repository carries three distinct test configurations, and the mix tells you what the project considers worth testing.

PHPUnit is the unit and integration layer, configured through phpunit.xml.dist. Behat is the behavioural layer, with behat.yml.dist at the root, and Behat is the tool for writing readable scenarios that drive the application the way a user would. And Karma is the JavaScript side, configured through karma.conf.js.dist, which is the standard runner for browser tests and the one wired into the pnpm test script.

The scripts reflect that split. The test script runs the watch variant with a single run flag, and the test-watch script runs check-engine and then karma start with the dist configuration. The check-engine call in front of karma is the same guard as in the webpack scripts, so the Node version requirement is enforced consistently across the build and the test run.

There is also a pdepend.xml.dist, which is a PHP dependency analysis configuration, and a 3rd-party-dependencies.md at the root documenting what the frontend pulls in. For a project of this size, where the frontend and the PHP application are separate build systems with separate lock files, that file is how a reviewer answers the question of what is actually being shipped to the browser.

The layering is the point: unit tests for the domain, Behat for the behaviour a user depends on, and Karma for the client. A team picking this up inherits the testing strategy as well as the application, which is the bigger inheritance.

OSL-3.0, an upgrade guide, and the shape of the licence question

The licence section is short. The project is under OSL-3.0, with the file linked as LICENSE and the copyright attributed to Oro Inc. for 2024, and the licence in the repository metadata is described as a custom one that GitHub cannot classify, which is what happens with a licence that is not one of the SPDX identifiers GitHub recognises.

OSL-3.0 is a copyleft licence, and the practical consequence for a team evaluating it is that if you modify the application and distribute it, your modifications carry obligations, and if you run it as a hosted service the terms on network use are worth reading carefully rather than assuming. This is not a legal opinion, and the file itself is the place to read the terms. The important structural point is that the community edition and the enterprise edition are not the same licence, and an evaluation that stops at the community edition does not answer the question for the edition you would actually deploy.

The upgrade path is documented in the repository as well. There is an UPGRADE.md at the root alongside a CHANGELOG.md, and the version numbers tell the story of a maintained major line. The releases listed are 7.0.3 on 2026-06-17, 7.0.2 on 2026-05-28 and 7.0.4 on 2026-08-17, with the repository pushed to on 2026-10-13.

So the maintenance picture is a project on a 7.x line with patch releases every few weeks, a documented upgrade file, and a repository that is not archived.

Where this repository is the wrong starting point

There are three cases where picking this repository is a mistake, and they are worth naming because the readme does not.

The first is when you want a CRM that works this afternoon. The Installation section does not contain instructions at all. It points at the online Installation Guide for the CRM CE and at the online system requirements page, which means the setup knowledge is in a documentation site rather than in the repository, and the repository is the code, not the process. If you are evaluating whether the product works, you are going to spend your time in the documentation.

The second is when you want the commerce or marketplace side. This distribution explicitly excludes the eCommerce and marketplace modules, so a business that needs a catalogue, an order pipeline and a B2B storefront is looking at the OroCommerce distributions, which are different repositories with their own module sets and their own licence terms.

The third is when the licensing question is the blocker. If your process needs a standard permissive licence with no copyleft obligation on modification and no question about offering source over a network, then OSL-3.0 is the wrong starting point and the conversation to have is with the vendor about the enterprise edition rather than with the community build.

What the community edition is good for is exactly what the readme says: a fully functional application you can use as is or customise, that you can read in full, that you can extend in PHP and JavaScript, and that you can run on infrastructure you control, with the data in your own Postgres and the mail never leaving your network.

Editorial conclusion

crm-application is worth adopting if you want to run or extend a full CRM on Symfony and you prefer a self assembled application over a hosted SaaS, because the edition split is explicit and the local stack is reproducible from the compose file. It is the wrong choice if you want a turnkey CRM this afternoon, since the installation guide lives in the online documentation and the assembly is manual, and it is the wrong choice if your legal process expects a standard permissive licence, because the project uses OSL-3.0. Before you start, read the Installation Guide for the CRM CE and the system requirements page, decide which distribution you actually want, since the enterprise and OroCommerce variants are separate repositories, and note that the current release is 7.0.4 from 2026-08-17 with the repository pushed to on 2026-10-13.

Frequently asked questions

Official sources

1. Issues
2. oroinc/crm-application on GitHub
3. Project website
4. README
5. Releases