Adobe headless commerce starts with the backend, not the storefront

Adobe headless commerce used to be a frontend question. Today it's a backend and licensing question that happens to produce a frontend. The architecture itself is old news: Adobe Commerce runs catalog, pricing, cart, checkout and orders, and a separate storefront talks to it over GraphQL and REST APIs. What changed is everything around it. Adobe now ships a default headless storefront, a SaaS backend, and a license rule that decides which of its prebuilt storefront components (Adobe calls them drop-ins) you can use.

So the order of decisions matters more than the framework. Pick the backend first, the storefront second and the framework last. Teams that open with "React or Vue?" can find out in sprint three that the components they planned around aren't covered by their license. This piece is written for ecommerce, IT and digital leaders who run Adobe Commerce or are weighing it, and it argues for that order.

Start with the backend, because it decides your storefront

Adobe Commerce now comes in three shapes, and each one opens or closes a different set of headless options.

The line that reshapes most plans sits in Adobe's backend guide. It reads: "All drop-in components require an Adobe Commerce as a Cloud Service or Adobe Commerce Optimizer license."

For a self-managed PaaS store, that one sentence turns into a checklist:

• An Adobe Commerce Optimizer license on top of your Adobe Commerce license.
• Adobe Commerce 2.4.8 or later.
• The Storefront Compatibility package (plus the B2B package for B2B stores), with the Services Connector and Catalog Service set up by hand.
• No Magento Open Source. It isn't supported on this storefront path.

On Adobe Commerce as a Cloud Service or Adobe Commerce Optimizer, the storefront is included and setup is automated. Settle this in procurement. It's a contract question, and discovering it mid-build costs far more than asking early.

Adobe Commerce as a Cloud Service is the SaaS option. Adobe says you get new features "without the need for manual upgrades," and each update gives you a 30-day window to test in a sandbox before it reaches production. Its storefront is "fully headless with a decoupled architecture," and Luma storefronts aren't supported at all. Adobe Commerce Optimizer suits a different buyer: one who wants to keep the existing commerce backend and rebuild only the storefront. It ingests catalog data from third-party sources and layers merchandising and the Edge Delivery Services storefront on top.

Staying on PaaS has its own homework. The current release is Adobe Commerce 2.4.9, generally available since May 12, 2026, with regular support through May 31, 2029. Version 2.4.8 is supported through May 31, 2028, and 2.4.10-alpha1 arrived on October 13, 2026 (Adobe release schedule). Version 2.4.9 requires PHP 8.5, and Adobe asks you to move to MariaDB 12.3 first (system requirements). If you're on an older line, that upgrade belongs in the budget before any headless rebuild sits on top of it.

How Adobe Commerce architecture works for headless commerce

In a traditional setup, the Luma theme or a theme like Hyvä renders pages inside the Adobe Commerce application. Template changes and checkout logic ship in the same release. A headless build cuts that tie. One backend can feed a web store, native apps and in-store screens with the same product data and fulfillment rules, while each frontend ships on its own schedule.

Adobe's implementation playbook notes that Adobe Commerce "has always allowed for headless deployments with REST APIs," and it recommends GraphQL for new headless builds. The benefit Adobe names is upgrade freedom: the core platform "can be easily upgraded without impact to the frontend touchpoints" (Adobe, headless benefits).

A working stack has five layers.

On Adobe's default path, the storefront architecture guide describes three tiers. Merchants author pages as documents. Edge Delivery Services turns those documents into HTML and publishes them through Adobe's delivery network. Drop-in components then call the Commerce APIs for live data such as prices and carts.

The org chart changes along with the code. Marketing owns pages, frontend engineers own components, and the commerce team owns business rules. In practice, that separation is what ends the standoff where a landing page waits on a checkout release.

Adobe headless commerce features worth planning around

Adobe's feature list is long. Four parts of it change how a build is scoped.

