Jak wybrać hosting dla Magento 2

Hosting Magento sprzedaje się w formie planów i specyfikacji, ale decyzja, która za tym stoi, dotyczy odpowiedzialności. Ktoś musi łatać system operacyjny, aktualizować OpenSearch, gdy zmieniają się wymagania Adobe, utrzymywać działanie crona i konsumentów kolejki oraz reagować, gdy sklep przestaje działać. Każdy poziom hostingu to inna odpowiedź na pytanie, kim jest ten ktoś.

Ten artykuł przedstawia wymagania Magento wobec infrastruktury, podaje listę kontrolną do oceny hostingu i stosuje ją do trzech poziomów: własnej chmury Adobe, wyspecjalizowanych dostawców managed Magento (w tym czeskich i polskich dostawców dostępnych w tym regionie) oraz samodzielnie zarządzanej infrastruktury na AWS lub Hetznerze. Każdy fakt dotyczący dostawcy zweryfikowano na podstawie podanego źródła w dniu 3 sierpnia 2026 r.; tam, gdzie czegoś nie udało się zweryfikować, jest to zaznaczone.

Czego Magento wymaga od serwera

Adobe publikuje tabelę przetestowanych kombinacji dla każdej linii wersji i wprost określa jej zakres: „Adobe wspiera wyłącznie kombinacje wymagań systemowych wymienione w poniższych tabelach”. Dla Magento 2.4.9 (wydanego 12 maja 2026 r., zgodnie ze stroną wydanych wersji), tabela dla wdrożeń on-premises wskazuje OpenSearch 3, MariaDB 12.3, MySQL 8.4, PHP 8.5, RabbitMQ 4.3, Valkey 9, Varnish 8 i nginx 1.30. Tabela dla wersji 2.4.8-p5 pozostaje o krok w tyle: PHP 8.4 i 8.3, przy czym Elasticsearch 8 nadal figuruje obok OpenSearch 3, oraz Valkey 8.1. Trzy zmiany w tych tabelach decydują o tym, czy hosting jest aktualny:

• OpenSearch jest wymagany; Elasticsearch znika z tabeli testowanych kombinacji. „Od Adobe Commerce 2.4 wszystkie instalacje muszą być skonfigurowane tak, by korzystać z Elasticsearch lub OpenSearch jako rozwiązania do wyszukiwania w katalogu” (wymagania wstępne dla wyszukiwarki), a tabela dla 2.4.9 wymienia wyłącznie OpenSearch 3, bez żadnego wiersza dla Elasticsearch. Elasticsearch 7.17 zakończył wsparcie 15 stycznia 2026 r., zgodnie ze stroną wymagań systemowych Adobe.
• Valkey zastąpił Redis. Tabele dla 2.4.9 i 2.4.8-p5 nie zawierają w ogóle wiersza dla Redis, najnowsze poprawki linii od 2.4.5 do 2.4.7 oznaczają Redis jako „niewspierany”, wskazując w to miejsce Valkey, a dokumentacja Adobe dotycząca cache stwierdza: „Począwszy od Adobe Commerce 2.4.9, Valkey oficjalnie zastąpił Redis w narzędziach CLI” (dokumentacja cache stron Redis).
• MySQL 8.0 zakończył wsparcie 30 kwietnia 2026 r., a strona wymagań systemowych Adobe zaleca dotkniętym tym liniom wydań przejście na MariaDB.

Poza samą tabelą dwa wymagania operacyjne wykluczają zwykły hosting współdzielony. Cron jest obowiązkowy: „Commerce zależy od prawidłowej konfiguracji zadań cron dla wielu ważnych funkcji systemowych, w tym indeksowania. Brak prawidłowej konfiguracji oznacza, że Commerce nie będzie działać zgodnie z oczekiwaniami”, a lista funkcji zależnych od crona obejmuje wszystkie transakcyjne wiadomości e-mail. Konsumenci kolejek to procesy robocze, które cron domyślnie restartuje partiami; utrzymanie ich w stabilnym działaniu jest zadaniem dostawcy hostingu lub zespołu. RabbitMQ jest zazwyczaj opcjonalny oraz domyślny dla Bulk API. Hosting, który oferuje PHP i MySQL, ale nie potrafi uruchomić OpenSearch, cache opartego na Valkey, Varnisha i kilku procesów roboczych, nie jest w stanie uruchomić Magento tak, jak testuje je Adobe, niezależnie od tego, co napisano na stronie z planami. Mage-OS publikuje własne wymagania z niższymi minimami (PHP 8.3 i nowsze, OpenSearch 2 i nowsze, z Elasticsearch i Redis nadal na liście), ale struktura stosu pozostaje taka sama: wyszukiwarka, cron i procesy robocze są obowiązkowe bez względu na to, jaką dystrybucję się uruchamia.

