Der Magento-Server-Stack 2026: PHP, OpenSearch, Valkey, Varnish

Der Magento-Server-Stack hat sich zwischen 2025 und 2026 stärker verändert als in den Jahren davor. Redis wurde von Valkey abgelöst, OpenSearch 3 wurde zur maßgeblichen Suchmaschine, ActiveMQ Artemis kam als Alternative zu RabbitMQ hinzu, und 2.4.9 wechselte auf PHP 8.5. Wenn Sie Magento Open Source oder Adobe Commerce auf eigener Infrastruktur betreiben, umfasst Ihr Upgrade-Plan jetzt auch die Plattform unter der Anwendung.

Dieser Artikel fasst die offiziellen Anforderungen für 2.4.9 und den neuesten Patch von 2.4.8 zusammen, erklärt, was sich geändert hat, und zeigt, wie Sie den Stack ohne Rätselraten konzipieren und dimensionieren.

Release-Kontext

Laut Adobes Lifecycle-Richtlinie erschien Adobe Commerce 2.4.9 am 12. Mai 2026, mit Support bis zum 31. Mai 2029. Adobe Commerce 2.4.8 erschien am 8. April 2025, mit Support bis zum 31. Mai 2028. Patch-Releases (zum Beispiel 2.4.8-p5) aktualisieren auch ihre getesteten Abhängigkeitsversionen; prüfen Sie daher immer die Zeile für genau den Patch, den Sie einsetzen möchten.

Adobe ist hier strikt. Laut der Seite mit den Systemanforderungen unterstützt Adobe nur die aufgeführten Kombinationen – als Beispiel wird genannt, dass 2.4.9 mit MariaDB 12.3 getestet ist. Sie sollten MariaDB daher vor dem Upgrade auf 2.4.9 aktualisieren.

Offizielle Anforderungen: 2.4.9 vs. 2.4.8-p5 (On-Premises)

Die folgende Tabelle gibt die On-Premises-Systemanforderungen von Adobe mit Stand vom 18. September 2026 wieder.

Bei Adobe Commerce on Cloud Infrastructure nennt das Cloud-Template für 2.4.9 MariaDB 12.3 (empfohlen) oder 11.8 und enthält keine Varnish-Zeile, da die CDN-Ebene von Fastly gestellt wird. Die Serviceversionen in der Cloud können von On-Premises abweichen. Cloud-Projekte sollten sich daher an der Cloud-Tabelle orientieren und an services.yaml.

Was sich geändert hat – Komponente für Komponente

PHP 8.5

Laut den Release Notes zu 2.4.9 wird PHP 8.5 vollständig unterstützt, PHP 8.4 ist nur für Upgrade-Zwecke zulässig und für den Produktivbetrieb nicht empfohlen, PHP 8.2 und 8.3 werden nicht mehr unterstützt. Damit ist das PHP-Upgrade Teil des 2.4.9-Projekts. Prüfen Sie jede Drittanbieter-Extension auf Kompatibilität mit PHP 8.5 und mit der Magento-Version.

Die Software-Empfehlungen von Adobe gelten weiterhin: OPcache aktivieren, PHP-Erweiterungen auf die von Magento benötigten beschränken und keine Debug-Erweiterungen im Produktivbetrieb einsetzen. Die von Adobe für eigene Tests vorgeschlagenen OPcache-Werte sind:

opcache.memory_consumption=512
opcache.max_accelerated_files=60000
opcache.consistency_checks=0
opcache.validate_timestamps=0
opcache.enable_cli=1
realpath_cache_size=10M
realpath_cache_ttl=7200

Valkey ersetzt Redis

Redis taucht in den Anforderungen für aktuelle Patch-Releases nicht mehr auf. Laut den Release Notes zu 2.4.9 wurde die Unterstützung für Valkey 9.x eingeführt – ausgelöst durch das Support-Ende von Redis 7.2 und geänderte Lizenzbedingungen –, mit CLI-Parität zu Redis. Auch die Valkey-Cache-Dokumentation von Adobe besagt, dass Valkey ab 2.4.9 sowie ab den Patch-Releases nach 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 und 2.4.8-p4 für die Cache-Konfiguration erforderlich ist.

Ab 2.4.9 verwendet die CLI valkey als Backend-Namen. Unter 2.4.8 und älter richten Sie die bestehenden Redis-Optionen auf einen Valkey-Server aus, da Valkey protokollkompatibel ist.

# 2.4.9: default cache, page cache (if not using Varnish) and sessions on separate DBs
bin/magento setup:config:set --cache-backend=valkey \
  --cache-backend-valkey-server=127.0.0.1 --cache-backend-valkey-db=0
bin/magento setup:config:set --page-cache=valkey \
  --page-cache-valkey-server=127.0.0.1 --page-cache-valkey-db=1