The first is the API surface. The Adobe Commerce GraphQL API lets a frontend request only the fields a page shows, which keeps product and cart calls small. Adobe publishes separate schemas for core commerce and B2B, Catalog Service, Live Search and Recommendations. REST is still there too, and the playbook calls it powerful for bulk work such as catalog imports and ERP syncs.

Second, the hosted commerce services. Catalog Service, Live Search and Product Recommendations run on Adobe's side and return catalog data faster than core GraphQL alone, per the storefront architecture guide. Plan for one wrinkle. Stores on Adobe Commerce Optimizer use the Merchandising Services GraphQL API instead of the Catalog Service API (Adobe, Catalog Service guide).

Third, the drop-ins themselves. They're npm packages that give you working storefront features. As of October 2026, Adobe's drop-in catalog lists 11 B2C components and 6 B2B components:

• B2C: Cart, Checkout, Order, Payment Services, Personalization, Product Details, Product Discovery, Recommendations, User Account, User Authentication and Wishlist.
• B2B: Company Management, Company Switcher, Purchase Order, Quote Management, Quick Order and Requisition List.

B2B sellers should read that second line twice. Quotes, purchase orders and company accounts were historically among the costliest pieces of a custom frontend. Now they arrive as packages, as long as your license covers them.

Fourth, extensibility outside the core. API Mesh for Adobe Developer App Builder merges several data sources into one GraphQL endpoint. A storefront can then pull Adobe Commerce data, an ERP stock feed and a review service in a single call, behind gateway-level WAF and DDoS protection. Adobe Commerce also supports out-of-process extensibility, where custom logic runs as separate App Builder apps connected through APIs, events and webhooks. For the detail, see Adobe App Builder: what it is and how it extends Adobe Commerce.

Four storefront options, from least to most you'll own

These options can be combined, as Adobe's playbook points out. Most teams still pick one as the main head.

The Edge Delivery Services storefront is the path Adobe's documentation leads with. You start from the Commerce boilerplate, add drop-ins as Commerce blocks and publish through Edge Delivery Services. A push to GitHub triggers the build and publish, so there are no storefront servers to run (Adobe). If the license fits, this is the shortest route to a supported headless store.

PWA Studio isn't archived. Its GitHub repository shows v14.5.0 in February 2026 and v14.5.1 in May 2026. Adobe's storefront documentation, though, now centers on Edge Delivery Services. A store running PWA Studio today has no emergency. Its next storefront decision should follow the backend and license, not PWA Studio's release calendar.