Lista kontrolna: kto czym zarządza i co jest zapisane na piśmie

Kto zarządza którą warstwą. Te trzy poziomy dzielą pracę inaczej. W PaaS Adobe to Adobe zarządza infrastrukturą, a sprzedawca nadal „zarządza kodem aplikacji, aktualizacjami, łataniem, konfiguracją infrastruktury w hostowanym środowisku Adobe” (przewodnik migracji Adobe). U wyspecjalizowanego dostawcy managed hosting zarządza stosem, a zespół sprzedawcy lub agencja obsługuje samo Magento. Przy infrastrukturze zarządzanej samodzielnie model współodpowiedzialności AWS jest jednoznaczny: klienci wdrażający EC2 „odpowiadają za zarządzanie systemem operacyjnym gościa (w tym aktualizacje i poprawki bezpieczeństwa)” oraz za wszystko powyżej. Prace na poziomie aplikacji, czyli aktualizacje Magento, rozszerzenia i kod niestandardowy, nigdy nie przechodzą na żaden hosting, niezależnie od poziomu. Pytanie brzmi wyłącznie, gdzie przebiega ta granica.

Czy hosting nadąża za platformą. Powyższe wymagania zmieniają się z każdym cyklem wydań, a hostingi pozostają w tyle o udokumentowane, sprawdzalne wartości. Porównaj opublikowane wersje komponentów danego hostingu (PHP, OpenSearch, Valkey) z aktualną tabelą Adobe; poniższe profile odnotowują, co deklaruje każdy dostawca, a brak deklaracji dotyczącej wersji to powód, by zapytać przed podpisaniem umowy. Opóźnienie ma największe znaczenie przy budowie nowego sklepu lub aktualizacji do najnowszej linii; hosting zgodny z przetestowanymi kombinacjami dla linii wydania, na której się znajdujesz, pozostaje wspierany aż do końca wsparcia tej linii.

Co faktycznie zawiera dokument SLA. Kilku dostawców reklamuje wskaźniki dostępności, których nie zawierają ich własne strony prawne; niezgodności, które znaleźliśmy, są odnotowane w profilach. Sprawdź, jak wygląda system kredytów, kto weryfikuje awarię i w jakim terminie trzeba zgłosić roszczenie. Ograniczenie strukturalne jest wszędzie takie samo: to sam dostawca zgłasza awarię, ogłasza własną konserwację, a jego własne logi decydują o roszczeniu. Kredyty są ograniczone, w przeczytanych przez nas warunkach do wysokości miesięcznej opłaty lub mniej; każdy znaleziony limit jest odnotowany poniżej. Publiczną stronę statusu z widoczną historią incydentów wciąż warto przejrzeć, a do każdej znalezionej podajemy link.

Operacje stojące za stroną z planami. Cztery pytania odróżniają specjalistę Magento od zwykłego dostawcy managed hostingu, a żaden z profilowanych poniżej dostawców nie publikuje na nie pełnych odpowiedzi. Jak plan radzi sobie ze szczytem sprzedażowym: czas realizacji zmiany rozmiaru, autoskalowanie i jakie planowanie pojemności na sezon szczytowy jest w to wliczone. Ile czasu zajmuje przywrócenie danych na zbiorze o rozmiarze produkcyjnym i czy odzyskiwanie bazy danych jest możliwe w dowolnym punkcie w czasie czy tylko z migawek; harmonogram kopii zapasowych to łatwiejsza połowa pytania. Jak deploy wpływa na działający sklep: okno konserwacyjne czy atomowe przełączenie, i czy staging odpowiada produkcji. Wreszcie, w planach wieloserwerowych, który węzeł odpowiada za cron i konsumentów kolejki i jak są one odizolowane od ruchu sieciowego. Warto zadać wszystkie cztery pytania; odpowiedzi rzadko są publiczne.

