Od 30 października sklepom Adobe Commerce on Cloud z przestarzałymi usługami grozi zawieszenie

30 października 2026 r. Adobe zaczyna egzekwować nową politykę bezpieczeństwa w Adobe Commerce on Cloud. Środowisko, które po tej dacie nadal korzysta z Elasticsearch, MariaDB w wersji 10.5 lub starszej albo RabbitMQ w wersji 3.9 lub starszej, „może mieć zawieszony dostęp do panelu Admin, przy czym sklep pozostaje dostępny, i/lub zawieszony ruch przychodzący, co wyłącza sklep”. Kolejne terminy przypadają w maju 2027 r., a następnie trzeba będzie zaktualizować także starsze wersje samego Magento.

Polityka dotyczy Adobe Commerce on Cloud (PaaS) w wersjach od 2.4.4 do 2.4.9. Nie obejmuje produktu SaaS firmy Adobe ani sklepów hostowanych samodzielnie. W takim przypadku istotna jest krótka sekcja pod koniec artykułu. Podane niżej daty i cytaty sprawdziliśmy na stronach Adobe 20 października 2026 r.

Terminy

Adobe wymaga odejścia od następujących usług:

Dotyczy to każdej wersji Magento, w tym 2.4.8 i 2.4.9, oraz każdego środowiska, nie tylko produkcyjnego.

Wersja Magento ma osobny termin. Sklepy w wersji 2.4.4 lub 2.4.5 muszą do 1 czerwca 2027 r. przejść na 2.4.9 albo migrować do SaaS firmy Adobe. Sklepy w wersji 2.4.6 lub 2.4.7 mają czas do 1 czerwca 2028 r. Dla wersji 2.4.8 i 2.4.9 Adobe nie wyznaczyło terminu. Sklepy w chmurze starsze niż 2.4.4 nie są wymienione w polityce, ale polityka cyklu życia Adobe przewiduje takie samo zawieszenie dla każdej nieobsługiwanej wersji od 1 czerwca 2027 r.

Jeśli używasz wersji 2.4.4 lub 2.4.5, potwierdź terminy z Adobe. Strona polityki podaje dla tych dwóch wersji w jednej tabeli termin 30 października 2026 r. dla wszystkich aktualizacji usług, a w drugiej powyższe daty. Zapytaj o to w zgłoszeniu do pomocy technicznej i uzyskaj odpowiedź na piśmie.

Konsekwencje niedotrzymania terminu

Adobe może zawiesić dostęp do panelu Admin wszystkim użytkownikom przy działającym sklepie, zawiesić ruch, co wyłącza sklep, albo zastosować oba środki. Jeśli po zawieszeniu ruchu środowisko nadal nie spełnia wymagań, „Adobe może zakończyć świadczenie usług chmurowych”, a likwidacja środowiska trwale usuwa wszystkie dane, środowiska i gałęzie. Adobe nie określa, z jakim wyprzedzeniem uprzedzi o którymkolwiek z tych kroków.

Jeśli nie możesz dotrzymać terminu, polityka zaleca, aby „jak najszybciej skontaktować się z zespołem obsługi konta lub Adobe Support” w sprawie „krótkiego przedłużenia”. Nie określa, jak długie może być przedłużenie.

Sprawdź, czego używasz

Potrzebne są dwie informacje: wersja Magento oraz wersja każdej usługi w każdym środowisku.

Wersję Magento widać w prawym dolnym rogu każdej strony panelu Admin, można ją też uzyskać poleceniem bin/magento --version. W przypadku usług polityka Adobe odsyła do Cloud Console: otwórz środowisko i sprawdź każdą usługę na karcie „Containers”, która pokazuje aktualnie działającą wersję.

W planie Pro sprawdzaj działającą usługę, a nie repozytorium. Baza wiedzy Adobe opisuje środowiska Staging i Production, w których zmiany w services.yaml „są ignorowane”, a nadal działają stare wersje. Plik pokazuje, o co poproszono. Działająca usługa pokazuje, co faktycznie masz. Warto też pamiętać, że New Relic nadal nazywa pamięć podręczną „Redis” nawet po przejściu na Valkey, dlatego nie należy ustalać rodzaju usługi na podstawie etykiet w monitoringu.

Przebieg aktualizacji