A custom frontend in React, often on Next.js (Vercel's React framework), gives you full control of the customer journey. You choose the framework your team already knows, and every screen is yours. Adobe's playbook is plain about the cost. Custom heads need strong frontend skills, lose native Page Builder compatibility and "may lose time-to-market advantages." Pick this route when your UX is genuinely different, not just branded differently.

Adobe Experience Manager fits when editorial content drives the sale, as in luxury, beauty or travel-style retail. AEM as a Cloud Service delivers structured Content Fragments to any app over GraphQL (Adobe, AEM headless), so it can act as the headless CMS beside Adobe Commerce. If AEM is already in your stack, look at what Adobe Experience Manager services can add on the content side.

Hyvä comes up in almost every one of these conversations, so it's worth placing. It's a frontend theme that replaces Luma, and the Hyvä Theme is now free and open source. It renders inside Adobe Commerce, so it isn't headless. For many single-store merchants, that's exactly the point.

Headless doesn't make a store fast. Decisions do.

Speed is the most common reason given for going headless, and the evidence for caring about it is solid. In late 2019, Google commissioned Deloitte and 55 to study 37 brand sites. A 0.1-second gain in mobile site speed went with an 8.4% lift in retail conversion rates (web.dev, "Milliseconds make millions"). That's a correlation from a 30-day window, not a promise. It still explains why mobile speed deserves its own line in the budget.

None of that speed comes free with the architecture. A poorly built React storefront can be slower than a tuned theme. The gains come from three choices. Render on the server or at the edge: Edge Delivery Services serves HTML from servers close to the shopper, and a custom head needs server-side rendering to match. Read catalog data from the hosted services, which Adobe says beat core GraphQL alone. And keep API calls few and small, using GraphQL to ask only for the fields a page needs.

There's a second kind of speed that gets less attention: speed of change. When marketing can publish a landing page without a backend release, campaigns stop waiting on code freezes.

Is the extra layer worth it for your store?

The headless approach earns its cost when one commerce engine has to serve many heads. That usually means several storefronts for different brands, regions or languages on one backend. It means web, mobile apps and kiosks that must show the same prices and offers at the same moment. It means campaigns that change weekly, or B2B and B2C buyers on one catalog with different pricing, quotes and approval flows.

If none of that sounds like your business, a traditional setup is often the better call. Headless adds an API layer, a second codebase and a second set of skills to hire for. Initial development takes longer than reskinning a theme, and someone has to own how the pieces fit together in year two. One store in one language with a standard catalog rarely needs it. Neither does a team that ships a campaign a quarter, has no frontend engineers in-house, or can't carry the added drop-in license on PaaS.

For those stores, a tuned theme such as Hyvä on Adobe Commerce, or a simpler hosted platform, will serve shoppers well and cost less to run. If you're comparing platforms more broadly, start with how the main commerce platforms fit your model. For a smaller direct-to-consumer catalog, a Shopify build may be the faster route.

Compliance doesn't shrink either. If you take cards, PCI DSS still applies, and each new head needs its own ADA and WCAG accessibility testing. The extra API layer is one more surface to secure.

Moving an existing store without breaking it

A headless project tends to fail slowly, then all at once. Five habits keep it on the slow-and-safe side.

1. Inventory your customizations. List every extension and custom module, and mark which ones touch the storefront, the checkout or the admin. Storefront-side extensions usually get rebuilt as components, and backend logic may move to App Builder.
2. Lock the backend and license before design starts. Choose PaaS, SaaS or Optimizer, and get written confirmation of which drop-ins your license covers. That single choice fixes your frontend options, your upgrade model and a good share of maintenance cost.
3. Migrate one page type at a time. Content pages first, then product listing and detail, then cart and checkout, each with a rollback plan. Split traffic between old and new where you can.
4. Protect rankings at cutover. Keep URLs stable, map redirects for any that change and confirm pages render full HTML without JavaScript. Check structured data and canonical tags on the new templates before launch.
5. Stay clear of peak season. Set the cutover well away from Black Friday and Cyber Monday. A new checkout shouldn't go live the week a code freeze lifts.

Step 1 is where our Adobe Commerce development team would begin: an extension inventory sorted by layer, so the backend and license call rests on what your store actually runs.

FAQ

Is Adobe Commerce headless by default?

Not on PaaS. Adobe Commerce on cloud infrastructure or on-premises ships with a built-in theme layer, though its GraphQL and REST APIs support headless builds. Adobe Commerce as a Cloud Service is different: its storefront is fully headless and Luma storefronts aren't supported.

Can you build a headless storefront on Magento Open Source?

Yes, with a custom frontend. Magento Open Source exposes GraphQL and REST APIs, so a React or Next.js head can run on it. Adobe's Edge Delivery Services storefront and drop-in components don't support Magento Open Source.

Is a headless storefront better for SEO?

Only when it's built for it. Search engines need fast, server-rendered HTML, stable URLs and clean structured data. Edge Delivery Services serves HTML from servers close to the shopper, while a custom frontend needs server-side rendering to compete with a well-tuned theme.

Backend first, then the head

The framework debate is the easy part, and it comes last. As an Adobe Solution Partner specialized in Adobe Commerce, Brainvire can map which backend and license fit your storefront plans before any design work starts. Start that conversation here.

Related reading

Three critical Magento flaws, three separate fixes: the October 2026 patch guideOctober 22, 2026 · 21 min readWhat is Adobe digital asset management? Inside AEM AssetsFebruary 5, 2025 · 11 min readAEM Adobe Analytics integration with the data layer, Tags and Web SDKJanuary 31, 2025 · 10 min read