Shopware 6 Extension Decision Guide: Plugin or App?

Every Shopware 6 extension project starts with the same fork in the road: build a plugin (PHP code loaded into the Shopware process) or an app (a manifest-declared extension that talks to the shop through APIs, webhooks and app scripts). The choice is hard to reverse later, and one constraint — hosting model — can eliminate one option entirely before you write a line of code.

The short version: if the shop must run on managed Shopware Cloud, you build an app. If you need deep access to core services and the shop is self-hosted, a plugin is usually the better tool. Everything else is trade-offs.

Start with the constraint that decides for you

Managed Shopware Cloud environments accept apps but not arbitrary plugins. If cloud compatibility is a requirement — now or plausibly later — the plugin option is effectively removed regardless of its technical advantages. Confirm the hosting model with the shop operator first; it is the cheapest question in the whole project and the one most often skipped.

Second constraint: distribution. If you intend to sell or ship the extension to many shops you do not control, the app model's external hosting and manifest-based install fit that SaaS-style distribution. Plugins ship with the shop codebase, which suits projects where you control the deployment.

How the two models compare

Trade-offs in practice

Plugins win on depth and ergonomics. You write a plugin base class, register services in the Symfony DI container, and subscribe to events directly. You get the data abstraction layer, in-process performance, and a normal local debugging loop. The cost is coupling: plugin compatibility across major upgrades is not guaranteed, so budget migration work whenever the shop's core version changes.

Apps win on isolation and reach. The app declares its metadata, permissions, webhooks, admin modules, custom entities and app scripts in a manifest. Because it interacts through defined surfaces, it survives upgrades better and runs where plugins cannot. The cost is that you can only use what the platform exposes, and anything beyond app scripts needs an external endpoint, credential handling, and webhook delivery you have to operate.

Hybrids are common. A thin app shell calling an external service, or a plugin offered only to self-hosted customers while cloud customers get an app, are both legitimate answers when one model cannot cover the requirement alone.

Concrete sketch: reacting to the same event both ways

Take one requirement: "when an order is placed, run custom logic." This fits both models and makes the difference tangible.

As a plugin, you create a plugin class, a service definition file, and an event subscriber that listens for the order event. The subscriber receives the event in-process and can call core services directly. Install and activate it via the Shopware console on a staging instance — but do not assume command names: run the console's command list on the actual installation and confirm the install/activate commands exist in your release, since they differ between versions.

As an app, you write a manifest declaring the app name, version, the permissions it needs, and a webhook bound to the same order event, pointing at your external endpoint. For simple logic you may instead use an app script and skip the external host entirely. Follow least privilege on permissions — over-broad scopes are a common security and store-review failure.

Validation checklist

1. Confirm the target Shopware major/minor version and hosting model before committing.
2. Check the developer documentation for your installed version: manifest fields, app script support, custom entities, and plugin base class signatures all vary between minor releases.
3. Install and activate the extension on staging; confirm it appears in the extension manager.
4. Trigger the subscribed event (place a test order) and verify the handler ran: check logs and the expected side effect.
5. For apps, verify webhook delivery and that credentials use minimal scopes.
6. Re-verify after any core upgrade; extension APIs and deprecations change between minor releases.

Limitations to keep in mind

The manifest schema, app script capabilities and custom-entity support depend on the exact minor version, so confirm the features you rely on exist before choosing the app model. Store distribution adds separate requirements — signing, review rules, permission justification — that sit outside the technical choice. And if you are genuinely torn, prototype both options against one real requirement and compare activation success, event handling, upgrade path and deployment effort. A day of prototyping beats a week of guessing.