bin/magento setup:config:set --session-save=valkey \
  --session-save-valkey-host=127.0.0.1 --session-save-valkey-db=2

# 2.4.8 and earlier: same Redis options, Valkey server
bin/magento setup:config:set --session-save=redis \
  --session-save-redis-host=127.0.0.1 --session-save-redis-db=2

Mit 2.4.9 wurde die Cache-Schicht außerdem von Zend Cache auf Symfony Cache umgestellt – so steht es sowohl in den Release Notes als auch in der Valkey-Dokumentation. Individueller Code, der direkt mit dem Cache-Backend kommuniziert, muss getestet werden.

OpenSearch 3

OpenSearch 3 ist die aufgeführte Suchmaschine sowohl für 2.4.9 als auch für die aktuellen 2.4.8-Patches. Elasticsearch 8 wird nur noch für 2.4.8 aufgeführt. Auf der Adobe-Seite steht außerdem, dass der Support für Elasticsearch 7.17 am 15. Januar 2026 endete. Wenn Sie noch Elasticsearch einsetzen, planen Sie den Wechsel zu OpenSearch vor oder zusammen mit Ihrem nächsten Upgrade.

Datenbank: MariaDB oder MySQL 8.4

Für 2.4.9 sind MariaDB 12.3 und MySQL 8.4 die getesteten Versionen. Adobe weist darauf hin, dass der Support für MySQL 8.0 am 30. April 2026 endete, und empfiehlt Kunden mit 2.4.4 bis 2.4.7 den Wechsel auf eine kompatible MariaDB-Version. Auf AWS ist Aurora MySQL aufgeführt als 8.0.mysql_aurora.3.12 oder die neueste verfügbare Version.

Message Queues: RabbitMQ und ActiveMQ Artemis

Für 2.4.9 sind sowohl RabbitMQ 4.3 als auch ActiveMQ Artemis 2 aufgeführt. Die Release Notes bezeichnen Apache ActiveMQ Artemis als empfohlenen langfristigen Message Broker und verweisen auf Risiken durch das Support-Ende von RabbitMQ 4.1. Wenn Sie heute RabbitMQ einsetzen, ist ein Upgrade innerhalb der unterstützten Versionen der kurzfristige Weg; bei neuen Setups sollten Sie Artemis prüfen. In jedem Fall sollten Consumer über einen Prozessmanager oder per Cron laufen, statt sie bei Bedarf starten zu lassen.

Varnish 8

Varnish 8 ist für 2.4.9 und 2.4.8-p5 aufgeführt (frühere 2.4.8-Patches nannten 7.6 oder 7.7). Die Performance-Dokumentation von Adobe empfiehlt Varnish als Full Page Cache im Produktivbetrieb. Exportieren Sie die VCL aus dem Admin, setzen Sie die Purge-ACL auf Ihre Magento-Hosts und registrieren Sie die Varnish-Hosts für das Purging:

bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2
bin/magento setup:config:set --http-cache-hosts=10.0.0.21:6081,10.0.0.22:6081

Webserver: nginx

nginx 1.30 ist der aufgeführte Webserver für 2.4.9 und 2.4.8-p5. Apache 2.4 stand in den On-Premises-Tabellen früherer Releases, ist aber weder für 2.4.8-p3 und neuer noch für 2.4.9 aufgeführt. Magento enthält weiterhin nginx.conf.sample, einen sinnvollen Ausgangspunkt. Betreiben Sie PHP über PHP-FPM.

Composer 2.10

Composer 2.10 ist für 2.4.9 und 2.4.8-p5 aufgeführt. Legen Sie die Composer-Version in Ihrem CI-Image fest, damit Builds reproduzierbar sind.

Empfohlene Architektur

Für einen Produktiv-Shop, der wachsen soll, beschreiben die Software-Empfehlungen von Adobe eine Basis: nginx und PHP-FPM, eine Datenbank, OpenSearch, Varnish, eine Cache-Instanz für Sessions und eine separate Instanz für den Standard-Cache, die nicht mit dem Page Cache geteilt wird. Ein typischer Aufbau:

• Edge: CDN und TLS-Terminierung vor Varnish.
• Cache-Ebene: Varnish als Full Page Cache, mit genug Arbeitsspeicher für Ihre meistbesuchten Seiten.
• Applikationsebene: ein oder mehrere zustandslose nginx- + PHP-FPM-Knoten mit gemeinsamem Medienspeicher (NFS oder Object Storage wie S3, das Adobe für AWS aufführt).
• Admin und Cron: bei größeren Shops hält ein separater Knoten für Admin-Traffic, Cron und Queue-Consumer die Hintergrundarbeit von den Anfragen der Kunden fern.
• Datenebene: MariaDB oder MySQL (managed oder selbst gehostet), OpenSearch, Valkey für den Cache, Valkey für Sessions sowie RabbitMQ oder ActiveMQ Artemis.

