Shopware Cloud vs. Self-Hosted in 2026: The Architecture Decision, With Real Numbers

Shopware Cloud is almost always discussed as a pricing question: what does the cloud cost, what does self-hosted cost, which one is cheaper? For Shopware, that question is already answered — by Shopware itself. Their official pricing page states it plainly: “Shopware SaaS comes at the same price as self-hosted.”

With that, the usual comparison criterion disappears, and the real question surfaces: Shopware Cloud vs. self-hosted is an architecture decision, not a cost decision. You are not deciding how much you pay. You are deciding how much access you keep to your own system — and which extensions you will still be able to install afterwards.

That second point is the one almost nobody discusses with actual numbers. So we measured it instead of describing it:

1. We counted the extension store. How many extensions in the official Shopware Store actually run in the cloud? And — far more importantly — how many of the best-selling ones?
2. We put the app system against the plugin system. Both extension types are defined in the source code. Their limits can be counted rather than claimed.
3. We took the pricing statements from the source, not from secondary articles.

Every number in this article was collected on 13 August 2026 — directly from the Shopware Store, from shopware.com, and from a fresh clone of the core repository (commit state 13 August 2026, version 6.7.13.0). Where we had to correct ourselves while measuring, it says so in the text. That is part of the method, not something for the archive.

What Shopware Cloud actually is

“Shopware Cloud” is not a single product. It is an umbrella term for two operating models that Shopware hosts itself:

• Shopware SaaS — Software as a Service. Shopware runs the infrastructure, applies updates automatically, and handles scaling and maintenance. You get a finished shop and work in the administration interface.
• Shopware PaaS — Platform as a Service. Also hosted by Shopware, but with a deployment pipeline, environments, CI/CD, and your own code. Shopware describes it as “all benefits from Shopware SaaS, as well as maximum customizability, performance monitoring, and dev tools.”

Opposite these sits self-hosted (often called on-premise): you install Shopware on your own server or with a hosting provider of your choice. Shopware itself describes this as the right solution “if you have an expert developer team by your side and you need full control over your chosen IT infrastructure.”

The sentence that actually decides the whole question, however, sits elsewhere on the same page — in the section about the Community Edition:

“It is not available in the Shopware Cloud – setup and maintenance are therefore your responsibility.”

The free Community Edition does not exist in the cloud. Anyone saying “Shopware Cloud” is necessarily talking about a paid plan. That is the first hard boundary, and comparisons routinely miss it, because “Shopware is open source and free” is a true sentence on its own — just not for the cloud.

The pricing question is answered faster than you think

Shopware’s plans are Community (free), Rise (from €600/month), Evolve (from €2,400/month) and Beyond (individual), all prices excluding VAT, as listed on 13 August 2026. Pricing is based, in Shopware’s words, on “your gross merchandise value (GMV) and further individual factors” — meaning the listed price is a floor, and your actual price depends on your merchandise volume.

And again: the plan costs the same in the cloud as self-hosted. The difference lies elsewhere — with self-hosting, server costs, updates and operational effort come on top; in the cloud they are included in the plan. We covered the full cost breakdown including TCO calculations in a dedicated article: Shopware 6 pricing and costs covers hosting, agency work, plugins and the hidden line items in detail. This article is about what the price does not tell you.

One small detail says more about the target audiences than any feature table: you can book a Rise plan directly in your Shopware account — but according to the footnote, only for self-hosted shops. For SaaS and PaaS you have to contact sales. The self-service path leads, of all places, into the model that demands more self-reliance.

The number that decides everything: 13.2%

Now to the core. You cannot install every extension in the cloud — that much is known. What is usually unknown is how large the restriction actually is. So we counted.

The official Shopware Store offers a “Cloud Compatible” filter. We applied it and paginated through every result page:

Method: store.shopware.com/en/extensions/, retrieved 13 August 2026. Total from the unfiltered result count, cloud figure with the store’s “Cloud Compatible” filter applied. The cloud set was additionally verified by paginating every result page and deduplicating by name + vendor: exactly 448 unique entries.

Roughly seven out of eight extensions in the official store do not run in Shopware Cloud. That is not a footnote. That is the decision.

And now the number that actually hurts

13.2% sounds like a restriction you could live with — after all, 448 extensions is a lot in absolute terms. The catch: not every extension matters equally. What counts is whether the extensions most shops actually use are available.

So we applied the same check to the bestseller list — the 144 most-purchased extensions in the store, sorted by topseller ranking:

Method: store.shopware.com/en/extensions/?order=topseller, pages 1–6 (144 cards, all unique), retrieved 13 August 2026. Matched against the complete cloud set by name + vendor. See the box below for the error source in the badge-based approach.

The more popular an extension is, the less likely it runs in the cloud. In the store’s top 48, it is three. Three.

