# Shopware 6: a Symfony commerce platform with two extension systems and a maintained backport branch

> Headless by option, monolithic by default, and shipping three minor lines at once, with a development container that still declares itself as the previous version.

**shopware/shopware** — Shopware 6 is an open commerce platform based on Symfony Framework and Vue and supported by a worldwide community and more than 3.100 community extensions

- Repository: https://github.com/shopware/shopware
- Website: https://shopware.com
- Stars: 3,446 · Forks: 1,216
- Language: PHP
- License: MIT
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/shopware-shopware

## Three ways to extend one platform

The README describes Shopware as both a ready-to-use shopping cart system and an ecommerce framework, and the extension story is where that duality shows. There are three routes, listed separately because they differ in how much Shopware-specific knowledge you need.

Plugins are Symfony bundles. The README says plugins let you harness the full power of Symfony by creating bundles and loading them as part of the application, which is the deep route: full framework access, full coupling, and a learning curve that includes the framework itself.

Apps are the opposite. They are described as a modern, lightweight but powerful way to add functionality requiring very little Shopware-specific knowledge, which is the extension format for developers who want to ship something without becoming Shopware experts.

The third route is headless. The README lists Shopware as API-first and as headless if you need it to be, which means the storefront is one consumer of the API rather than a fixed part of the application.

A fourth option is not in that list at all, and it is the one the README recommends for on-premise work: installing through the flex template, which is described as making Shopware a vendor dependency in your project rather than the project itself. That inversion is the most important architectural fact in the README, and it is easy to miss because the bullet list presents it as just another feature.

## Three version lines shipping on the same morning

The three most recent releases were all published on 2026-09-23 or within a week of it: v6.6.10.26, v6.7.14.2 and v6.7.14.1 from the week before. Two minor lines are being maintained in parallel.

What the 6.6 patches contain is the interesting part, because these are not just dependency bumps. The listed fixes include syncing aria references on the search widget, improving the buy box screen reader accessibility, restoring offcanvas cart quantity focus, using valid text input types in checkout address modals, and improving cart helper form accessibility. Nearly every entry on that list is an accessibility fix, backported explicitly, which tells you two things at once.

First, the platform has an active accessibility problem in its storefront templates, and the team is working through it. Second, they are willing to backport those fixes into an older supported line rather than telling users to upgrade, which is a maintenance posture worth respecting and also a cost you should factor in if you are choosing a version.

The release body opens by pointing at an upgrade notes file in the repository root, and those files are all there, one per version from 6.1 through 6.9. A single release tag therefore does not carry its own changelog. To find out what changed you have to open a file in a different directory than the one you tagged, and that file describes every change in the minor line rather than just this patch.

## The development container advertises the previous minor version

The repository ships a `compose.yaml` for local work, and the first environment variable in it declares the version the development checkout pretends to be:

```yaml
+COMPOSER_ROOT_VERSION: 6.7.9999999-dev
+```

The same file pulls a container image tagged for PHP 8.4 and Node 24 with Caddy in front, wires a MariaDB service with a strict SQL mode and a large buffer pool, and points the application at OpenSearch for both the storefront and admin search. The database connection string is a local root user with a root password, which is fine for a development container and would be catastrophic anywhere else.

So the development environment identifies itself as a 6.7 development build, while the tree contains upgrade guides through 6.9 and a release notes file for 6.7 specifically. Those facts sit side by side without a note explaining the relationship. Either the container image is pinned to a line that is no longer the newest, or the dev environment intentionally tracks the line most installs run.

The practical consequence is narrow but real: if you follow the compose file to set up a local environment and then follow an upgrade guide for a newer minor, you will be working against a version stamp that disagrees with the guide. Check the version the template produces before you rely on it.

## Tooling that suggests how the project is actually run

The root directory is a better description of the project's engineering practice than the README is. There are architecture decision records in an `adr/` directory, a coding guidelines directory, a backward compatibility exclusion file, a deprecation ignore list, and a PHPStan configuration with a baseline and explicit paths. Each of those is an artifact of a team that runs automated checks and has to record exceptions to them.

There is also `composer-dependency-analyser.php`, which suggests a check for dependencies that should not be where they are, `phpbench.json` for performance benchmarks, and `config-schema.json` for validating configuration. A delivery process directory and a changelog directory suggest that releases and notes are generated rather than written by hand.

Then there is the agent configuration. The tree contains `CLAUDE.md`, `AGENTS.md`, an `.agents/` directory and a `.agents-templates/` directory, alongside a `.claude/` directory. A project that ships instructions for coding agents in the repository has decided that contributors will use them, and has chosen to version them so they stay in sync with the codebase.