Lokalizacja danych i podstawa prawna dla dostawców z USA. Transfery danych z UE do USA opierają się obecnie na Ramach ochrony danych UE-USA (EU-US Data Privacy Framework), przyjętych 10 lipca 2023 r.; Sąd Ogólny UE podtrzymał je w sprawie ze skargi Latombe 3 września 2025 r. (raport IAPP), a kolejna apelacja Latombe do Trybunału Sprawiedliwości (sprawa C-703/25 P, wniesiona 31 października 2025 r.) wciąż była w toku, gdy sprawdzaliśmy to w sierpniu 2026 r. Udział amerykańskiego dostawcy w ramach można zweryfikować na oficjalnej liście DPF. Praktyczna kontrola jest prostsza: czy dostawca dokumentuje pisemnie, w jakim centrum danych działa Twój sklep? Profile odnotowują, kto to robi.

Podział odpowiedzialności PCI. Dostawca hostingu jest zewnętrznym dostawcą usług (TPSP) w rozumieniu PCI DSS, a dodatek Rady z 2016 r. dotyczący zapewnienia zgodności przez strony trzecie stwierdza wprost: „Korzystanie z TPSP nie zwalnia jednak podmiotu z ostatecznej odpowiedzialności za jego własną zgodność z PCI DSS…” (dodatek PCI SSC). Poproś dostawcę hostingu o jego Attestation of Compliance dla dostawcy usług i zachowaj macierz pokazującą, które wymagania pokrywa; obowiązki leżące po stronie sprzedawcy pozostają Twoim zadaniem.

Jak wygląda cennik na każdym poziomie. Wyspecjalizowani dostawcy managed sprzedają plany stałe, konfiguracje rozliczane według zużycia (JetRails) albo, w przypadku MGT-Commerce, opłatę za zarządzanie plus własny rachunek za chmurę; infrastruktura zarządzana samodzielnie jest rozliczana licznikowo; Adobe działa wyłącznie sprzedażowo. Wszystkie poniższe kwoty podane są netto, bez VAT, który firmy z UE i tak rozliczają metodą odwrotnego obciążenia; dostawcy rozliczający się w USD doliczają koszty wymiany walut i ekspozycję walutową, których nie mają dostawcy rozliczający się w EUR. Profile cytują opublikowane kwoty dosłownie; tam, gdzie dostawca nie publikuje żadnych, jest to zaznaczone, i nie szacujemy sum całkowitych dla konfiguracji rozliczanych licznikowo.

Chmura Adobe: rozwiązanie własne dostawcy platformy

Adobe Commerce na infrastrukturze chmurowej to PaaS samego dostawcy platformy, działający na AWS lub, w przypadku Pro, na Azure, zgodnie z jego dokumentacją architektury Pro; jego przewodnik po bezpieczeństwie dokumentuje dołączoną sieć CDN Fastly z ochroną DDoS i WAF, godzinne kopie zapasowe środowiska produkcyjnego oraz to, że instancje produkcyjne mogą działać w większości regionów AWS, przy czym to klient wskazuje, gdzie znajduje się środowisko produkcyjne. Jednolity dodatek SLA Adobe (obowiązujący od 12 października 2025 r.) definiuje zobowiązanie jako „99,99% dla hostowanej przez Adobe infrastruktury środowiska produkcyjnego”. Ten poziom ograniczają dwie rzeczy. Licencjonowanie: to produkt Adobe Commerce, a strona rozwiązań produktowych Adobe klasyfikuje wdrożenia open source jako zarządzane przez klienta i samodzielnie hostowane; Mage-OS, o którym dokumentacja Adobe w ogóle nie wspomina, również nie ma tam żadnej ścieżki. Cennik: nie jest nigdzie publiczny; liczby krążące w sieci to szacunki stron trzecich, których nie powtarzamy.

Adobe zmienia też charakter tej warstwy. W 2025 r. wprowadziło Adobe Commerce as a Cloud Service (SaaS) i publikuje przewodnik migracji: SaaS blokuje kod aplikacji rdzeniowej i przenosi personalizację do API i App Builder, a jego promowany storefront działa na Edge Delivery Services, obowiązkowym dla sklepów Luma, podczas gdy istniejące sklepy PWA i headless mogą zostać zachowane. Dla sklepu Luma to przejście jest przebudową architektury, a nie zwykłą migracją. Blog Adobe twierdzi, że PaaS nie ma zaplanowanego końca wsparcia (strona nie wczytała się nam; ta informacja pochodzi z jej zindeksowanej treści). Wiążący termin znajduje się gdzie indziej: od 1 czerwca 2027 r. polityka cyklu życia Adobe pozwala jej wymusić aktualizacje wersji w środowiskach chmurowych i wycofywać instancje działające na niewspieranych wydaniach. Sprzedawcy, którzy wybrali PaaS ze względu na stabilność, powinni rozważyć tę politykę przed odnowieniem umowy.

