Adobe Commerce Storefront on Edge Delivery Services combines edge-hosted pages, prebuilt drop-in components, and document-based authoring. The catch most coverage omits: drop-ins require a licence covering them, meaning Adobe Commerce as a Cloud Service, Adobe Commerce Optimizer, or Commerce PaaS with Optimizer added. If you run standard Commerce PaaS, that is a commercial decision before it is a technical one.
That single requirement reshapes the whole evaluation. Edge Delivery Services gets discussed as a performance choice competing with Hyvä, and on architecture it is. On procurement it is not the same conversation at all, because one path is a frontend project and the other may involve changing what you license from Adobe. Here is what it actually takes, drawn from Adobe’s own documentation.
What Edge Delivery Services actually is
Adobe’s Commerce Storefront documentation describes the stack as three things working together: Edge Delivery Services for hosting and delivery, Commerce drop-in components, and content blocks.
The pieces are worth separating, because people conflate them.
Edge Delivery Services is the delivery layer. Pages are served from the edge, and the authoring model is document-based, meaning merchandising teams create and edit content in familiar document tools rather than in a page builder inside the admin. That authoring shift is a bigger organisational change than the hosting change, and it is the part teams underestimate.
Drop-in components are ready-made npm packages that each own one shopper job: cart, checkout, product detail, sign-in. They are framework agnostic, so they can run in Edge Delivery Services, in AEM, and even in Luma. You wire them up rather than building them.
Content blocks are the authorable building units that sit alongside the commerce components.
The boilerplate ships with the B2C drop-ins pre-installed, which is genuinely useful. It means a standard B2C storefront starts from a working set rather than a blank page.
The licence gate
This is the part to establish before anything else. Per Adobe’s before you start guide, using drop-in components requires a licence that covers them: Adobe Commerce as a Cloud Service, Adobe Commerce Optimizer, or Commerce PaaS with Adobe Commerce Optimizer added.
Read that carefully against your own contract. A merchant on self-hosted Magento Open Source is not in scope. A merchant on standard Commerce PaaS without Optimizer is not in scope either, without adding it.
This does not make Edge Delivery Services unavailable to you. It makes it a procurement conversation with Adobe rather than a project you scope with an agency and start next sprint. That difference in lead time is the single most useful thing to know early, and it is routinely absent from comparison articles that place Edge Delivery Services and Hyvä side by side as though the barrier to each were the same.
What Commerce PaaS teams have to do first
If your backend is Commerce PaaS, there is real setup work before drop-ins function. Adobe lists the required packages and services:
- Storefront Compatibility package
- Services Connector
- Catalog Service
- Any additional services your rollout needs, such as Live Search, Product Recommendations, or Data Connection
Adobe is direct about what happens if you skip ahead: until that Commerce-side work is done, steps that read live data, like previewing a product page or running the boilerplate locally, can fail or look incomplete. Teams that start with the boilerplate before finishing the backend services tend to lose their first week to confusing, half-working previews.
Adobe Commerce as a Cloud Service and Adobe Commerce Optimizer handle most of these service requirements automatically. Commerce PaaS carries the extra configuration burden. That asymmetry is worth pricing into any estimate.
Developer prerequisites are conventional: an Adobe ID, a GitHub account, Node.js, npm, the AEM CLI, Git, and API credentials into your Commerce backend.
Edge Delivery Services against a Hyvä frontend
Both make a Magento storefront meaningfully faster. They are not interchangeable.
| Edge Delivery Services | Hyvä | |
|---|---|---|
| Licence prerequisite | ACCS, Optimizer, or PaaS plus Optimizer | None, core is free and open source |
| Backend setup | Substantial on PaaS, automatic on ACCS | Magento patch level and PHP version |
| Authoring model | Document-based, new workflow for merchandisers | Unchanged, stays in Magento admin |
| Component approach | Prebuilt drop-ins you configure | Templates you build in a child theme |
| Extension compatibility | Rethink around drop-ins and services | Compatibility modules or rebuild |
| Talent pool | Smaller, newer | Larger, established partner network |
| Best fit | Already in the Adobe content ecosystem | Speed without changing your contract |
The honest read for most mid-market Magento merchants: if the problem is that the storefront is slow, Hyvä is the shorter and cheaper path, because it requires no licence change and no backend service build-out. We compared frontends directly in our Hyvä vs Luma decision guide.
Edge Delivery Services earns its place when one or more of these is true. You are already on Adobe Commerce as a Cloud Service, so the licence and services questions are answered. Your merchandising team genuinely wants document-based authoring and will use it. You are invested in Adobe’s wider content tooling and want the commerce storefront to sit inside it. Or you are building a new storefront rather than migrating an existing one, so there is no accumulated theme to carry across.
Where the effort actually goes
If you do proceed, budget realistically against these, not against the boilerplate demo.
Backend services. On PaaS this is the first real workstream. Storefront Compatibility, Services Connector, and Catalog Service have to be installed, configured, and verified against live data before frontend work means anything.
Catalog and data readiness. Catalog Service and the storefront APIs expect your product data in a particular shape. Merchants with unusual attribute structures or heavy customisation find this is where the time goes.
Drop-in gaps. The drop-ins cover the standard B2C shopper jobs well. Anything outside that, and particularly B2B workflows, needs checking feature by feature against what the drop-ins support. Adobe’s own guidance acknowledges gaps exist and offers to help plan around them, which is a fair signal that you should inventory your requirements rather than assume parity.
Authoring migration. Document-based authoring is a workflow change for the people who merchandise your site every day. Training and process design are part of the project, not an afterthought.
Integration layer. As with any frontend change, your ERP, OMS, tax, fraud, and search integrations need to be re-verified. This is where most project risk lives regardless of which frontend you pick, and we have written about the patterns in Magento B2B integration patterns for ERP, CRM, and POS.
A useful sanity check before committing: ask your team to name which of these five workstreams they have done before. Most Magento teams have done the integration work and none of the rest. That is not a reason to avoid Edge Delivery Services, but it does mean the estimate should reflect a learning curve rather than assuming existing Magento frontend experience transfers cleanly. It largely does not, because the authoring model, the component model, and the deployment pipeline are all different.
A sequencing recommendation
For merchants weighing this in 2026, we would sequence the decision like this.
Start with your licence position, because it is binary and it has the longest lead time. If you are on Adobe Commerce as a Cloud Service, Edge Delivery Services is a genuine near-term option and worth evaluating properly. Our guide to Adobe Commerce as a Cloud Service covers what that platform is and who it suits.
If you are on Commerce PaaS or Magento Open Source, ask what problem you are actually solving. If it is speed, a Hyvä frontend gets you there without a contract change, and the runway question is covered in how long can you stay on Luma. If it is a genuine strategic move into Adobe’s content ecosystem, then the licence conversation is the right one to start, with eyes open about lead time and the PaaS setup burden.
What we would not recommend is treating the two as equivalent performance options and picking on benchmark numbers alone. The constraint that decides this is commercial, not technical.
How Bemeir helps
Bemeir is a Brooklyn ecommerce agency and the USA’s first official Hyvä Gold Partner, working across the Adobe Commerce stack since Magento 1. We will tell you when a frontend change is not the answer, which is more often than most agencies admit.
Our Magento and Adobe Commerce development practice covers upgrades, B2B, security, and the backend service work an Edge Delivery Services rollout depends on. Our Hyvä development services cover the path that needs no licence change. We also build on Shopify and Shopify Plus, Shopware, and BigCommerce, and the integration work behind any storefront decision draws on our technology partner ecosystem across payments, ERP, shipping, and search.
More about the team is on the about Bemeir page, or start a conversation from the Bemeir homepage.
Frequently asked questions
Do I need a special licence to use Adobe Commerce Edge Delivery Services?
To use the Commerce drop-in components, yes. Adobe states that drop-ins require a licence covering them: Adobe Commerce as a Cloud Service, Adobe Commerce Optimizer, or Commerce PaaS with Adobe Commerce Optimizer added. Merchants on standard Commerce PaaS without Optimizer, or on Magento Open Source, need a commercial conversation with Adobe before this becomes a technical project.
What do I have to install on Commerce PaaS before drop-ins work?
The Storefront Compatibility package, Services Connector, and Catalog Service at minimum, plus any additional services your rollout needs such as Live Search, Product Recommendations, or Data Connection. Adobe is explicit that until this backend work is finished, anything reading live data, including previewing a product page or running the boilerplate locally, can fail or look incomplete.
Is Edge Delivery Services better than Hyvä?
Neither is universally better and they clear different bars. Edge Delivery Services requires a qualifying licence and, on PaaS, meaningful backend setup, and it changes how merchandisers author content. Hyvä requires no licence change since the core became free and open source, and it leaves the authoring workflow alone. If your problem is a slow storefront and your contract is standard, Hyvä is usually the shorter path. If you are already on Adobe Commerce as a Cloud Service, Edge Delivery Services is a serious option.
Can drop-in components be used outside Edge Delivery Services?
Yes. Drop-ins are framework agnostic npm packages, so they can be used in Edge Delivery Services, in AEM, and in Luma. That flexibility is useful if you want to modernise specific shopper journeys, such as cart or checkout, without committing to a full storefront replatform, though the licensing requirement still applies.
Does Edge Delivery Services support B2B?
The boilerplate ships with the B2C drop-ins pre-installed, and B2B requirements need checking feature by feature rather than assumed. Adobe acknowledges that gaps exist between drop-in coverage and specific merchant scenarios and offers planning support to identify what is supported versus what is a gap. If you run complex company hierarchies, negotiated quoting, or requisition workflows, inventory those requirements before committing.
