Shopware Server Requirements: Specs & Setup

Shopware server requirements at a glance

Shopware 6.7 needs PHP 8.2 or higher, MySQL 8.0.17 or newer or MariaDB 10.11 or newer, at least 4 GB RAM (8 to 16 GB recommended), Composer 2.2+, Node.js 20 LTS, and roughly 10 GB of free disk. A quad-core CPU and NGINX or Apache 2.4 complete a production-ready stack.

These are the numbers the installer checks before it runs. The values below follow the official Shopware system requirements for the current 6.7 release. Shopware 6.7 raised the PHP floor and dropped older versions, so a spec sheet from a year ago is already out of date; the Shopware 6.7 update guide documents the exact changes. Where the documentation gives one figure, we split it into what boots the software and what actually holds up in production.

Read the table as two shops. The minimum column installs Shopware and runs a demo catalog. The recommended column keeps a real store fast once traffic, plugins, and background jobs pile on. The difference between those two columns is where most performance complaints start.

PHP requirements and extensions

Shopware 6.7 requires PHP 8.2, 8.3, or 8.4 with a `memory_limit` of at least 512 MB and a fixed set of extensions including gd, curl, intl, pdo_mysql, mbstring, and zip. PHP 7.x and 8.1 are no longer supported and will block installation on the current release.

The extension list is not a suggestion. The official Shopware documentation states plainly that "the following PHP extensions must be active", and a single missing extension aborts the installer rather than warning you later. Check them before you touch anything else:

• `ctype`, `curl`, `dom`, `fileinfo`, `gd`, `iconv`, `intl`, `json`, `libxml`, `mbstring`, `openssl`, `pcre`, `pdo`, `pdo_mysql`, `phar`, `simplexml`, `xml`, `zip`, `zlib`
• `memory_limit` at 512 MB is the documented floor. For imports or plugin-heavy setups, 1024 MB or more prevents the most common failures.
• Enable OPcache and the JIT compiler on PHP 8.3+ for a measurable drop in response time under load.

Database requirements

Shopware runs on MySQL 8.0.17 or newer, or MariaDB 10.11 or newer. Avoid the known-incompatible builds: MySQL 8.0.20 and 8.0.21, and MariaDB 10.11.5 and 11.0.3. More important than the brand is how you size the InnoDB buffer pool, which caches your working set in RAM.

Both engines are officially supported, so the choice is rarely dramatic. MariaDB 10.11+ tends to be slightly leaner in memory handling, while MySQL 8.0+ is the more common default on managed hosting and extremely stable. Whichever you pick, set `innodb_buffer_pool_size` to hold your active catalog, because a database that reads from disk on every request will feel slow no matter how many CPU cores you throw at it.

The incompatible builds are worth calling out because they fail quietly. MySQL 8.0.20 and 8.0.21 shipped a regression that breaks Shopware's queries, and MariaDB 10.11.5 and 11.0.3 carry their own known issues. Pin your database to a version outside those ranges before you migrate, not after you spend an afternoon chasing a phantom bug.

Hardware and performance: RAM, CPU, disk

Plan 4 GB RAM as an absolute floor and 8 to 16 GB for production, a quad-core CPU, and SSD or NVMe storage. Requirements scale with catalog size, traffic, and whether you run services like Redis or OpenSearch on the same machine. The type of traffic matters as much as the volume.

The forum question "how much RAM do I need" has no single answer, because hardware demand tracks three variables: number of products, concurrent visitors, and the depth of your integrations (ERP, PIM, search, AI). Three profiles cover most shops.

Starter and niche shops

Under 1,000 products and fewer than 500 visitors a day, on a standard theme with few plugins, run 4 to 8 GB RAM, 2 vCPU, and NVMe storage. Never HDD. Shared hosting can technically work here, but once the message queue and background workers kick in, a small managed VPS is the more stable entry point.

Scaling shops with marketing traffic

At 10,000+ products with regular campaigns and marketplace connections, plan 16 to 32 GB RAM and 4 to 8 dedicated cores. At this size the database becomes the bottleneck, so Shopware Caching with Redis for sessions and app cache stops being optional. OpenSearch for product search follows close behind.