A look at the names makes the practical impact clear. Among the bestsellers that are not cloud compatible are:

• PayPal for Shopware 6 (shopware AG)
• Shopware 6 Security Plugin (shopware AG)
• Shopware Migration Assistant (shopware AG)
• Shopware Language Pack (shopware AG)
• Custom JavaScript/CSS Manager, Custom Template Manager (PremSoft)
• SEO Redirect (301 / 302) (scope01)
• Amazon Pay

The remarkable part: several of these come from Shopware itself. So the cloud restriction is not third-party vendors being slow to port their products — it is structural. The next section explains why.

⚠️ How we almost lied to ourselves with this number

Our first approach was the obvious one: the store renders badges on every product card, including a cloud symbol. So we counted cards with a cloud badge in the bestseller list — result: 9 of 144 = 6.2%. A nice, dramatic number.

It was wrong. The cross-check using set logic (matching all 448 entries of the cloud filter against the 144 bestsellers) produced 12. Three extensions by MILLENWORLD appeared in the cloud filter but carried no badge in the unfiltered bestseller list — same products, same website, with the filter applied the badge appeared, without the filter it was missing.

🔑 The lesson: a display element is not a data field. The badge is rendered when the context calls for it; it is not a reliable property of the product. Both numbers looked plausible, both came from the same source, and only one held up. That is why this article consistently uses the higher, more conservative figure (8.3%), even though the lower one would have supported our thesis more strongly.

A second error from the same family: while paginating, we initially counted 592 cloud badges across 448 cards — impossible. Cause: when the page number exceeds the last valid page, the store silently serves the last valid page again instead of returning an empty page or an error. Duplicate counts. Only deduplication by name + vendor produced the clean 448. A pagination that never comes back empty cannot be used as a stop condition.

Who actually builds those 448 cloud extensions

The cloud set itself deserves a second look, because 448 extensions sounds like a thriving ecosystem:

Method: full evaluation of all 448 entries in the cloud filter; vendor and price taken from the product card’s data attribute (0.00 = free). Collected 13 August 2026.

A quarter of the cloud offering comes from five vendors. That is not a disaster, but it puts the 448 in perspective: the selection is narrower than the absolute number suggests, and concentrated among a few houses.

Why this is the case: apps instead of plugins

The extension limit in the cloud is not arbitrary — it follows directly from the architecture. Shopware has two kinds of extensions, and only one of them is cloud capable.

Plugins are PHP code that runs inside the Shopware process. They are loaded into the application, may replace services, override templates, create their own database tables and modify practically any point of the system.

Apps run outside of Shopware. They communicate exclusively over HTTP. Shopware’s own documentation puts it refreshingly clearly:

“Fully cloud compatible: By decoupling Shopware and your app, your app is automatically compatible with multi-tenant cloud systems.”

And that is exactly where the price sits: an app is cloud capable because it does not reach into the core. In a multi-tenant cloud, many shops share one platform — foreign PHP code in the core would be a security and stability risk for every other tenant. The restriction is the condition that makes the model work at all.

The difference, counted in the source code

Both extension types are defined in the Shopware core. Instead of claiming “apps can do less”, it can be counted. We cloned the repository (state 13 August 2026, 6.7.13.0) and measured the surface area of both systems:

Method: git clone --depth 1 github.com/shopware/shopware, commit state 13 August 2026. Schema elements from src/Core/Framework/App/Manifest/Schema/manifest-3.0.xsd (unique xs:element name=). App script hooks = concrete, non-abstract classes extending a *Hook class, excluding test artefacts. Event classes = concrete classes with the Event suffix outside test directories. Twig blocks = unique {% block %} names under src/Storefront/Resources/views. PHP classes = all .php files outside test directories.

The row that hits the core: 58 schema elements against 6,704 decoratable classes. An app moves within a clearly fenced field that Shopware defines. A plugin moves within Shopware.

This is explicitly not an argument against apps. The app system is technically the cleaner solution: it survives updates better, it can be written in any language, and it cannot crash the shop. It simply answers a different question — “how do I extend the system safely?” instead of “how do I fundamentally change the system?”

A side finding from the source code

While searching the core for a cloud switch, we came up empty — and the absence is itself a finding: there is no SaaS or cloud environment variable in the core that disables features. Searching src/Core for corresponding constants or env flags returned nothing.

That confirms what Shopware also communicates openly: cloud and self-hosted run on the same codebase. The cloud is not a stripped-down Shopware. The difference does not come from disabled features, but from who has access to the execution environment. You get the same program — just without the key to the engine room.

What you actually give up in the cloud

The practical limits follow from the architecture. In order, without drama:

1. No root access, no console. You cannot log into the server. No bin/console, no direct database access, no looking at logs on the filesystem. Anyone who has narrowed down a Shopware issue with a console command knows what is missing here.