Wyspecjalizowani dostawcy managed

Hypernode (Amsterdam, część team.blue) to najbardziej aktualna platforma managed spośród sprawdzonych przez nas. Jej dokumentacja wymienia PHP 8.5 jako w pełni wspierany (dokumentacja wersji PHP), a changelog datuje OpenSearch 3.3 na grudzień 2025 r. oraz Valkey 8 na październik 2025 r., wciąż bez żadnej deklaracji dotyczącej Valkey 9. Narzędzia dla Magento są natywne: hypernode-deploy z szablonem Magento 2, staging przez Brancher na planach Falcon. Opublikowany cennik zaczyna się od 129 EUR miesięcznie za najmniejszy węzeł produkcyjny Falcon, do 3462 EUR za największy, bez VAT; linia Eagle oparta na AWS kosztuje od 672 EUR do 33 409 EUR. Zastrzeżenia dotyczą kwestii operacyjnych. Nie znaleziono publicznego dokumentu SLA z procentowym wskaźnikiem dostępności; istniejące liczby znajdują się na stronie dokumentacji i są przypisane dostawcom infrastruktury: 99,9% dla linii Falcon i 99,95% dla infrastruktury AWS stojącej za Eagle. Bezpłatne wsparcie działa w godzinach biurowych (9:00 do 18:00 CET/CEST); zgodnie z dokumentacją wsparcia awaryjnego, pomoc poza godzinami biurowymi jest bezpłatna, gdy przyczyną jest awaria po stronie Hypernode, a w przeciwnym razie jest rozliczana w stawce od 100 do 200 EUR za pierwszą godzinę, zależnie od poziomu SLA, a potem godzinowo w tej samej stawce. Linia Falcon działa w Belgii; Frankfurt wymaga linii Eagle. Strona statusu jest publiczna, z widoczną historią incydentów.

maxcluster (Paderborn, część team.blue od 2023 r.) prowadzi zarządzane klastry failover w niemieckich centrach danych i wprost wymienia wsparcie dla Mage-OS i Hyvä. Jej dokument SLA gwarantuje „99,99% Verfügbarkeit” sprzętu i sieci jako średnią roczną (maksymalnie 52 minuty przestoju rocznie) i zobowiązuje się do pierwszej reakcji w ciągu 30 minut, całą dobę, przez swoją linię awaryjną. Rutynowe wsparcie i prace serwisowe odbywają się w godzinach biurowych. Jej publiczna mapa drogowa datuje PHP 8.5 na grudzień 2025 r., a Valkey na listopad 2025 r., bez podania numeru wersji; nie znaleziono wyraźnej deklaracji dotyczącej OpenSearch 3. Cennik jest publiczny, ale znajduje się w niemieckojęzycznym cenniku PDF datowanym na 12 stycznia 2026 r. Klastry zaczynają się od 19 EUR miesięcznie za najmniejszą parę failover, choć ten wejściowy klaster (1 CPU, 2 GB RAM) nie spełnia wymagań stosu Magento 2.4, a klaster o rozmiarze odpowiednim dla Magento kosztuje znacznie więcej, do czego dochodzi jeszcze poziom zarządzanego SLA sięgający do 350 EUR miesięcznie (Enterprise). Zgodnie z tym samym cennikiem praca serwisowa wykraczająca poza SLA jest rozliczana licznikowo (wsparcie dewelopera 30 EUR za 15 minut w godzinach biurowych, 50 EUR poza nimi), a automatyczne skanowanie pod kątem złośliwego oprogramowania staje się płatnym dodatkiem dla niższych poziomów od 1 stycznia 2027 r.