AI-ready and enterprise shops

High API load from a headless frontend, mobile app, or live AI features changes the profile again. Here single-thread CPU performance matters more than raw RAM, because PHP processes each request on one core. The reason is simple: an AI query that inspects the live cart cannot be cached, so every interaction becomes real compute rather than a cache hit.

Notice the last two rows. On-premise AI, where you host models and vector search yourself, forces you to scale hardware massively. An external, API-based AI service does the opposite: the compute happens off your server, so a strong web server with high PHP concurrency is enough. That single architectural choice can move you two rows up or down this table.

Web server and software stack

Shopware supports NGINX (recommended) or Apache 2.4, both behind a valid SSL certificate, plus Composer 2.2+ and Node.js 20 LTS for the build toolchain. Redis 7.0+ is listed as optional in the docs but is effectively mandatory for sessions and cache on any production shop.

NGINX generally delivers static assets and cached pages faster than Apache, while Apache is easier to configure with per-directory rules. Either works. A valid certificate is non-negotiable, and getting Shopware SSL right also unlocks HTTP/2, which matters for the many small asset requests a Shopware storefront makes.

1. Web server: NGINX with HTTP/2 (recommended) or Apache 2.4.
2. TLS: a valid SSL certificate, ideally with HTTP/2 or HTTP/3 enabled.
3. Build tools: Composer 2.2+ for dependencies, Node.js 20 LTS for storefront and administration builds.
4. Cache and search: Redis 7.0+ for sessions and app cache, OpenSearch 1.0+ once product search slows on MySQL.

This page is the spec reference, not the setup walkthrough. If you want the step-by-step install flow, from Composer to the first admin login, follow our dedicated Shopware installation guide instead.

Minimum vs recommended: what you actually need

Minimum specs run a demo or dev store. A live shop with real traffic needs the recommended tier: 8 to 16 GB RAM, a quad-core CPU, NVMe SSD, and proper PHP tuning to stay fast under load. The gap between those two columns is where most "why is my shop slow" tickets come from.

The point of a minimum is that Shopware boots, not that it performs. A shop on 4 GB RAM with no Redis will answer a single tester in milliseconds and then stall the moment a marketing email lands 200 visitors on it at once. Treat the minimum as a passing installer check, and the recommended tier as the actual buying spec.

Shopware's own system requirements documentation is blunt about the target: it recommends a "Quad-core or higher" CPU with 8 GB of RAM as the baseline and 16 GB "recommended", especially once you run Redis and OpenSearch alongside PHP on the same box. That is the spec you buy against, not the floor the installer accepts.

Choosing hosting that meets these requirements

Shared hosting rarely meets Shopware requirements under load. Managed Shopware hosting or cloud hosting that guarantees PHP 8.2+, adequate RAM, NVMe storage, and Redis is the reliable choice for production shops. The real decision is how much of the stack you want to run yourself.

Three routes cover almost everyone. Shared hosting is cheap but usually blocks the SSH access and background workers Shopware 6 needs. Managed Shopware Hosting hands you a pre-tuned stack with Redis and OpenSearch already configured, so you trade some control for reliability. Shopware Cloud Hosting goes further and abstracts the server entirely, which fits teams without a sysadmin. For a side-by-side of providers, see our comparison of the best Shopware hosting providers.

Preparing your shop for AI-ready performance

Beyond raw specs, a fast, well-resourced Shopware server is the foundation for AI features like product consultation that depend on low latency to convert. An external, API-based AI service keeps the heavy computation off your own server, so you scale conversations without scaling hardware.

The distinction is concrete. On-premise AI runs models and vector search on your machine and drives CPU and RAM through the roof; an external service turns each interaction into a single outbound API call, so your server only needs stable outbound networking and enough PHP concurrency to keep those calls open. This is exactly why AI product consultation is delivered as a hosted service rather than something you install.

The Pooldoktor case study shows what a fast, well-provisioned setup enables. Their AI product advisor Franz handles over 1,100 conversations a month, answers in 13 seconds on average, and generates 112 EUR of revenue per conversation, for a measured +18.75% higher revenue per user and a 33x return on investment. None of that works if the server behind it stalls under load.

FAQ