OCM Labs Extensions: Composer Install, Private Packagist Licensing, and Updates Explained

Before anyone puts third-party code on a production Magento store, the questions are the same, and they are the right questions. How does it install? What happens at upgrade time? What exactly am I licensed to do, and what happens if I stop paying or want the code gone? Here is how all of that works for OCM Labs modules, plainly, including the parts that are gated and the parts that are not.

OCM Labs is the extension brand of Orange Collar Media. We are a Magento agency first; the modules exist because we kept building the same things for clients. They are sold directly from our store, and every module's documentation is public, so you can read exactly what you are buying before spending anything.

How does buying an OCM Labs extension work?

You buy the module on our store, your purchase grants Composer access to the OCM Labs Packagist repository, and you install with composer require like any other dependency. For our commercial modules there is no zip file to shuffle around and no license key pasted into the admin: access to the private Packagist repository is the licensing mechanism, and updates arrive through the same channel via composer update.

Concretely, for the Extra Fees module that means adding our repository and your access credentials to your project's Composer configuration, then:

composer require ocmlabs/module-extra-fees
bin/magento module:enable OCMLabs_ExtraFees
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

Standard Magento module lifecycle, nothing exotic. The one step people skip is setup:static-content:deploy, and for Extra Fees specifically it matters: the admin condition builder and the checkout components are deployed static assets, and skipping the deploy leaves them missing or stale on a production-mode store. The full walkthrough, including the Hyva companion package and ACL setup, is in the Extra Fees installation docs.

Which modules are gated and which are public?

Two of the five modules are commercial-gated: Extra Fees and Webhooks require the Packagist access that comes with purchase. The other three install from public Packagist with no credentials, per our own docs. We would rather state that plainly than let you discover it mid-evaluation.

Compatibility varies a little by module, so check the docs frontmatter for the one you are installing: Extra Fees and Support Tickets target Magento 2.4.7 to 2.4.8 on PHP 8.3+, FAQ reaches back to 2.4.6, Webhooks runs PHP 8.2 to 8.4, and WordPress Integration wants 2.4.8+ on PHP 8.1+. All five support Luma and Hyva, with Hyva handled through separate companion packages where needed, such as ocmlabs/module-extra-fees-hyva.

What about Adobe Commerce?

Commerce editions are handled with Composer metapackages rather than separate codebases. For Extra Fees, Adobe Commerce stores run composer require ocmlabs/module-extra-fees-commerce, a metapackage that licenses the module for Adobe Commerce at $500 and pulls in the core ocmlabs/module-extra-fees package automatically; every following bin/magento step is identical. The FAQ module uses the same pattern with ocmlabs/module-faq-commerce. You pick the edition on the product page at checkout, and Composer enforces the rest.

How do updates work?

The same way updates work for every other Composer dependency in your project, which is the point:

composer update ocmlabs/module-extra-fees
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

Each module keeps a public changelog in its docs, the Extra Fees changelog for example, so you can read what a version changes before pulling it into a deploy. Because the modules resolve through Composer with normal version constraints, they fit an existing CI pipeline without special handling: your composer.lock pins the version, staging gets the update first, and production gets what staging tested.

What if you want it gone?

An uninstall story is part of the trust question, so here is the one we can state precisely, for Extra Fees: bin/magento module:uninstall OCMLabs_ExtraFees --remove-data is a clean uninstall that drops the module's five tables, every column it added to core sales tables, and its configuration rows. A plain module:disable leaves all data in place, which is what you want when you are only testing. No orphaned tables to find two years later during a migration.

Why direct sales and Composer, not a marketplace?

These modules are sold directly from our store rather than through a marketplace, and distribution is Composer because that is how we install things on our own client stores. The practical consequences for you: the docs are public before purchase, the install path is identical to the rest of your dependency tree, and the people answering questions about the module are the people who wrote it and run it in production for clients.

If you are weighing whether to buy an extension at all versus building in-house, we made the case for both sides with working code in custom code vs extension for Magento 2 fees, and showed the lifecycle problems an extension is really buying you out of in checkout fees through tax, invoices, and refunds. The full catalog lives on the Magento extensions page.