W planie Pro Adobe samo aktualizuje usługi w środowiskach Staging i Production na podstawie zgłoszenia do pomocy technicznej. Polityka wymaga złożenia go „co najmniej 30 dni przed datą egzekwowania”. Dla terminu 30 października ten moment minął 30 września, więc jeśli zgłoszenie nie zostało jeszcze złożone, należy złożyć je teraz i w tym samym zgłoszeniu zapytać o przedłużenie. Zmiany w środowisku Production wymagają ponadto powiadomienia z wyprzedzeniem co najmniej dwóch dni roboczych, nie licząc weekendów, a w okresach wzmożonego ruchu dłuższego.

W planie Starter strona usług Adobe opisuje tę zmianę jako samoobsługową: scalenie zaktualizowanego pliku .magento/services.yaml z gałęzią produkcyjną aktualizuje środowisko produkcyjne. Późniejsze obniżenie wersji usług nie jest możliwe, dlatego najpierw wykonaj kopię zapasową. Sama polityka nakazuje jednak wszystkim klientom Cloud złożenie zgłoszenia, więc ustal z Adobe, kto wprowadza zmianę w Twoim projekcie.

W obu przypadkach część pracy pozostaje po Twojej stronie:

• najpierw przetestuj aktualizację w środowisku nieprodukcyjnym, co najmniej checkout, wyszukiwanie, koszyk i integracje,
• po zakończeniu prac przez Adobe wykonaj ponowny deploy, który odbudowuje także kolejki RabbitMQ,
• po zmianie OpenSearch wykonaj pełne ponowne indeksowanie,
• zapewnij, aby ktoś z Twojego zespołu lub partnera był dostępny przez całe okno serwisowe w środowisku Production, ponieważ Adobe nie testuje Twojej aplikacji.

Strona usług Adobe zaleca weryfikowanie aktualizacji usług pojedynczo i ostrzega, że „aktualizacje baz danych mają największy wpływ na działanie i wymagają największej ostrożności”. W planie Pro przećwicz całość w środowisku Staging na danych o rozmiarze produkcyjnym. Czas, jakiego to wymaga, jest najlepszym oszacowaniem okna serwisowego w środowisku Production.

Aktualizacja usługi jako aktualizacja Magento

Każda poprawka Magento obsługuje określone wersje usług, wymienione w wymaganiach systemowych Adobe, a Adobe obsługuje wyłącznie podane tam kombinacje. Wymagana wersja usługi może więc nie działać z posiadaną wersją Magento. Z tej tabeli wynikają następujące przypadki:

• Wersje 2.4.4 i 2.4.5 nie działają z PHP 8.2. Każda poprawka obu wersji obsługuje wyłącznie PHP 8.1. Dotrzymanie terminu dla PHP z 31 maja 2027 r. oznacza aktualizację Magento do tego dnia, czyli dzień przed terminem dla wersji z 1 czerwca.
• Wersja 2.4.6 nie obsługuje PHP nowszego niż 8.2, a PHP 8.2 przestaje otrzymywać poprawki bezpieczeństwa 31 grudnia 2026 r., według php.net. Polityka cyklu życia Adobe wskazuje to jako ryzyko w kontekście PCI od końca 2026 r. Jedynym wyjściem jest aktualizacja Magento.
• Starsze poprawki wymagają aktualizacji poprawki przed terminem październikowym. Na przykład OpenSearch 2 wymaga co najmniej 2.4.4-p13 lub 2.4.5-p12, a RabbitMQ 3.13 wymaga 2.4.4-p18. W przypadku starszej poprawki najpierw trzeba przejść na nowszą.
• OpenSearch 3 w wersjach 2.4.6 i 2.4.7 wymaga najnowszej poprawki (2.4.6-p15 lub 2.4.7-p10). Te poprawki wymagają również Valkey zamiast Redis, RabbitMQ 4.3 oraz MariaDB 10.11 lub nowszej, więc przejście na OpenSearch 3 może wymusić wcześniejsze przeprowadzenie także tych zmian. Wcześniejsze poprawki 2.4.6 i 2.4.7 obsługują OpenSearch 2. Czy to wystarczy do dotrzymania terminu 30 października, należy ustalić w zgłoszeniu.
• Przejście ze starej wersji na 2.4.9 wymaga kilku etapów. Żadna pojedyncza poprawka nie obsługuje jednocześnie starych i nowych wersji wszystkich usług, a RabbitMQ trzeba aktualizować stopniowo, wersja po wersji. Zapytaj Adobe, ile okien serwisowych w środowisku Production należy zaplanować.

Dwie zmiany większe, niż się wydaje

Samo Adobe ostrzega, że „przejście z Elasticsearch na OpenSearch oraz z Redis na Valkey to migracje na inne oprogramowanie, a nie aktualizacje wersji”.

