Editions and Ecosystem

The figure and the table below summarise the five offerings. They share a lineage: Mage-OS is built from the Open Source code base, and Adobe Commerce is built from it as well and adds licensed features and Adobe services.

Source: Adobe Commerce docs: SaaS and PaaS comparison

Adobe’s documentation marks which product a page is about with badges. A page with the PaaS only badge covers Adobe Commerce on Cloud and on-premises projects and, unless the page says otherwise, self-hosted projects built on the Magento Open Source code base; a page with the SaaS only badge covers Adobe Commerce as a Cloud Service and Adobe Commerce Optimizer projects only. A page without a badge applies to all solutions. Keep this rule in mind when you follow an official link from this subsection, because a feature can be absent from an edition even when its page looks general.

Source: Adobe Commerce docs: Product solutions

Magento Open Source is the code base. It lives in github.com/magento/magento2, its default branch is 2.4-develop, and the project licence is the Open Software License 3.0 (the repository metadata shows OSL-3.0, and the composer.json of tag 2.4.9 declares OSL-3.0 and AFL-3.0). Every -pN release is tagged there, which is how Open Source users get the security patches; see Versions, Lifecycle and Requirements.

What Open Source gives you is the whole commerce engine: catalog, cart, checkout, orders, customers, promotions, the Admin, the frontend themes Blank and Luma, the REST and GraphQL APIs and the module system that the rest of this subsection teaches. What it does not give you, according to Adobe’s documentation, is the following.

The Marketplace keys problem deserves a warning, because it surprises newcomers. The official way to install Open Source is composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition, and that repository asks for Marketplace access keys even though the software is free (the public key is the user name and the private key is the password). This subsection never creates such an account, so it installs through Mage-OS. The Installation page walks through it, and Mage-OS (next section) avoids it.

Source: Adobe Commerce docs: Install with Composer

Adobe Commerce adds licensed features and Adobe’s support on top of the Open Source code base. It comes in two self-managed shapes, which Adobe’s documentation groups together as the PaaS model.

Adobe Commerce on-premises is installed on your own servers or a host you pick, exactly like Open Source, with the magento/project-enterprise-edition Composer project and the same Marketplace access keys. You operate everything and you own the patching. In return you get the extended support tiers, the Upgrade Compatibility Tool, B2B and the out-of-process extension points (events and webhooks).

Adobe Commerce on Cloud is the same software on Adobe-managed, single-tenant cloud infrastructure with a preprovisioned environment. Adobe’s feature comparison page lists, for this model, the following properties:

Cloud has one more property that a self-hosted shop does not: Adobe enforces version and dependency deadlines, with suspension of the Admin or the whole storefront as the consequence. The dates are in the Cloud enforcement section. The only official Docker tooling, magento-cloud-docker, is for Cloud projects too; see Local Development Environments.

Source: Adobe Commerce docs: SaaS and PaaS comparison

Adobe Commerce as a Cloud Service is a different architecture, not a hosting plan. It is multi-tenant, Adobe upgrades it continuously ("versionless"), and Adobe manages the infrastructure. It has four building blocks: the Commerce Storefront (the customer-facing interface), the Merchandising Services (catalog, pricing and inventory services), Product Visuals (digital asset management) and the Developer Platform (core development tools and APIs). Adobe Commerce Optimizer, a separate SaaS project type, is documented next to it and shares the SaaS badge.

The extensibility consequences are large, and they are the reason this page exists. Adobe states that Adobe Commerce as a Cloud Service does not support Luma storefronts, and its feature comparison lists these differences from the PaaS model.

Source: Adobe Commerce docs: SaaS and PaaS comparison and Adobe Commerce docs: Cloud Service overview

The practical rule: almost everything the later pages teach about PHP modules, di.xml, plugins, observers, declarative schema, layouts and phtml templates does not apply to ACCS. What applies to it is the REST and GraphQL APIs page (the APIs themselves), the API Authentication page (Adobe IMS replaces the native tokens on SaaS) and the Out-of-Process Extensibility page. Adobe’s own migration advice for teams moving to SaaS is to move suitable functionality to out-of-process extensibility where possible, reduce the scope that requires a transition, consider API Mesh for extending API functionality, and evaluate industry-specific data model needs against the available extension options.

The Commerce Storefront is documented in the Adobe tools site as built on Edge Delivery Services with Commerce blocks and drop-in components. Its backend options are Adobe Commerce on Cloud or on-premises (through a Storefront Compatibility package), Adobe Commerce as a Cloud Service, and Adobe Commerce Optimizer. All drop-in components require an ACCS or Adobe Commerce Optimizer license; PaaS customers get drop-ins by adding an Adobe Commerce Optimizer license. Open Source is not among the listed backends. The Frontend: Hyvä, PWA Studio and Edge Delivery page covers this storefront in detail.

Source: Adobe Commerce Storefront: Backend options

Adobe’s extensibility page defines the two models and says which one new work should use. In the in-process model, "PHP modules, plugins, observers, and other customizations" run inside the Commerce application process and interact directly with its runtime, services and database. That gives deep control but couples the custom code to the Commerce version, the PHP runtime, internal APIs, the deployment process and the resources of the application. In the out-of-process model the custom logic runs outside Commerce, on Adobe Developer App Builder and its supporting services, and connects through APIs, events, webhooks, SDKs and supported extension points.

Source: Adobe Commerce developer docs: Extensibility

The page adds that the two are not interchangeable implementation details: for new Commerce apps and for modernising existing customisations you should start with App Management and build using the out-of-process model. That is a recommendation, not a prohibition: the words "whenever possible", which you may see quoted, are not on the current page.

