---
title: "Jak wybrać hosting dla Magento 2"
description: "Chmura Adobe, wyspecjalizowani dostawcy managed, albo własne AWS lub Hetzner: kto prowadzi którą warstwę, kto nadąża za wymaganiami platformy, co faktycznie zawiera SLA i co wiadomo publicznie o cenach, sprawdzone na stronach dostawców."
author: "Luboš Zápotočný"
published: "2026-08-04"
language: "pl"
canonical: "https://zapolu.com/pl/blog/hosting-dla-magento/"
---

# 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](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements)
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](https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions)),
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](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/prerequisites/search-engine/overview)),
  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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/redis/redis-pg-cache)).
- **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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/configure-cron-jobs):
„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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/message-queues/manage-message-queues);
utrzymanie ich w stabilnym działaniu jest zadaniem dostawcy hostingu lub zespołu. RabbitMQ jest
[zazwyczaj opcjonalny](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/prerequisites/message-brokers/rabbitmq)
oraz
[domyślny dla Bulk API](https://developer.adobe.com/commerce/webapi/rest/use-rest/bulk-endpoints/).
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](https://mage-os.org/get-started/system-requirements)
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](https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview)).
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](https://aws.amazon.com/compliance/shared-responsibility-model/)
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](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en)
(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](https://iapp.org/news/a/european-general-court-dismisses-latombe-challenge-upholds-eu-us-data-privacy-framework/)),
a
[kolejna apelacja Latombe](https://digitalpolicyalert.org/event/35459)
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](https://www.dataprivacyframework.gov/list).
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](https://listings.pcisecuritystandards.org/documents/ThirdPartySecurityAssurance_March2016_FINAL.pdf)).
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](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/architecture/pro-architecture);
jego
[przewodnik po bezpieczeństwie](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/architecture/security)
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](https://www.adobe.com/cc-shared/assets/pdf/legal/terms/enterprise/pdfs/unified-sla-actionabilityaddendum2025oct12.pdf)
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](https://experienceleague.adobe.com/en/docs/commerce/user-guides/product-solutions)
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](https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview):
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](https://business.adobe.com/blog/continued-investment-support-adobe-commerce-on-cloud)
(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](https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy)
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](https://docs.hypernode.com/hypernode-platform/php/supported-php-versions-and-how-to-change-them-on-hypernode.html)),
a changelog datuje
[OpenSearch 3.3 na grudzień 2025 r.](https://changelog.hypernode.com/release-10641-opensearch-3-3-available-on-hypernode/)
oraz
[Valkey 8 na październik 2025 r.](https://changelog.hypernode.com/release-10564-valkey-8-now-available-at-hypernode/),
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](https://www.hypernode.com/en/plans-and-prices/) 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](https://docs.hypernode.com/about-hypernode/about-hypernode/which-cloud-providers-do-we-use.html)
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](https://docs.hypernode.com/about-hypernode/support/emergency-support-outside-office-hours.html),
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](https://www.hypernode-status.com/) jest publiczna,
z widoczną historią incydentów.

**maxcluster** (Paderborn, część
[team.blue od 2023 r.](https://press.team.blue/228140-maxcluster-becomes-part-of-team-blue/))
prowadzi zarządzane klastry failover w niemieckich centrach danych i
[wprost wymienia wsparcie dla Mage-OS i Hyvä](https://maxcluster.de/magento-hosting).
Jej [dokument SLA](https://maxcluster.de/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](https://maxcluster.de/en/roadmap) 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](https://maxcluster.de/preise)
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](https://www.mgt-commerce.com/)). 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](https://www.mgt-commerce.com/magento-hosting/)
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](https://www.mgt-commerce.com/service-level-agreements)
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](https://jetrails.com/december-2025-autopilot-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](https://learn.jetrails.com/) 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](https://jetrails.com/terms-of-service/):
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](https://jetrails.com/magento-hosting/)); dokładne
wyceny wymagają założenia konta.
[Serwery dedykowane](https://jetrails.com/dedicated-servers/) 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](https://jetrails-status.com/) jest publiczna.

**Nexcess**, jeden z najdłużej działających hostingów Magento, jest
teraz sprzedawany przez Liquid Web:
[plany Magento](https://www.liquidweb.com/magento-hosting/) 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](https://www.liquidweb.com/magento/latest-magento-version/)
dostawcy w chwili sprawdzania nadal nazywała 2.4.8 najnowszą wersją
Magento, jedyna dostępna
[strona dokumentacji](https://docs.nexcess.com/hosting/control-panel/whm/php-management/using-the-cloudlinux-php-selector-in-cpanel-and-whm/)
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](https://www.liquidweb.com/policies/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](https://status.nexcess.net/). 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](https://www.cloudways.com/en/support.php) wyłącza
warstwę aplikacji: debugowanie niestandardowego kodu, bezpieczeństwo
na poziomie aplikacji i aktualizacje modułów są poza zakresem. Jej
[changelog](https://www.cloudways.com/en/changelog.php) 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](https://www.cloudways.com/en/support-sla.php)).
Lokalizacja centrum danych jest wybierana na poziomie
bazowego dostawcy;
[strona hostingu Magento](https://www.cloudways.com/en/magento-hosting.php)
wymienia Amsterdam, Frankfurt i Londyn wśród lokalizacji
DigitalOcean.
[Cennik](https://www.cloudways.com/en/pricing.php) 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](https://vshosting.eu/about)) 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](https://vshosting.cz/blog/vshosting-nejvetsi-e-commerce-infrastructure-provider))
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](https://vshosting.eu/references/takoy)
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](https://vshosting.eu/services/managed-servers)
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](https://centuria.pl/en/magento-hosting/) 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](https://help.wedos.cz/otazka/hosting-magento-2/2697/)
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](https://www.websupport.sk/podpora/kb/instalacia-cms-magento-cez-webovu-konzolu/)
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](https://www.ovhcloud.com/pl/web-hosting/magento-hosting/)
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](https://docs.aws.amazon.com/whitepapers/latest/migrating-magento-open-source-adobe-commerce-to-aws/migrating-magento-open-source-adobe-commerce-to-aws.html)
dotyczący Magento nosi baner „This whitepaper is for historical
reference only”,
[moduł Terraform](https://github.com/aws-ia/terraform-adobe-magento),
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](https://github.com/amazon-archives/aws-refarch-magento)
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](https://aws.amazon.com/compute/sla/)). Dostępnych
jest osiem
[regionów europejskich](https://docs.aws.amazon.com/general/latest/gr/rande.html),
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ść](https://community.hetzner.com/tutorials/install-magento-on-managed-server/)
(po niemiecku) dla linii Managed Server oraz
[strona dokumentacji](https://docs.hetzner.com/konsoleh/account-management/managed-server-tutorials/magento/),
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](https://www.hetzner.com/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](https://www.hetzner.com/unternehmen/ddos-schutz/),
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](https://www.hetzner.com/legal/cloud-server/)). 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

| Opcja | Model | Dostępność w SLA | Aktualny stos, według deklaracji | Lokalizacje w UE | Publiczny cennik |
| ------ | ----- | ----------------- | ------------------------ | ------------ | -------------- |
| Chmura Adobe (PaaS) | PaaS od dostawcy platformy | 99,99% (dodatek do SLA) | Od dostawcy platformy | AWS/Azure, wybór klienta | Nie |
| Hypernode | Managed | Brak dokumentu SLA; 99,9–99,95% w dokumentacji | PHP 8.5, OpenSearch 3.3, Valkey 8 | BE; DE przez linię AWS | Tak |
| maxcluster | Managed | 99,99% średnia roczna | PHP 8.5 (roadmapa), Valkey bez wersji | DE | Tak (PDF) |
| MGT-Commerce | Opłata + własny AWS | 99,95%, brak warunków kredytów | Zadeklarowane PHP do 8.4 | Regiony AWS, niesprecyzowane | Opłaty tak, AWS licznikowo |
| JetRails | Managed na AWS | Brak procentu w warunkach | OpenSearch 3.2; PHP-FPM do 8.3 w dokumentacji wsparcia | Niedokumentowane | Tylko widełki |
| Nexcess (Liquid Web) | Managed | 100% tranzytu, 5% kredytów za 15 min | Niezadeklarowane; dokumentacja cPanel sięga PHP 8.3 | Amsterdam | Tak (USD) |
| Cloudways | Zarządzanie serwerem | SLA wyłącznie dla wsparcia | PHP 8.4; OpenSearch 2.19 | Przez wybrane IaaS | Tak |
| vshosting~ | Managed | Nie znaleziono | Niepublikowane | CZ, DE | Ceny wejściowe |
| Centuria | Managed | Nie znaleziono | Wymienia Redis, Elasticsearch | PL, DE | Orientacyjny |
| AWS (samodzielne zarządzanie) | IaaS | Per usługa | Twoje zadanie | 6 regionów UE | Licznikowo |
| Hetzner (samodzielne zarządzanie) | IaaS | 99,9% na zasadzie starań | Twoje zadanie | DE, FI | Tak |

„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](/pl/services/devops/), a tę samą ocenę
stosujemy w ramach naszej [pracy z Magento](/pl/services/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.