Shopware open source: one core, three deployment models and what it means for your shop

On 27 August 2026, Shopware explained why open source is part of its commerce strategy and that all deployment variants (SaaS, PaaS, self-hosted) run on the same core. For shop owners, architects and developers this means plugins and integrations should remain compatible. Here you will learn where that applies, where the limits are and how to plan a switch.

A typical scenario: a head of technology compares two hosting offers, SaaS and self-hosted. The key question is whether plugins, integrations and operational processes remain compatible between the variants. Shopware describes its platform architecture as “one core, three deployment models”. A shared core is meant to ensure compatibility and make migration paths predictable. You can find the source in Shopware’s article on its open source strategy.

What does “one core, three deployment models” mean for shop owners?

The short answer: all three deployment variants (SaaS, PaaS, self-hosted) are based on the same Shopware core, so core functions and APIs should be consistent. Plugins and integrations are therefore portable in principle, and migration paths are easier to plan.

Technically, this means Shopware intends not to change central logic, data models and public APIs when a shop moves from its own hosting to a Shopware SaaS offering or to a PaaS. For you as a shop owner, this has three practical consequences. First, it is easier to assess whether a third-party plugin works in all models. Second, migration tests become more predictable because the APIs aren’t supposed to change fundamentally. Third, you can switch hosting options later without necessarily having to rewrite all integrations.

Compatibility doesn’t automatically mean full interoperability, though. System-specific configurations, infrastructure-dependent services (for example certain cloud services) and proprietary SaaS extensions can still cause differences. Before a migration, check the version and compatibility lists of the plugins you use and document any dependencies on the infrastructure.

How does the shared codebase affect developers, plugins and CI/CD?

The shared codebase reduces coordination effort for developers. API behaviour and core functions are more predictable, so plugin architectures, tests and CI/CD pipelines can be aligned with a reliable framework.

In concrete terms, test environments can be set up to reliably reflect the behaviour of the core. A plugin that strictly uses public interfaces and feature toggles is easier to transfer between SaaS, PaaS and self-hosted. CI/CD processes should include dedicated stages for contract tests against the core API, integration tests against external services and validation of infrastructure as code. This lets you find deviations early.

Some integrations do depend on the infrastructure, however. A search based on a particular host’s managed service may have to be run differently in another model. We therefore recommend building plugins in layers: a core-compatible layer, an adapter layer for the infrastructure and a configuration layer. Most of the code then stays the same, and only the adapters are swapped.

Which risks and limits apply when switching between SaaS, PaaS and self-hosted?

A unified core reduces risks but doesn’t eliminate them. Limitations arise from infrastructure dependencies, proprietary SaaS features and operation-specific configurations. Migration effort may still be needed, especially for integrations and operational processes.

Concrete risks include different operational functions (monitoring, backup, maintenance windows), differing additional services (for example CDN, managed search) and performance optimisations tied to particular cloud providers. Legal or data protection requirements can also make a switch harder if a SaaS offering doesn’t provide suitable data localisation.

Before a migration, a gap analysis is advisable: record the plugins in use, document external services and check which operational processes (CI, rollbacks, data migration scripts) are tied to the infrastructure. Test migrations in staging environments that reflect the target model as realistically as possible. User rights, API quotas or SLA agreements may differ with SaaS partners compared to your own data centre.

How does the open source strategy affect vendor lock-in and community contributions?

Open source as part of the strategy reduces classic vendor lock-in, because source code and core logic remain open. A practical tie to platform services is still possible if you use proprietary extensions. Shopware explicitly names community contributions as part of the strategy.

For shop owners, this means you can in principle view, adapt and run the code yourself, which strengthens your negotiating position with service providers. In practice, lock-in arises less from code access than from services used within the ecosystem (for example proprietary backups, certain cloud integrations) and from the degree of customisation. Shopware also addresses community contributions in the announcement: a shared core ensures that improvements and bug fixes benefit as many users as possible.

If your strategy aims for maximum independence, plan your architecture accordingly. Use adapters for external services, keep customisations in your own plugins cleanly separated from the core and document what needs changing. That way a switch remains possible without giving up updates from the community or the manufacturer.

When does which deployment model make sense for my shop?

The choice depends on three criteria: operational effort, need for customisation and compliance requirements. SaaS suits low operational effort, self-hosted gives maximum control, and PaaS is a compromise between control and simple operation.

Concrete decision aids:

• If you want as little operational effort as possible and accept that the provider manages some services, SaaS usually makes sense. Pay attention to SLA and data protection terms.
• If you need customisations at infrastructure or operating system level (for example special storage or security modules), self-hosted is probably the only practical option.
• If you want to scale flexibly while carrying less operational responsibility, PaaS is often a good compromise, provided the provider supports the add-ons you need.

Decide using a short list of criteria: list your mandatory requirements (compliance, performance, integrations), then optimise infrastructure costs and estimate long-term maintenance effort. Use migrations on staging to check whether your most important plugins and integrations can be transferred.

Frequently asked questions

Is the entire Shopware code really identical in all models?

Shopware states that all three models are based on the same core, so core functions and APIs should be consistent. Infrastructure-dependent additional features or proprietary SaaS extensions can still cause differences. Check the manufacturer’s information on the respective features.

Do plugins have to be recertified for each model?

Not necessarily. If plugins stick to the public APIs, they are portable in principle. Certifications or tests may be needed, however, if plugins use infrastructure-dependent functions or require special permissions.

How do I test migration paths in practice?

Create a test matrix: core version, plugin versions, external integrations. Run automated API contract tests, integration tests and load tests in a staging environment similar to the target model. Document deviations and build adapters where needed.

Does the open source strategy change anything about compliance or data protection obligations?

The strategy mainly concerns code and architecture; compliance depends on the operating model you choose. With SaaS, check data location and data processing agreements. With self-hosted, you configure data protection and backups yourself.

Conclusion

Use Shopware’s clarification as a starting point for a technical review, not as the sole basis for a decision. Check plugins, document infrastructure dependencies and test migrations on staging. If you want low operational effort, SaaS often makes sense; with strict compliance or customisation requirements, self-hosted is frequently necessary.

The next concrete step: create a list of all plugins and external services, test their behaviour in an environment that matches the target model and document the adapters you need. Then you stay in control when switching between SaaS, PaaS and self-hosted. You can read how we support such transitions under Shopware migration and relaunch.