MGT-Commerce (Berlin) sprzedaje inny model: opłatę za zarządzanie doliczaną do infrastruktury AWS działającej na własnym koncie AWS klienta, „rozliczaną osobno na własnym koncie AWS w celu zapewnienia pełnej przejrzystości” (strona główna). Taka struktura oznacza rzeczywistą przejrzystość kosztów i przenośność, a jednocześnie oznacza dwa rachunki. Stos obejmuje Varnish, Valkey lub Redis, OpenSearch lub Elasticsearch oraz RabbitMQ; strona hostingu podaje PHP od 8.1 do 8.4, wciąż bez żadnej deklaracji dotyczącej platformy PHP 8.5, mimo że jej własny blog omawia wymagania 2.4.9. Opłaty za zarządzanie są publiczne (od 149 EUR miesięcznie za pojedynczy serwer, 1499 EUR za autoskalowanie), choć nazwy poziomów i kwoty różnią się między stroną główną a podstronami z planami. Jeśli chodzi o dostępność, strona główna reklamuje jednocześnie 99,99% i 99,95%, a strona przeglądu SLA stwierdza „gwarancję dostępności sieci na poziomie 99,95%” bez systemu kredytów, wyłączeń czy procedury zgłaszania roszczeń; nie znaleziono publicznej strony statusu. Zapis „15 Min Response Time” to marketingowa średnia dostawcy; strona SLA zobowiązuje się do poniżej 24 godzin dla ogólnych wskazówek oraz reakcji awaryjnych od poniżej 8 godzin na najniższym poziomie do poniżej 30 minut na najwyższym poziomie autoskalowania.

JetRails (Illinois) jest skoncentrowany na Magento i udostępnia środowiska AWS dla pojedynczego klienta przez swój portal AutoPilot, z dostępem roota i rozliczeniem godzinowym; jego changelog z grudnia 2025 r. odnotowuje OpenSearch 3.2 i domyślne udostępnianie Magento w wersji „v2.4.8.2”. Na jego stronach marketingowych ani w changelogach nie ma macierzy wsparcia PHP; artykuł na jego portalu wsparcia dokumentuje przełączalne wersje PHP-FPM aż do 8.3. Marketing JetRails obiecuje 99,99% dostępności (we fragmentach wyników wyszukiwania na jego stronach), czego jednak nigdy nie stwierdzają warunki świadczenia usług: warunki obiecują „komercyjnie uzasadnione starania”, a kredyty są ograniczone do dwóch tygodni opłat miesięcznie, zgodnie z prawem stanu Illinois. Publiczny cennik to widełki („Nasze standardowe konfiguracje mieszczą się w przedziale 100-2500 USD miesięcznie” na stronie Magento); dokładne wyceny wymagają założenia konta. Serwery dedykowane są opisane jako centra danych w USA, a żadna strona marketingowa nie dokumentuje możliwości wyboru regionu w UE (FAQ JetRails Cloud wskazuje, że konfiguracje wieloregionalne są wspierane, bez podania nazw regionów), co sprawia, że lokalizacja danych w UE to kwestia do ustalenia na piśmie przed podpisaniem umowy. Strona statusu jest publiczna.

Nexcess, jeden z najdłużej działających hostingów Magento, jest teraz sprzedawany przez Liquid Web: plany Magento działają na infrastrukturze Nexcess, od 74 USD miesięcznie w cenniku dla najmniejszego planu (najpierw pokazywana jest cena promocyjna), wyłącznie w USD. Każdy plan zawiera Varnish, Redis i dedykowany kontener OpenSearch; platforma zapewnia staging, SSH i Git. Problem tkwi w tym, jak aktualny jest stos i jak jasno jest to opisane: własna strona referencyjna dostawcy w chwili sprawdzania nadal nazywała 2.4.8 najnowszą wersją Magento, jedyna dostępna strona dokumentacji wymieniająca wersje PHP (dla linii cPanel) kończy się na 8.3, a dla samych planów Magento nie znaleziono żadnej deklaracji dotyczącej PHP, OpenSearch ani Valkey. Strona marketingowa reklamuje „99,99% uptime guaranteed”, podczas gdy strona SLA nie zawiera takiej wartości. Jej sekcja dotycząca Nexcess, do której odsyła infrastruktura planów (przy podpisywaniu umowy warto potwierdzić, który schemat obowiązuje), obiecuje 100% nieprzerwanego tranzytu, z kredytami w wysokości 5% opłaty miesięcznej za każde 15 minut potwierdzonego przestoju ponad pierwsze 15 minut w miesiącu, ograniczonymi do wysokości miesięcznej opłaty, przy czym roszczenia trzeba zgłosić w ciągu siedmiu dni, a weryfikacja odbywa się na podstawie własnych logów dostawcy. Obecność na kontynencie UE to jedna lokalizacja, Amsterdam, zgodnie ze stroną statusu. Niemal dwie dekady historii Magento i zmiany marki od czasu fuzji z Liquid Web są widoczne na jej stronach.