Which models an edition allows, and with which tools, is the table that decides what you can build.

Source: Adobe Commerce developer docs: Install Adobe I/O Events and Adobe Commerce developer docs: Webhooks

The two kinds of out-of-process connection differ in how they react to Commerce. Events are asynchronous: Commerce sends a message after something happened (an order was placed) and the app handles it later, so it can never block the shopper. Webhooks are synchronous: Commerce calls the app before it finishes an operation and waits for the answer, which lets the app validate, block or modify the data. On-premises installations generate the webhook plugin module with bin/magento webhooks:generate:module and define webhooks in a module’s etc/webhooks.xml or in app/etc/webhooks.xml, while SaaS has a predefined list of webhooks configured in the Admin or through REST. The Out-of-Process Extensibility page has the full detail.

Adobe’s documentation does not name an edition for the Admin UI SDK or API Mesh beyond listing them as ACCS tools, so this subsection says "documented for Adobe Commerce" rather than inventing support for Open Source.

The decision follows from three questions, which the diagram turns into a path.

Source: Adobe Commerce developer docs: Extensibility

Mage-OS is a community-owned distribution of the Magento Open Source code base. It was founded to give the community a way to improve the platform and to keep businesses built around Open Source healthy; its association is member-owned, without shareholders or investors, according to its website. Its stated focus is performance and usability improvements and the integration of community pull requests that Adobe has not merged for lack of resources, while remaining compatible with Magento solutions and integrations. It publishes its own Composer repository, its own releases and a catalogue of community modules called Mage-OS Lab. This page and its siblings use Mage-OS 3.6.0 as the verification environment because it installs without Adobe Marketplace keys.

The facts below were observed on a local Mage-OS 3.6.0 shop (PHP 8.5.12, MariaDB 11.8.9, OpenSearch 3.9.0, Valkey 9.1.3) and on the project’s website.

Mage-OS describes 3.5.0 as porting Adobe’s hotfix for CVE-2026-75650, which it calls StyleSmuggler, an unauthenticated remote code execution that Adobe reports as exploited in the wild, and it warns that patching alone is not enough: the remediation steps (key rotation) apply as well. That makes the distribution a practical way to get fast fixes without an Adobe license, but it also means you depend on the Mage-OS team for patch timing, not on Adobe.

These commands were run on the local Mage-OS 3.6.0 shop to check the claims above; they only read data.

Source: Mage-OS and Mage-OS Composer repository

The outputs were the CLI banner above, versions : * 3.6.0, two licence lines (OSL-3.0 and AFL-3.0) and a metapackage type, a count of 248 mage-os/* requirements, the replace relationship for magento/framework, 360 packages in vendor/mage-os, and 319 enabled Magento_* modules. The module count is a useful sanity number: the core is a large, modular code base, about 320 modules, which is why the Architecture Overview spends time on modules and areas.

Hyvä Theme is a third-party storefront theme that replaces Luma’s RequireJS, Knockout and LESS stack with Tailwind CSS and Alpine.js. It is the best-known Luma alternative for self-hosted Magento (its vendor reports more than 7,000 stores, a vendor figure). Its licensing changed in November 2025, which affects every older article you will find.

Hyvä was not installed in the verification environment, so none of the commands above were run; the Frontend: Hyvä, PWA Studio and Edge Delivery page covers the theme in more depth.

Source: Hyvä: Hyvä Theme is Now Open Source and Free and Hyvä docs: Getting started

PWA Studio is Adobe’s React-based toolset for building a progressive web app storefront on top of the GraphQL API; its reference storefront is called Venia. The repository’s latest GitHub release at the time of checking is 14.5.1, and neither the repository page nor the developer documentation carries a deprecation or archive notice. The documentation states no support status and no compatibility table either, so "maintained, not deprecated" means only that no notice was found. The npm packages are versioned independently of the GitHub release tag (for example @magento/venia-ui is at 11.7.4 while the release tag is 14.5.1), so do not compare the two numbers.

Any headless storefront, whether PWA Studio, a Next.js shop or Adobe’s Commerce Storefront, talks to Magento through the GraphQL API and the REST API. They remove the Luma theme from the request path and move rendering to a separate application, at the cost of re-implementing features the theme gave you for free. For a first project, Luma or Hyvä on the server-rendered stack is the lower-risk choice.

Source: PWA Studio: Releases and Adobe Commerce developer docs: PWA Studio

Where extensions come from depends on the edition and on the model.

Because any PHP extension can change checkout or the Admin, treat third-party code as part of your attack surface, which the Security page quantifies.

Source: Adobe Commerce docs: SaaS and PaaS comparison

Pocket Coffee is a small specialty-coffee shop with 18 bean variants, a Coffee Club customer group, two shipping zones and Spanish and English storefronts. It needs custom PHP behaviour (a roast date badge on the product page and an "order placed" log line), which rules out ACCS, and its budget does not include an Adobe Commerce license.

So the subsection builds Pocket Coffee on Mage-OS 3.6.0 (Magento 2.4.9) with PHP 8.5, OpenSearch 3 and Valkey 9, with plugins, observers, declarative schema and REST and GraphQL endpoints. Wherever a feature changes on Adobe Commerce, the page says so. A team on Adobe Commerce on Cloud would follow the same pages and add the out-of-process material; a team on ACCS would skip most of the PHP pages and use the API, authentication and out-of-process pages.

Things this page could not run: the Adobe Marketplace and repo.magento.com installs, Adobe Commerce-only features, Adobe I/O Events, webhooks, App Builder, ACCS and Cloud environments (all need Adobe accounts or licences), and Hyvä and PWA Studio installs. Their statements come from the cited Adobe, Hyvä and GitHub pages.