Shopware

Last reviewed Sep 13, 2026 · 898 words

Shopware is a Magento-class commerce platform that happens to have a pleasant admin. Budget 2 GB of RAM for a bare test install, 4 to 8 GB once OpenSearch and Redis join it, and about a week of learning before the first product goes live. For a shop with a few hundred products, no B2B pricing, and one warehouse, that is more platform than you need; WooCommerce or PrestaShop gets you selling in an afternoon. For a shop that has outgrown those, or a team leaving Magento, Shopware is the open-source option with the fewest regrets.

What you are actually installing

Shopware 6 is a Symfony application with a Vue.js administration and a Twig storefront. The Community Edition is MIT-licensed and is the same core the paid tiers run on; the commercial editions add things like the B2B suite, advanced search, and support, not a different product. The runtime you need: PHP 8.2 or newer at last check, MySQL 8 or a recent MariaDB, Composer, and Node during the build step for the admin bundle. It is a PHP app, which means a real web server with PHP-FPM, correct memory limits (512 MB per process is a sane floor), and opcache on, because the admin makes hundreds of API calls per page and a cold PHP process makes every one of them slow.

Dockware for development, your own image for production

The community-maintained Dockware images bundle everything, including MySQL and the demo data, into one container that starts in a minute. Use them to learn the admin and to test plugins. Do not run a shop on them. For production, the project's own Docker tooling and the composer-based install give you a stateless PHP container in front of a separate database, with persistent volumes for the parts that hold state:

services:
  shop:
    image: your-registry/shopware:latest
    environment:
      - APP_URL=https://shop.example.com
      - DATABASE_URL=mysql://shopware:secret@db:3306/shopware
    volumes:
      - ./files:/var/www/html/files
      - ./media:/var/www/html/public/media
      - ./jwt:/var/www/html/config/jwt
    depends_on:
      - db

The three volumes are the ones people lose: uploaded files, product media, and the JWT keys that sign admin and store API tokens. Lose the JWT directory and every logged-in session and every connected app breaks at once.

Three services turn it from sluggish to fast

A bare Shopware install works, and then a catalogue of 5,000 products with 20 property filters makes category pages crawl. The fix is the same three services every serious install runs. First, OpenSearch or Elasticsearch for product search and listing filters; Shopware falls back to MySQL for both and it shows past a few thousand products. Second, Redis for the HTTP cache, sessions, and the cart, which cuts repeat page loads sharply. Third, and most often forgotten, the workers:

bin/console messenger:consume async --time-limit=3600
bin/console scheduled-task:run

Shopware queues indexing, emails, and imports on a message bus and runs housekeeping as scheduled tasks. By default the admin triggers these from the browser, which means nothing happens overnight and imports stall when nobody is logged in. Run both as supervised processes or as separate containers from day one; half the "Shopware is slow" complaints I have read were a shop with no consumer running.

Headless is a real mode, not a checkbox

Shopware exposes two documented APIs: the Store API for everything a customer does and the Admin API for everything a merchant does. The default Twig storefront is one client of the Store API, and you can replace it entirely with a Nuxt or React front end while keeping the admin, rules, and checkout. This is the structural difference from WooCommerce, where the theme and the store are welded together, and it is why agencies pick Shopware for a shop that also needs to feed a mobile app or a marketplace connector. If you will never build a second front end, the storefront is good and you can ignore all of this.

The extension store is the ecosystem and the trap

Payment providers, shipping integrations, and marketing features arrive as plugins from the Shopware store, and many of the good ones are paid with annual renewals. This is how a free platform becomes a few hundred euros a year, and it is also how upgrades get stuck: each major Shopware version needs each plugin to be updated, and an abandoned plugin can pin you to an old core. Before adopting an extension, check its last release date against the current Shopware version, and prefer the ones from payment providers themselves.

What I'd do

Learn it on Dockware for a week. Go to production only with the composer install in your own image, MariaDB or MySQL 8 on a separate container, Redis, OpenSearch, and both worker processes supervised, on a 4-core box with 8 GB. Keep the plugin count under 10 and audit it before every major upgrade. That setup runs a mid-sized European B2C or B2B shop well, which is who actually runs Shopware. If that list of services reads as more infrastructure than your shop justifies, it is; go back to the ecommerce category and pick something smaller, because a platform you cannot maintain is worse than a modest one you can.