Cloudways (część DigitalOcean) to budżetowa opcja managed, którą wybierają mniejsze sklepy, a sprawdzalne fakty uzasadniają ostrożność. Zarządza serwerem, a jej zakres wsparcia wyłącza warstwę aplikacji: debugowanie niestandardowego kodu, bezpieczeństwo na poziomie aplikacji i aktualizacje modułów są poza zakresem. Jej changelog datuje wsparcie dla Magento 2.4.8 na lipiec 2025 r., a PHP 8.4 na wrzesień 2025 r., i wymienia dostępne wersje wyszukiwarki, kończąc na OpenSearch 2.19, podczas gdy przetestowane kombinacje Adobe dla 2.4.8-p5 i 2.4.9 wskazują wyłącznie OpenSearch 3. Nie ma tam w ogóle SLA dla infrastruktury; jedyne opublikowane SLA obejmuje konsolę wsparcia i stwierdza, że nie odnosi się do dostępności dostawców chmury (SLA wsparcia). Lokalizacja centrum danych jest wybierana na poziomie bazowego dostawcy; strona hostingu Magento wymienia Amsterdam, Frankfurt i Londyn wśród lokalizacji DigitalOcean. Cennik jest publiczny i naprawdę niski, od 11 USD miesięcznie na DigitalOcean. Dla sklepu, który mieści się na jednym serwerze, i zespołu, który sam odpowiada za Magento, może się to sprawdzić na linii wydania, na której aktualnie działasz; dopóki Cloudways nie udostępni OpenSearch 3, aktualizacja do 2.4.8-p5 lub 2.4.9 wykracza poza przetestowane kombinacje Adobe. Specjalizacja nie sięga dalej niż provisioning.

Opcje czeskie i polskie

vshosting~ (Praga, część Grupy Contabo według jej strony o firmie) jest, według własnej deklaracji, dostawcą infrastruktury managed najczęściej wykorzystywanym przez czeski i słowacki e-commerce; ten opis samego siebie (na jej własnej stronie) oraz jej listy klientów to twierdzenia dostawcy, bez żadnego niezależnego pomiaru, jaki udało nam się znaleźć. Co jest udokumentowane: opublikowane studium przypadku dotyczące Magento dla Takoy („rozwiązanie hostingowe dopasowane do Magento”), własne centrum danych w Pradze plus lokalne niemieckie centra danych, z których korzysta, oraz cennik serwerów managed od 217 EUR za serwer miesięcznie, z zastrzeżeniem drobnym drukiem, że ceny startowe zakładają dziesięć lub więcej serwerów w umowach na 36 miesięcy; „reakcja administratora w ciągu 60 sekund” telefonicznie oraz monitoring 24/7 to sformułowania dostawcy. Nie publikuje się cennika pakietów Magento dla poszczególnych planów, a strony, które sprawdziliśmy, nie podają ani procentu SLA, ani wersji stosu.

Centuria (Poznań) to najwyraźniejszy polski wyspecjalizowany dostawca managed Magento, jakiego udało nam się znaleźć: dedykowana strona hostingu Magento z serwisem 24/7, wskazanymi z nazwy centrami danych (Equinix Frankfurt, Beyond i Talex w Poznaniu) oraz referencjami od Castoramy i sklepu CD PROJEKT RED (publikowane przez dostawcę). Opublikowany stos wymienia Varnish, Redis i Elasticsearch; Elasticsearch 8 wciąż mieści się w przetestowanych kombinacjach Adobe dla 2.4.8-p5, Redis już nie, więc lista komponentów na tej stronie zasługuje na bezpośrednie pytanie. Cennik jest wyłącznie orientacyjny: miesięczne utrzymanie od około 1500 do 2000 zł według jej własnej strony.