For a contributor, that is convenient. For an evaluation, it is a signal about where the maintainers think friction is. The friction in a codebase this size is not writing code, it is knowing which of several hundred Symfony bundles and Shopware services to touch, which is exactly what a committed instruction file is for.

## Metadata details that are worth a second look

Two small things in the repository metadata are more informative than they look.

The GitHub topic list includes `magento` and `prestashop`. Those are competing commerce platforms, and neither is mentioned anywhere in the README. Topics like these help people searching for a migration path find the repository, which is a reasonable reason for them to exist, but it also means the topic list is not a description of what the project contains.

The repository description says the platform is supported by more than 3.100 community extensions, using a period as a thousands separator. The README says more than 3,100 extensions and links to the community store. The two numbers agree; the formatting difference suggests the description was written by someone whose first language is not English, which is not a criticism so much as a reminder that a one-line repository description is often the least-maintained text in a project.

Both numbers point at the same thing, which is the real strength of Shopware: the platform's ecosystem is large enough that finding an existing plugin is often cheaper than writing one. The extension store is a separate service from the repository, and its contents are not visible in this tree, so the count is a claim about somewhere else.

## Licensing, hosting and the CLA

The license in the repository is MIT, and there is a separate section in the README for a contributor license agreement. That combination is normal for a project that wants code contributions to carry a patent and copyright grant, and it is worth reading before you submit a pull request, because agreeing to a CLA is a decision with legal weight rather than a formality.

Hosting is where the commercial part lives. The README names a managed cloud offering as the easiest way to run a shop, and states that commercial plans also exist for on-premise installs, alongside a list of hosting partners who offer a pre-installed shop. There is also a web-based installer and a setup course.

So the MIT license covers the code, and the services around it are commercial. For an agency evaluating this, the question is not whether the license permits what you want to do with the code, since it plainly does, but whether the extension ecosystem and the support arrangements you need are covered by a plan you are willing to buy. That information is on the vendor's site, not in this repository, which is the normal arrangement for an open core project of this shape.

## Conclusion

Shopware is a real framework rather than a shop you configure, and the deciding question is whether you want Symfony bundles, Shopware plugins, the lighter app system, or a headless frontend talking to the API. The repository makes the trade-offs visible if you look past the README: an architecture decision record directory, a backward compatibility exclusion file, a deprecation ignore list and benchmark configuration all point to a codebase with real maintenance discipline. Version 6.7 is what most on-premise installs will land on today, 6.6 is still receiving accessibility backports, and the local container configuration has not caught up with the upgrade guides in the tree. Read the upgrade notes for your target version before you plan an extension build.

## FAQ

### What is Shopware used for?

Shopware 6 is an open source commerce platform for building online shops. It ships as a complete shopping cart system you can install through a template, and as a framework if you want to build on top of Symfony, since the platform is built on Symfony 7 with a Vue 3 administration interface.

### What is the difference between a Shopware plugin and an app?

A plugin is a Symfony bundle loaded as part of the application, which gives full framework access and full coupling. An app is the lighter format, described in the README as needing very little Shopware-specific knowledge. Extensions published to the community store use one system or the other, and picking the wrong one for an extension you intend to maintain long term is expensive to undo.

### Does Shopware need Elasticsearch or OpenSearch to run?

The local development compose file starts an OpenSearch service and points both the storefront and admin search at it, so a search backend is part of the standard development setup. For production the requirement depends on your catalogue size and search needs, which is a decision the README leaves to the deployment guides rather than answering in the overview.

### How do I find out what changed between Shopware versions?

The release body does not carry a full changelog. It links to an upgrade notes file in the repository root, and there is one file per minor version, so the file for your target line describes everything that changed in that line rather than only in the patch you are reading. Note also that patch releases land on older lines, so read the notes for the branch you actually run.

### Is Shopware free to use commercially?

The repository is MIT licensed, so the code can be used commercially. The commercial parts are the services: managed cloud hosting and commercial support plans for on-premise installs, both described in the README as separate offerings, alongside a list of hosting partners who sell pre-installed shops.

## Sources

- [License: MIT](https://github.com/shopware/shopware/blob/trunk/LICENSE)
- [Project website](https://shopware.com)
- [README](https://github.com/shopware/shopware/blob/trunk/README.md)
- [Releases](https://github.com/shopware/shopware/releases)
- [shopware/shopware on GitHub](https://github.com/shopware/shopware)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shopware-shopware