Adobe Commerce as a Cloud Service is Adobe's software-as-a-service (SaaS) edition of Adobe Commerce. Adobe runs the infrastructure and applies updates automatically, the storefront is headless and delivered through Edge Delivery Services, and you customize it only from the outside, through APIs, events, API Mesh and App Builder apps, instead of installing PHP modules into the core. For merchants that means less upgrade work; for developers it means a different way of building.
This guide compares the three ways to run Adobe Commerce today, explains what moves to the "out-of-process" model, and gives you a simple test for whether your current store is a good fit.
Three ways to run Adobe Commerce
Adobe now groups its offerings into two models. "PaaS" covers the long-standing application you can run yourself (on-premises or with any host) or on Adobe Commerce on Cloud infrastructure. "SaaS" is Adobe Commerce as a Cloud Service, sometimes shortened to ACCS. Magento Open Source sits outside both: it is the free codebase you host and support yourself.
The table below is built from Adobe's own feature comparison and overview pages, checked in November 2026. Details change release by release, so treat it as a map, not a contract.
| Area | On-premises (self-hosted) | Adobe Commerce on Cloud (PaaS) | Cloud Service (SaaS) |
|---|---|---|---|
| Who runs the servers | You or your host | Adobe-managed, single-tenant | Adobe, multi-tenant, auto-scaling across the stack |
| Upgrades and patches | You apply them | You apply them (Adobe ships the releases) | Applied by Adobe in a "versionless" model, with a 30-day sandbox preview window |
| Customization model | In-process PHP modules plus APIs | In-process PHP plus out-of-process (App Builder recommended) | Out-of-process only: APIs, events, webhooks, App Builder |
| Languages your team writes | PHP, XML, JS, CSS | PHP, XML, JS, CSS | JS, Node, HTML, CSS |
| Storefront | Luma, Hyvä, Breeze, headless | Luma, Hyvä, Breeze, headless | Commerce Storefront on Edge Delivery Services (Luma not supported) |
| CDN | Your choice | Fastly included | Managed edge CDN; bring-your-own CDN supported |
| Extensions | PHP extensions from Commerce Marketplace | PHP extensions plus App Builder apps | App Builder apps from Adobe Exchange |
| Data model changes | Full control | Full control | Custom attributes on core and B2B entities |
| Monitoring | Your tooling | New Relic access included | Adobe managed; OpenTelemetry for App Builder apps, RUM for the storefront |
Two more lines from Adobe's comparison matter for planning. Search index customization on the SaaS edition "requires third-party solutions", and custom email types are limited to the standard templates. If either of those is central to your store, check the current comparison page before you commit.
What changes for merchants
No more upgrade projects
On PaaS, every minor release and security patch is a project: test, fix extensions, deploy. Adobe's comparison notes six patch releases and one minor release a year for PaaS. On the Cloud Service, Adobe updates the application for you. You get an in-app notice and a 30-day window to evaluate changes in a sandbox before production updates apply. That is the biggest single reason merchants look at SaaS.
Services come bundled
The Cloud Service includes Commerce Storefront, Merchandising Services (catalog, pricing, inventory), Product Visuals for digital assets, Live Search, Product Recommendations, Payment Services and the developer platform. On PaaS, several of these are optional services you connect yourself.
Less control over the core
The trade-off is control. You can no longer hook into almost any PHP method, rewrite a core class or add your own database tables. Content management moves from CMS pages and Page Builder to document-based authoring and Storefront Builder. B2B features come pre-installed, but deeply bespoke B2B logic has to be rebuilt against the extension points Adobe exposes.
Different compliance coverage
Adobe lists SOC 2, PCI, ISO and GDPR for the Cloud Service and notes HIPAA is not currently available there. If you sell regulated products, confirm the current list with Adobe for your contract.
What changes for developers
The skill set shifts from Magento PHP to JavaScript and Node.js running on Adobe's developer platform.
- App Builder replaces most custom modules. Business logic runs as serverless actions that react to Commerce events or webhooks. Our Adobe App Builder guide covers how those apps are structured.
- API Mesh is how you extend the GraphQL API, combining Commerce with ERP, PIM or CMS sources behind one endpoint. See API Mesh for Adobe Commerce for patterns and limits.
- Events and webhooks come from a predefined list that Adobe extends over time. If the hook you need does not exist yet, the requirement waits or is redesigned.
- Admin UI SDK lets you add Admin menus, pages and grid columns without PHP.
- Storefront work means Edge Delivery Services blocks and drop-in components, not Luma templates. Teams with React or Next.js experience usually adapt faster than teams who only know Luma.
The upside is that this work survives upgrades. Adobe states that updates are backward compatible for code that follows the API-first extensibility model, which is exactly the guarantee in-process PHP never had.
How customizations map across
When teams assess a move from PaaS to SaaS, each customization usually lands in one of four buckets:
| Current customization | Typical Cloud Service route | Effort signal |
|---|---|---|
| Integration with ERP, PIM, OMS via cron or observers | Events plus App Builder actions | Moderate: logic is rewritten, behavior stays |
| Custom GraphQL resolvers | API Mesh custom resolvers | Moderate |
| Checkout or pricing rules in PHP plugins | Webhooks, native features or rethink | High if the hook is not exposed |
| Admin screens and grids | Admin UI SDK | Low to moderate |
| Custom tables and entities | Custom attributes or external storage via App Builder | High |
| Luma or Hyvä theme | Rebuild on Commerce Storefront | High: a new frontend project |
| Third-party PHP extensions | App Builder equivalent, native feature, or drop | Varies by vendor |
Adobe provides assessment tooling that flags code needing refactoring and maps legacy features to native equivalents. Use its output as a starting inventory, then have a developer read the code that matters most: checkout, pricing and integrations.
Is the Cloud Service a fit? A quick test
Answer these honestly. The more "yes" answers in the first list, the better the fit.
Signs SaaS will suit you
- Upgrades and patching consume a large share of your development budget.
- Your customizations are mainly integrations and Admin tweaks, not core rewrites.
- You plan a new storefront anyway, or want a headless one.
- You already use, or want, Live Search, Product Recommendations and Payment Services.
- Your team is comfortable with JavaScript, Node.js and serverless patterns.
Signs to stay on PaaS for now
- You depend on deep checkout, pricing or tax logic in PHP plugins.
- Your catalog or B2B model needs custom database entities.
- You rely on PHP extensions with no App Builder equivalent.
- You need HIPAA coverage or a hosting region not yet confirmed for SaaS.
- You recently invested in a Hyvä or Luma frontend and want to recover that cost first.
Adobe has said it continues to support Adobe Commerce on PaaS and has not announced an end-of-life date for it, so staying is a valid choice. If you stay, keep your release on a supported line; 2.4.9, released May 12, 2026, has standard support until May 31, 2029.
Frequently asked questions
Is Adobe Commerce as a Cloud Service the same as Adobe Commerce on Cloud?
No. Adobe Commerce on Cloud infrastructure is the PaaS edition: Adobe hosts it, but you own upgrades and can install PHP code. The Cloud Service is SaaS: Adobe owns upgrades and you extend it only through APIs and App Builder.
Can I install Magento extensions on the Cloud Service?
Not PHP extensions. Adobe's comparison lists App Builder apps from Adobe Exchange as the marketplace for the SaaS edition. Many vendors are building App Builder versions; check each one you depend on.
Can I keep my Hyvä or Luma theme?
Adobe states that the Cloud Service does not support Luma storefronts. The storefront is Commerce Storefront on Edge Delivery Services, so plan a frontend rebuild as part of any move.
Does it cost more?
Adobe licenses both editions by quote, so there is no public price to compare. Compare total cost: licence, hosting, the upgrade work you stop doing, and the rebuild work you take on.
Where to go from here
Whether you move to SaaS or stay on PaaS, the decision rests on an honest inventory of your customizations. Mistri's Adobe Commerce development team can run that assessment, rebuild integrations as App Builder apps, and plan a headless Adobe Commerce storefront. If you stay on PaaS, our Magento extension development work keeps custom modules clean enough to move later.
Sources
Adobe Commerce as a Cloud Service overview (Adobe Experience League); Feature comparison: Cloud Service vs PaaS (Adobe Experience League); Adobe Commerce system requirements (Adobe Experience League).