Poszukiwania pozwoliły też ustalić, których dostawców wykluczyć. WEDOS, którego hosting działa teraz pod marką VEDOS, odpowiedział w swojej bazie wiedzy w 2019 r., że dla Magento poleca VPS, a uruchamianie go na ich webhostingu nazywa problematycznym, i nie znaleźliśmy tam nowszych wskazówek dotyczących Magento. Websupport dokumentuje wyłącznie to, że Magento można zainstalować na hostingu współdzielonym mimo ograniczeń, a u Forpsi, Master Internet ani cyber_Folks nie znaleziono żadnej strony hostingu Magento. Nie znaleźliśmy żadnego wyspecjalizowanego dostawcy managed Magento z siedzibą na Słowacji w ogóle; słowackie sklepy w tym segmencie kupują od dostawców czeskich, polskich, niemieckich lub międzynarodowych. Polska strona Magento OVHcloud istnieje, ale poleca samodzielnie zarządzane VPS-y lub serwery dedykowane, co stawia ją wśród opcji samodzielnie zarządzanych.

Samodzielne zarządzanie: AWS i Hetzner

Uruchomienie Magento na czystej infrastrukturze chmurowej to realna opcja z jasną ceną: Twój zespół sam staje się dostawcą managed. W AWS zarządzane usługi pokrywają część stosu (Aurora dla bazy danych, OpenSearch Service, ElastiCache, Amazon MQ), a tabela wymagań Adobe zawiera wiersze specyficzne dla AWS właśnie dla nich, plus dla S3; wiersz ElastiCache Adobe wymienia jako przetestowaną kombinację „ElastiCache 7.1 for Redis OSS (enhanced). Valkey 8 is available.”, a CloudFront pokrywa CDN poza tabelą. Varnish, PHP-FPM, cron i procesy robocze kolejki pozostają na EC2, którym administrujesz, a konfiguracja multi-AZ dodaje własną pracę specyficzną dla Magento: współdzielone przechowywanie mediów, współdzielone sesje i cache, failover bazy danych oraz jednego właściciela dla crona i konsumentów. Czego AWS nie ma, to gotowej do produkcji, natywnej ścieżki dla Magento: jego whitepaper dotyczący Magento nosi baner „This whitepaper is for historical reference only”, moduł Terraform, do którego linkuje, jest oznaczony jako beta i niezalecany do produkcji (ostatni commit w sierpniu 2025 r.), oryginalna strona Magento Quick Start już nie istnieje, a repozytorium architektury referencyjnej nie było ruszane od kwietnia 2018 r. i jest zarchiwizowane. SLA są tam ustalane dla każdej usługi odrębnie i mają wyłącznie formę kredytów: 99,99% dla EC2 wymaga wdrożenia multi-AZ, a pojedyncza instancja ma 99,5% (SLA compute). Dostępnych jest osiem regionów europejskich, sześć z nich w państwach członkowskich UE, w tym Frankfurt. Koszt jest rozliczany licznikowo w wielu pozycjach; nie podajemy żadnych sum całkowitych, ponieważ realistyczna suma wymaga zamodelowania własnego ruchu.

Hetzner to unijny punkt odniesienia pod względem kosztu i nie dokumentuje na temat Magento niemal niczego: brak strony produktowej, brak aplikacji instalowanej jednym kliknięciem, brak macierzy wersji. Najbliżej tego są tutorial napisany przez społeczność (po niemiecku) dla linii Managed Server oraz strona dokumentacji, która do niego linkuje; tutorial dokumentuje same trudności, czyli samodzielnie instalowany OpenSearch, który wymaga zatwierdzonego przez wsparcie procesu Java, bez udokumentowanego RabbitMQ. Na linii Managed Server Magento pozostaje samodzielnie instalowanym obejściem bez żadnego wsparcia produktowego za sobą. To, co Hetzner sprzedaje, to wydajna, dobrze wyceniona infrastruktura i nic ponad to: instancje cloud od 5,99 EUR miesięcznie z adresem IPv4 za 2 vCPU i 4 GB (strona cloud; ceny renderowane są po stronie klienta), serwery dedykowane powyżej tego, centra danych w UE w Niemczech i Finlandii (istnieją też lokalizacje w USA i Singapurze), darmowa ochrona przed DDoS na poziomie sieci, oraz SLA dla cloud w formule „komercyjnie uzasadnionych starań o zapewnienie miesięcznej dostępności na poziomie 99,9%”, z kredytami wypłacanymi w Cloud Credits, ograniczonymi do wysokości miesięcznej faktury za dany serwer i zgłaszanymi w ciągu 14 dni (warunki cloud). Na Hetznerze za cały stos Magento, a także za dyżur, odpowiadasz sam. Sklep na jednym z powyższych planów managed, od 129 EUR miesięcznie w Hypernode albo 149 EUR w MGT-Commerce, częściowo płaci właśnie za pracę operacyjną opisaną w tej sekcji.