Z Elasticsearch na OpenSearch. W Cloud silnik wyszukiwania jest konfigurowany w .magento.env.yaml (SEARCH_CONFIGURATION) oraz w relacjach usług w .magento.app.yaml. Oba miejsca muszą wskazywać nową usługę. Sprawdzenia wymagają też rozszerzenia wyszukiwania. Na przykład ElasticSuite firmy Smile obsługuje OpenSearch 3 dopiero od Magento 2.4.8, więc sklep w wersji 2.4.6 lub 2.4.7, który z niego korzysta, powinien uzgodnić wersję OpenSearch z Adobe przed 30 października.

Z Redis na Valkey. Strona o Valkey Adobe zaleca, aby po przejściu traktować pamięć podręczną jako nową i pustą: sesje mogą nie zostać zachowane, a „użytkownicy zostają wylogowani po zakończeniu migracji”. Usuń starą definicję Redis, ponieważ jeśli dostępne są obie usługi, Magento nadal korzysta z Redis. Najnowsze poprawki wersji od 2.4.5 do 2.4.7 oraz wszystkie poprawki 2.4.8 i 2.4.9 w ogóle nie obsługują już Redis, więc sklep, który na bieżąco instaluje poprawki, przeprowadzi tę zmianę przed terminem z maja 2027 r.

Kroki w zależności od wersji

• Każdy sklep w Cloud, od razu: sprawdź działającą wersję każdej usługi w każdym środowisku. Jeśli dotyczy Cię którykolwiek wiersz z terminem październikowym albo używasz wersji 2.4.4 lub 2.4.5, złóż teraz zgłoszenie do pomocy technicznej. Zapytaj, które terminy Cię dotyczą, ile okien serwisowych w środowisku Production będą wymagać prace, i poproś o przedłużenie, jeśli termin 30 października jest nieosiągalny.
• 2.4.4 i 2.4.5: przejdź na 2.4.9 albo migruj do SaaS firmy Adobe i zakończ prace do 31 maja 2027 r. Zgłoszenia dotyczące usług złóż z dużym wyprzedzeniem przed 1 maja, który jest ostatnim możliwym terminem, a nie punktem wyjścia.
• 2.4.6: rozpocznij teraz aktualizację do 2.4.9, ponieważ PHP 8.2 traci wsparcie w zakresie bezpieczeństwa z końcem 2026 r.
• 2.4.7: przejdź na PHP 8.3, który otrzymuje poprawki bezpieczeństwa do 31 grudnia 2027 r., i zaplanuj aktualizację do 2.4.9 przed tą datą. Termin Adobe to 1 czerwca 2028 r.
• 2.4.8 i 2.4.9: sprawdź powyższą tabelę usług. Termin dla wersji nie został jeszcze wyznaczony. Standardowe wsparcie dla 2.4.8 kończy się 31 maja 2028 r.
• Wersje starsze niż 2.4.4: przejdź na 2.4.9 przed 1 czerwca 2027 r. i zapytaj Adobe, czy dotyczą Cię terminy październikowe. Obsługa OpenSearch zaczyna się od 2.4.4-p13, więc już samo odejście od Elasticsearch wymaga aktualizacji Magento.

Jeśli hostujesz Magento samodzielnie

Ta polityka nie grozi wyłączeniem sklepu hostowanego samodzielnie. Nie obejmuje ona Adobe Commerce on-premises, Magento Open Source ani Mage-OS. To samo oprogramowanie również jednak traci wsparcie: jak podaje firma Elastic na stronie o końcu wsparcia, wsparcie dla Elasticsearch 7.17 zakończyło się 15 stycznia 2026 r., a PHP 8.2 straci je z końcem 2026 r. Nasz wpis o hostingu omawia, którzy dostawcy hostingu nadążają za wymaganiami Adobe.

Alternatywa proponowana przez Adobe

Każdemu terminowi dla wersji towarzyszy druga możliwość: przejście na Adobe Commerce as a Cloud Service, które Adobe nazywa „zalecanym docelowym rozwiązaniem długoterminowym” dla klientów Cloud. Omówienie migracji Adobe jasno pokazuje, że oznacza to budowę od nowa: modyfikacje stają się aplikacjami App Builder, a sklepy są budowane od nowa na Edge Delivery Services. Wersja SaaS nie obsługuje sklepów opartych na Luma. Dla większości sklepów jest to projekt zmiany platformy, a nasz wpis o zmianie platformy lub naprawie omawia, jak porównać tę opcję z aktualizacją.

Aktualizacje wersji i usług tego rodzaju realizujemy w ramach naszej usługi Magento.