2. No custom PHP plugins. The big one from the section above. Individual requirements that would need a plugin — an exotic ERP connection, special pricing logic, a deep change in the checkout — are not implementable in the SaaS variant.

3. No control over update timing. Automatic updates are a selling point and a risk at the same time. They take work off your plate — and they take away your ability to test an update on staging first and then deliberately roll it out.

4. No infrastructure access. No custom caching setup, no custom Elasticsearch configuration, no choice of data center, no custom cron job.

5. No Community Edition. As documented above: entering the cloud always costs money.

And in return you get:

1. No server responsibility. No patch day, no kernel update, no night spent explaining why the shop is unreachable. That is worth more than it sounds — we documented a real security incident on our own infrastructure that went unnoticed for five days. In a SaaS environment, that particular attack surface would not have been ours.

2. No update debt. The most common state of an aging self-hosted shop is not “broken” but “three minor versions behind, because the update window never came.” In the cloud, that state cannot arise.

3. Predictable costs. One plan instead of server plus maintenance contract plus emergency hours.

4. A smaller security problem. Less of your own code means less of your own attack surface. If you want to know where vulnerabilities actually come from in practice, we wrote that up with our own measurements in IT security vulnerabilities — the biggest entry vector is dependencies, not spectacular zero-days.

The migration path — and why it is not symmetric

A question that belongs before the decision rather than after it: can I get back out?

The good news: because cloud and self-hosted share a codebase, your data is not trapped in a foreign format. Products, customers, orders and categories live in the Shopware data model — the same one a self-hosted installation uses. That is a structural advantage over closed SaaS systems where you end up with nothing but a CSV export.

The uncomfortable news: the path is still not equally easy in both directions.

• Self-hosted → cloud is the harder direction. Every plugin you have accumulated over the years needs a cloud-capable counterpart — and by our count the probability of that is 13.2%, and lower still for popular extensions. Custom development has to be rebuilt as an app.
• Cloud → self-hosted is the easier direction, because you only carry over things that were built within the cloud’s narrower constraints. Everything that ran there also runs self-hosted — the set of possibilities grows, it does not shrink.

From this follows a practical recommendation you rarely read: when in doubt, start in the cloud. Not because it is better, but because leaving the cloud is the easier change of direction. Someone who starts self-hosted and realises three years later that they no longer want the server responsibility is sitting on a plugin stack that makes migration expensive.

Shopware PaaS: the overlooked third option

The “cloud or self-hosted” debate regularly ignores that Shopware offers a model in between. Shopware PaaS is also hosted by Shopware, but permits your own code, deployment pipelines and environments.

For many projects that is the actually fitting answer: you hand off server responsibility while keeping the ability to intervene deeply. Two caveats worth knowing:

• The price is not published. Shopware writes: “As Shopware PaaS is tailored to your specific needs, we offer you individualized pricing for it.” Unlike SaaS, there is therefore no commitment that it costs the same as self-hosted. We deliberately do not put an estimated number here — an estimated number looks exactly like a measured one once it sits in a table.
• It is not a self-service product. As with SaaS, the path runs through sales, and the documentation lists guided PaaS onboarding including deployment and CI/CD setup as a paid service on a time-and-materials basis.

If your requirement is “I need custom plugins but I don’t want to run servers”, then PaaS is the category you should be asking about — not SaaS.

Making the decision: concrete criteria instead of gut feeling

Instead of a pros-and-cons list, here is a set of questions that actually separate the cases. Each can be answered yes or no:

Choose Shopware Cloud (SaaS) if:

• You have no development team and do not intend to hire one.
• Your requirements are covered by standard features plus a handful of extensions.
• You have verified that the specific extensions you need are in the cloud set — the store filter answers that in five minutes.
• Automatic updates are a relief for you rather than a risk.
• You would rather invest your time in assortment and marketing than in infrastructure.

Stay self-hosted if:

• You need custom plugins, or already have them.
• An ERP, PIM or inventory integration exists for which there is no app.
• You must control update timing because your shop is business critical and an unplanned update would be unacceptable.
• You have specific requirements regarding hosting location, data residency or infrastructure.
• You want to use the Community Edition — which does not exist in the cloud.

Ask about PaaS if:

• Both lists above partly apply to you: custom code required, but no appetite for running servers.

And the one test that effectively pre-empts the decision: write down the extensions you need and check each one in the store filter. If a business-critical one is missing, the question is answered — regardless of every other argument.

How we do it ourselves — and why that should not be your benchmark

We run Shopware in production self-hosted, among others for Pastaclean, and we are an official Shopware partner. The choice was not made out of principle but because the requirements force it: custom plugins for product presentation and thumbnailing, template-level changes, integrations with existing systems. None of that would be possible in the SaaS variant.