Zestawienie porównawcze

„Nie znaleziono”, „niezadeklarowane”, „niepublikowane” i „niedokumentowane” odnotowują wyłącznie nasze własne poszukiwania na podanych stronach; „Twoje zadanie” oznacza, że sprzedawca sam instaluje i pilnuje stosu. „Aktualny stos” porównuje opublikowane wersje komponentów każdego dostawcy z tabelami Adobe dla 2.4.8-p5/2.4.9 (PHP 8.3–8.5 w zależności od linii, OpenSearch 3, lub, tylko dla 2.4.8-p5, Elasticsearch 8, Valkey). Wszystko według stanu na 3 sierpnia 2026 r.

Wybór między poziomami

Zacznij od licencji. Sklepy na Magento Open Source i Mage-OS nie mogą kupić chmury Adobe, więc ich wybór ogranicza się do wyspecjalizowanego dostawcy managed albo własnej infrastruktury. Licencja Adobe Commerce otwiera wszystkie trzy poziomy: własna chmura Adobe, z jej SLA i polityką wymuszonej aktualizacji od 2027 r., to po prostu jedna opcja więcej obok wyspecjalizowanych dostawców, z których kilku hostuje też Adobe Commerce.

Między wyspecjalizowanym dostawcą a własną chmurą decydującym czynnikiem jest Twój zespół. Wyspecjalizowany dostawca managed jest wart swojej ceny, gdy nikt w zespole nie powinien śledzić wersji OpenSearch ani pełnić dyżuru; powyższe porównanie zawęża się wtedy do tego, kto jest aktualny, kto spisuje swoje SLA na piśmie i kto dokumentuje Twoje centrum danych. Na podstawie opublikowanych dowodów Hypernode najściślej śledzi platformę, przy czym maxcluster i JetRails są aktualne w części stosu, a milczą co do reszty; maxcluster dokumentuje niemieckie centra danych, a vshosting swoją własną lokalizację w Pradze, podczas gdy w MGT-Commerce dane znajdują się w dowolnym regionie AWS, jaki uruchomisz. Samodzielnie zarządzany AWS albo Hetzner jest lepszym wyborem, gdy zdolny zespół już istnieje, a sklep potrzebuje albo ekonomii skali, albo topologii, jakiej nie oferuje żaden plan; kosztuje to trwałe zaangażowanie części zespołu, i ten koszt nie pojawia się na żadnej fakturze.

Niezależnie od tego, w którą stronę wskazuje porównanie, migracja jest osobnym projektem z osobnym rachunkiem: synchronizacja mediów w skali katalogu, ponowne indeksowanie wyszukiwarki na nowym stosie, przeniesienie stanu crona i kolejki, przełączenie TLS i DNS oraz okno zamrożenia, które musi ominąć szczyt sprzedażowy. Zaplanuj budżet migracji, zanim porównasz ceny planów; tańszy plan plus migracja może kosztować więcej niż odnowienie u obecnego dostawcy.

Konkretnie dla rynku czeskiego, słowackiego i polskiego lokalni dostawcy managed mają przewagę w zakresie języka i lokalizacji danych, ale publikują mniej: brak stałych planów Magento, ceny orientacyjne lub warunkowe, brak procentów SLA na sprawdzonych przez nas stronach i brak wersji stosu do porównania. Poproś na piśmie o SLA, cenę, okres obowiązywania umowy i okres wypowiedzenia; rabat związany z 36-miesięcznym okresem umowy, jak w cenach wejściowych vshosting, jest częścią ceny. Wśród dostawców międzynarodowych maxcluster i Nexcess publikują umowne warunki SLA razem ze swoimi cenami, a większość publikuje przynajmniej ceny; lokalnego dostawcę można poprosić, by dorównał temu na piśmie.

Hosting to jeden z trzech obszarów, które obejmuje nasza usługa DevOps, a tę samą ocenę stosujemy w ramach naszej pracy z Magento: która warstwa pasuje, czy obecny hosting wciąż spełnia tabelę wymagań Adobe i ile kosztowałaby migracja, gdyby nie spełniał. Niezależnie od tego, kto Cię hostuje, śledzenie tej tabeli to zadanie, które ktoś musi wziąć na siebie.