Skip to content

Make shopware/shopware stand-alone for development and testing

Make shopware/shopware stand-alone for development and testing


This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository. You can find the original version here


The platform requires some additional config, a console and web entrypoint and additional development tooling for development, tests and running the application. In practice this is provided by one of the templates: shopware/development or shopware/production. This creates a cyclic dependency, which brings some problems:

  • shopware/development and shopware/shopware need to be updated in lockstep, which makes updating them individually sometimes impossible
  • some IDEs have trouble with multi-repository projects
  • updating development tooling breaks everything
  • auto-detection of git revision and diff is broken because the development template is the root
  • for each release branch an additional branch needs to be maintained


  • use shopware/shopware directly in the pipeline
  • allow development without a template by moving the development tooling into platform
  • only advertise this as shopware/shopware development setup. Projects should still start with shopware/production as a template
  • shopware/development should continue to work
  • allow testing by adding entrypoints for cli and web
  • add scripts to composer to ease common tasks
    • these scripts should be kept small and simple
    • essential functionality should be implemented as npm scripts or symfony commands
    • we should improve the symfony commands or npm scripts if they are too complicated
    • if possible, the scripts should allow adding arguments
  • use standard convention
    • .env.dist provides default environment variables
    • .env can be used to define a custom environment (for example, if you use a native setup)
    • docker-compose.yml provides a working environment
    • docker-compose.override.yml can be used for local overrides to expose ports, for example
  • use defaults that work out of the box in most cases
    • don't expose hard coded ports in docker-compose.yml. It's not possible to undo it and may prevent startup of the app service


  • simplified CI, which also makes errors easier to reproduce locally
  • simplified local setup
  • no custom scripts that are not available in all setups
  • projects may try to use shopware/shopware directly
  • yet another shopware setup to choose from