That is explicitly not an argument for you. Our constellation — existing developer know-how plus deep custom requirements — is precisely the one self-hosting was built for. Anyone lacking those two things mainly buys themselves a responsibility they do not need.

To be honest, the flip side belongs in the balance too: self-hosting means security vulnerabilities are your vulnerabilities, updates are your job, and outages happen during your night. We have experienced both, and we would not advise anyone to take that on without a reason.

Conclusion: the right question is not “what does it cost”

Shopware Cloud vs. self-hosted is posed as a cost question and is not one — Shopware itself says SaaS and self-hosted cost the same. The real question is: how much access to your own system do you need?

The three numbers worth remembering:

1. 13.2% of the 3,402 store extensions run in the cloud.
2. 8.3% of the 144 best-selling extensions run in the cloud — the more popular, the less likely.
3. 58 schema elements are available to an app, versus 6,704 decoratable PHP classes for a plugin.

Anyone who knows these three numbers makes the decision in ten minutes instead of three meetings. And anyone unsure should start in the cloud — because the way out is easier than the way in.

If you want to place the Shopware ecosystem in a broader context, the neighbouring topics are here: Shopify vs. Shopware for the system comparison with a TCO model, Shopware 6 pricing and costs for the full cost breakdown, Magento alternatives for those migrating, and best shop system for choosing from scratch. And if you want to know how fast your shop actually is — regardless of operating model — you can measure it directly with our Core Web Vitals test.

FAQ: Common questions about Shopware Cloud

What is Shopware Cloud?

Shopware Cloud is the umbrella term for the two operating models Shopware hosts itself: Shopware SaaS (fully managed, automatic updates, no custom code) and Shopware PaaS (also hosted, but with a deployment pipeline and custom code). In both cases Shopware runs the infrastructure, not you.

What does Shopware Cloud cost?

The plans are Rise from €600/month, Evolve from €2,400/month and Beyond individually priced, each excluding VAT (as of 13 August 2026). Pricing is based, according to Shopware, on gross merchandise value (GMV) and further individual factors — the listed amounts are floors. Importantly, Shopware states that SaaS costs the same price as self-hosted; the difference is that self-hosting adds server and operating costs on top.

Is the Shopware Community Edition available in the cloud?

No. Shopware states explicitly on its own pricing page that the Community Edition is not available in Shopware Cloud, and that setup and maintenance are therefore your responsibility. Anyone wanting to use the cloud needs a paid plan.

Can I install custom plugins in Shopware Cloud?

No, not in the SaaS variant. Cloud environments permit apps only — extensions that run outside of Shopware and communicate solely over HTTP. Classic PHP plugins that execute inside the Shopware process cannot be installed. If you need custom code but still do not want to self-host, you should ask about Shopware PaaS.

How many Shopware extensions are cloud compatible?

Of the 3,402 extensions in the official Shopware Store, exactly 448 were marked cloud compatible on 13 August 2026 — 13.2%. Among the 144 best-selling extensions the share is even lower at 12 (8.3%). Several of the non-cloud-capable bestsellers come from Shopware itself, including the PayPal plugin, the Security plugin and the Migration Assistant.

What is the difference between an app and a plugin?

A plugin is PHP code that executes inside Shopware. It can replace services, override templates and modify practically any part of the system — the core offers 6,704 PHP classes and 2,047 Twig blocks for that. An app runs outside of Shopware and communicates only over HTTP; its scope is bounded by the manifest schema with 58 elements and 55 app script hooks. Apps are therefore cloud capable and update safe, plugins are more powerful.

Can I move from Shopware Cloud to self-hosted?

Yes, and that is the easier of the two directions. Cloud and self-hosted share a codebase and a data model, so your data is not trapped in a foreign format. Moving from cloud to self-hosted expands what is possible; nothing falls away. The reverse — self-hosted into the cloud — requires every existing plugin to have a cloud-capable counterpart, which is the actual cost driver.

Is Shopware Cloud more secure than self-hosted?

In one important respect, yes: server operation, patching and infrastructure security sit with Shopware, and less of your own code means less of your own attack surface. That does not replace diligence, though — credentials, permissions, third-party apps and how you handle customer data remain your responsibility. Self-hosted can be equally secure, but it requires a team that actually performs updates and hardening.

How do I find out whether my extensions run in the cloud?

The official Shopware Store has a “Cloud Compatible” filter. It lets you check in a few minutes whether the specific extensions you need are available. Important: rely on the filter result, not on the cloud symbol in unfiltered lists — while measuring we found the same product carrying a cloud badge with the filter applied and no badge without it.

Which Shopware variant is right for me?

As a rule of thumb: SaaS if you have no development team and can work with standard features plus available apps. Self-hosted if you need custom plugins, deep system integrations or control over update timing. PaaS if you need custom code but do not want to run servers. The fastest test is always the same: list the extensions you cannot do without and check each one in the store’s cloud filter.