Can you install a plugin on Shopware Cloud?
No. Shopware’s extension overview publishes a comparison table for what can be installed in Shopware 6 Cloud shops, and the plugin row is a cross. Themes are a cross too, unless delivered inside an app. Apps are the only tick.
The reason is architectural rather than commercial. Shopware’s own wording is that apps "are the extension mechanism designed for Shopware’s Cloud environment" and that "unlike plugins, they don’t run code directly inside the shop system", communicating with external services through APIs instead. A plugin runs inside the shop, with access to the platform’s own logic and its database. Cloud does not give anybody that access, including you.
This is the least-written-about fact in Shopware buying, and it is the one that reframes every total-cost comparison against a hosted platform. It is also easy to miss, because Shopware sells Rise, Evolve and Beyond as SaaS, PaaS or self-hosted, so a buyer can get quite far believing the plan and the hosting are the same decision. They are not.
Checked against: Shopware developer docs: plugins, themes and apps in Cloud shops, read 20 August 2026
Why does that decide an ERP integration?
Because the useful half of an ERP integration usually needs to run inside the storefront, not beside it.
Pushing catalogue, stock and orders back and forth does not need to be inside Shopware. An external service or Middleware is a layer of software that sits between the ERP and the storefront, translating and enforcing rules that neither system holds on its own. It can be a hosted integration platform or a custom service. can do all of that through Shopware’s Admin API and Sync API, and that works on Cloud.
What cannot live outside is behaviour: resolving a customer-specific price while the page renders, blocking a checkout because the customer is over their credit limit in the ERP, showing a delivery date the ERP calculated, or substituting an availability rule the platform does not model. Those hook into Shopware’s own pricing and checkout logic, which is what a plugin can reach and an app cannot.
So the test is simple. If your ERP integration only has to move data on a schedule and on events, Cloud is on the table. If it has to change what the storefront decides at the moment a buyer is looking at it, you are on self-hosted or PaaS, and the operational cost of that belongs in the business case next to the licence.
Checked against: Shopware developer docs: Admin API, Store API and Sync API roles, read 20 August 2026, Shopware developer docs: apps communicate with external services through APIs, read 20 August 2026
Shopware Cloud and self-hosted, compared on what an ERP project actually needs
One claim per cell, read from Shopware documentation on 20 August 2026. PaaS sits between the two columns: you get plugin capability without running the metal yourself, and you still own upgrades and application-level operations.
Read the first three rows together. They are the same decision looked at from three angles.
| Criterion | Shopware SaaS Cloud | Self-hosted or PaaS |
|---|---|---|
| Install a custom pluginEverything else on this table follows from this row. | No. Shopware’s extension table marks plugins as not installable in Cloud shops. | Yes. A plugin runs inside the shop with access to its logic and database. |
| Install a custom app | Yes, and apps can carry themes too. Apps talk to external services over APIs rather than running code in the shop. | Yes. Apps work on both, so an app-based integration is the portable choice if you might move hosting later. |
| Resolve a price from the ERP at render timeThis is usually the only reason a contract-priced seller chooses Shopware over a hosted platform, so it is usually the row that settles hosting. | Not from inside the platform. You can pre-compute prices externally and write them in through the Admin API on a schedule. | Yes, through a plugin that extends the pricing layer, with caching and a defined fallback for when the ERP does not answer. |
| Block checkout on an ERP condition such as a credit limit | Only on data already written into Shopware, evaluated by the Rule Builder. The freshness of that data is whatever your sync interval is. | Yes, including a live call at checkout, with your own timeout and failure behaviour. |
| Who patches, monitors and restores the environmentThe honest counterweight to everything above. Teams underestimate this consistently. | Shopware. This is the whole value of Cloud and it is worth real money. | You, or a partner under a maintenance agreement. Budget it as an ongoing line, not a project cost. |
| Database and infrastructure access | None. No direct database access and no server access. | Full. This is what makes data residency, deep reporting and unusual integration patterns possible. |
| Disaster recovery and region | Shopware’s responsibility, within the regions and terms it offers. Confirm region and recovery objectives in writing before you sign. | Entirely yours to design and pay for, which is either an advantage or a liability depending on your team. |
| Upgrades | Handled for you, which also means on Shopware’s timing rather than yours. | Yours to schedule, which matters because B2B Components carry per-component minimum versions. |
Checked against: Shopware developer docs: plugins, themes and apps in Cloud shops, read 20 August 2026, Shopware developer docs: integrations and APIs, read 20 August 2026, Shopware docs: B2B Components and per-component minimum versions, read 20 August 2026
A five-question test for which side you are on
Answer these about your own requirements before anybody quotes you. If you answer yes to any of the first four, you are on self-hosted or PaaS and the licence figure is not the whole cost.
If you answer no to all four, Shopware Cloud is genuinely available to you, and so are the hosted platforms you were comparing it against, which is worth noticing.
Does the correct price depend on something the storefront cannot know in advance, so it has to be calculated while the page renders?
Does the checkout have to be blocked or altered based on a value that lives in the ERP and changes during the day, such as an available credit balance?
Does the storefront have to show an availability or delivery answer that only the ERP can compute, rather than a stock number it was sent earlier?
Does any part of your compliance, data-residency or audit requirement need direct database or infrastructure access?
And the counter-question: is there a named team or partner, under a maintenance agreement, who will patch and monitor this environment in year three? If not, the honest answer may be to change the requirements rather than the hosting.
Checked against: Shopware developer docs: plugin and app capabilities, read 20 August 2026
When is Shopware Cloud the right answer?
Often, and we would rather say so than sell an operational burden nobody needs. Acro Commerce is a Shopware Platinum Partner and self-hosted work is the more lucrative shape, which is exactly why this section is here.
Cloud fits when your ERP integration is a data pipeline rather than a behaviour change: catalogue and stock in, orders out, on a schedule and on events. An integration platform or a custom external service calling the Admin API and Sync API does that comfortably, and the app model exists precisely for extensions that work this way.
Cloud also fits when your pricing is pre-computable. If the right price for a customer can be worked out overnight and written in, you do not need render-time resolution, and the strongest argument for self-hosting evaporates.
And Cloud fits when your team has no appetite for operations. A self-hosted Shopware that nobody patches is a worse outcome than a Cloud tenant with a slightly awkward integration, and it is a common one.
One honest caveat. If you choose Cloud and later discover you need in-process behaviour, the migration is real work: hosting, deployment, extension architecture and testing all change. Decide this deliberately rather than by default.
Checked against: Shopware developer docs: apps are the extension mechanism designed for Cloud, read 20 August 2026, Shopware pricing: Rise, Evolve and Beyond available as SaaS or PaaS, read 20 August 2026
What we could not verify about Shopware hosting
Three things, stated because a page that only publishes what it knows is more useful than one that fills the gaps.
Shopware does not publish rate limits, batch-size caps or an API versioning policy in its integrations guide, so nobody can tell you from documentation how fast a Cloud tenant will accept a 40,000-SKU catalogue load. That figure has to come from a test.
We could not establish whether B2B Components are fully exposed through the Store API, which matters here because a headless front end on Cloud is the one architecture that would sidestep the plugin restriction for some behaviours. Shopware’s B2B Components developer documentation makes no statement about Store API coverage as of 20 August 2026.
And Shopware’s published documentation does not set out region availability or recovery objectives for Cloud in a form we could quote, so treat both as contract questions rather than product facts.
Checked against: Shopware developer docs: integrations and APIs, no published rate limits, read 20 August 2026, Shopware developer docs: B2B Components, no Store API statement, read 20 August 2026
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Can you install plugins on Shopware Cloud?
- No. Shopware’s extension overview publishes a table for what can be installed in Shopware 6 Cloud shops, and plugins are marked as not installable, as are themes unless they are delivered inside an app. Apps are the supported extension mechanism on Cloud, and Shopware describes them as not running code directly inside the shop system. Read 20 August 2026.
- Does that mean Shopware Cloud cannot integrate with an ERP?
- It can, through the APIs. An external service or an integration platform can move catalogue, stock, customers and orders using Shopware’s Admin API and Sync API, and an app can react to events. What Cloud cannot do is run your code inside the storefront, so anything that changes what Shopware decides at render time or at checkout needs self-hosted or PaaS.
- What is the difference between a Shopware app and a plugin?
- A plugin runs inside the shop system with access to its logic and database, and it cannot be installed on Cloud. An app, in Shopware’s words, does not run code directly inside the shop and instead works in an event-driven way, communicating with external services through APIs. Apps can also carry themes. Apps install on both Cloud and self-hosted, so an app-based integration is the portable option.
- Is Shopware PaaS the same as Shopware Cloud?
- They are different offers and the distinction matters for this question. Shopware lists Rise, Evolve and Beyond as available as SaaS or PaaS. The restriction documented in Shopware’s extension guide is on Cloud shops, so a PaaS or self-managed deployment is the route when you need a plugin. Confirm the specific deployment model in your contract, because the marketing word "cloud" is used loosely across the industry.
- If we start on Shopware Cloud, can we move to self-hosted later?
- Yes, but treat it as a project rather than a setting. Hosting, deployment pipeline, extension architecture, monitoring and testing all change, and any app-based integration you built may need rework to become a plugin. The cheaper path is to answer the render-time question honestly at the start: if the correct price or the checkout decision has to come from the ERP live, choose self-hosted or PaaS on day one.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.