Ein Single-Server-Setup reicht für kleine Kataloge und wenig Traffic aus, solange dieselben Dienste darauf laufen. Die Aufteilung wird wichtig, sobald eine Last (Indexierung, Importe, Cron) mit dem Checkout um CPU-Ressourcen konkurriert.

Grundsätze der Dimensionierung (ohne erfundene Benchmarks)

Adobe veröffentlicht Faustregeln statt fester Servergrößen – der richtige Ansatz, denn jeder Shop ist anders. Aus den Hardware-Empfehlungen von Adobe:

• CPU: ein Kern kann etwa zwei (teilweise bis zu vier) ungecachte Commerce-Anfragen bedienen. Die Formel von Adobe lautet N[Cores] = (N[Expected Requests] / 2) + N[Expected Cron Processes]. Es zählen nur ungecachte Anfragen – Ihre Cache-Trefferquote bestimmt also direkt die Anzahl der benötigten Kerne.
• PHP-Speicher: etwa 256 MB für reine Storefront-Webknoten, 1 GB für den Admin bei großem Katalog und 2 GB bei einem Single-Server-Shop oder einem Build-Server.
• Datenbankspeicher: der verfügbare Arbeitsspeicher sollte mindestens annähernd die Hälfte der Datenmenge in der Datenbank betragen.
• Varnish: genug Arbeitsspeicher für Ihre beliebtesten Seiten.
• Cache-Speicher: genug für alle Caches außer dem Page Cache. Hauptfaktor ist der Block Cache, der mit der Anzahl der SKUs multipliziert mit den Store Views wächst.
• Sessions: dimensionieren Sie die Session-Instanz danach, wie lange Sessions bestehen bleiben sollen, und nach Ihrer Strategie für Warenkorbabbrüche.
• Netzwerk: sorgen Sie für ausreichend Bandbreite zwischen den Webknoten und den entfernten Cache-Servern, denn Magento kommuniziert ständig mit dem Cache.

Zur Anwendung ermitteln Sie die maximalen ungecachten Anfragen pro Sekunde aus Ihren Access-Logs oder Ihrem APM, messen die aktuelle Größe von Datenbank und Cache und führen vor großen Verkaufsaktionen Lasttests auf einer Staging-Kopie durch. Echte Zahlen aus Ihrem eigenen Shop schlagen jede Herstellertabelle.

Reihenfolge des Upgrades

1. Prüfen Sie jede Extension auf Kompatibilität mit 2.4.9 und PHP 8.5.
2. Aktualisieren Sie zuerst die Dienste, die beide Versionen unterstützen: OpenSearch 3, Valkey, Varnish 8, RabbitMQ 4.3, nginx 1.30, Composer 2.10.
3. Migrieren Sie die Datenbank auf einer Staging-Kopie auf MariaDB 12.3 oder MySQL 8.4 und testen Sie.
4. Stellen Sie PHP zusammen mit dem Code-Upgrade auf Magento 2.4.9 auf 8.5 um und führen Sie die vollständige Regressionstest-Suite aus.
5. Indexieren Sie neu, wärmen Sie die Caches auf und überwachen Sie die Fehlerlogs nach dem Go-live genau.

Häufig gestellte Fragen

Kann ich Redis mit Magento 2.4.9 weiter betreiben?

Redis ist in den Anforderungen für 2.4.9 nicht aufgeführt, und Adobe unterstützt nur die aufgeführten Kombinationen. Valkey ist auf Kompatibilität ausgelegt, daher ist die Migration meist ein Austausch des Dienstes plus Konfigurationsänderungen – testen Sie sie aber auf Staging.

Wird Apache noch unterstützt?

Apache 2.4 steht in den Adobe-Tabellen für ältere Releases, ist aber weder für 2.4.8-p3 und neuer noch für 2.4.9 aufgeführt. Für eine unterstützte Konfiguration bei aktuellen Releases verwenden Sie nginx.

Kann ich 2.4.9 mit PHP 8.4 betreiben?

Die Release Notes von Adobe erlauben PHP 8.4 nur für Upgrade-Zwecke und empfehlen es nicht für den Produktivbetrieb. Planen Sie den Betrieb mit PHP 8.5 ein.

Brauche ich ActiveMQ Artemis?

Nicht sofort. RabbitMQ 4.3 ist für 2.4.9 aufgeführt. Adobe bezeichnet Artemis als empfohlenen langfristigen Broker – es lohnt sich also, ihn für neue Infrastruktur in Betracht zu ziehen.

Quellen

• https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements
• https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9
• https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy
• https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/valkey/valkey-pg-cache
• https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/valkey/valkey-session
• https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/hardware
• https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/software
• https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/varnish/configure-varnish-commerce
• https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/varnish/use-varnish-cache