In short: The difference between a Shopware project that runs calmly and one that turns every release day into a risk rarely lies in the code - it lies in the pipeline around it. From my project experience: Docker as the local base, shopware-cli for builds and project tasks, deployments through the Deployment Helper instead of FTP, and a staging environment that deserves the name. None of this is rocket science - but the combination decides.
The actual problem: fragmentation
Ask ten Shopware developers about their local setup and you get eight different answers: native PHP with Valet, Symfony CLI, devenv, Dockware, hand-built Docker composes, MAMP descendants. Each of them somehow works - and that is exactly the problem: in teams and during handovers, every special solution costs time. The new colleague fights the environment for two days instead of the ticket, and "works on my machine" is the norm instead of the exception.
Shopware itself is visibly working on establishing one golden path here - the direction is clear: Docker as the standard, one CLI as the central tool. My recommendation: walk that path instead of maintaining yet another island solution.
Local: Docker, consistently
What has proven itself in my projects:
- Docker as the only prerequisite. No locally installed PHP with an extension puzzle, no version conflicts between projects. The project's PHP version lives in the container, not on the machine.
- The same services as production: MySQL/MariaDB in the live version, plus Redis, OpenSearch/Elasticsearch and Mailpit for outgoing mails where needed. Developing locally without a search server while running one in production means testing past reality.
- Reproducibility over comfort: The environment is versioned in the repository. Everyone on the team - and every AI agent increasingly working alongside - can bring it up with one command.
Build: shopware-cli instead of a script collection
The shopware-cli has established itself as the central tool - for extension builds, project builds (shopware-cli project ci) and store uploads. The point that pays off most in projects: the build runs identically locally and in CI. Composer install, asset compilation, one command. That kills the undocumented build.sh scripts that only work on the original developer's machine.
Add a CI pipeline (GitHub Actions or GitLab) that at minimum builds, runs static analysis (PHPStan) and tests on every push. Not as dogma - as an early warning system.
Deployment: the Deployment Helper is the standard
I still regularly see the deployment anti-pattern of all anti-patterns: changes pushed via SFTP straight to the live server, undocumented, bypassing Git. That works right up to the first update - then nobody knows what is actually running on the server.
The Shopware Deployment Helper is the right answer: one entry point that checks the installation, runs migrations, manages extensions and triggers theme compilation - idempotent and repeatable. Combined with the transport of your choice (Deployer, rsync, containers), you get a deployment anyone on the team can trigger, without "the one colleague who knows how".
The rules I enforce in every project:
- No path around Git. What is not in the repository does not exist.
- Staging is mandatory, not luxury. An update that never ran on staging does not run on production either - it just has not been noticed yet.
- Deployments are boring. If a deployment produces adrenaline, the process is broken, not the day.
What only sounds good in theory
For completeness - things I dismantle in projects:
- Kubernetes for the 50,000 € revenue shop. The operational complexity eats every theoretical benefit. A clean Docker setup on a decent server goes a long way.
- Microservices around Shopware where a plugin or a lean Symfony application would do. Distributed systems are not an end in themselves.
- Custom deployment frameworks. Every agency maintaining its own deployment tool pays for it again with every project. The standard tools have become good enough - use them.
Conclusion
In 2026 there is no good reason left for exotic Shopware setups: Docker locally, shopware-cli for builds, Deployment Helper for the way to the server, staging as the safety net. This is not a big project - converting an existing setup usually takes a few days and pays for itself with every update. The most expensive pipeline is the one that exists only in one person's head.