Hosting PrestaShop: jakie parametry sprawdzić przed zakupem serwera dla sklepu?
Hosting PrestaShop wybieraj dla konkretnej wersji sklepu, modułów i sposobu pracy. Najpierw sprawdź zgodność PHP, bazy oraz rozszerzeń, następnie zasoby podczas koszyka i importów, a dopiero potem cenę. Pakiet z dużym dyskiem i napisem „e-commerce” nie daje jeszcze pewności, że działają na nim płatności, aktualizacje i zadania integracji. Do decyzji potrzebujesz listy wymagań oraz próby na kopii własnego sklepu.
Porównaj usługi
Dokumentacja PrestaShop 9 odczytana 28.10.2026 rozróżnia między innymi linie 9.0 i 9.1: rekomendowane PHP to odpowiednio 8.4 i 8.5. Nie przenoś rekomendacji dla nowszej linii na starszą instalację bez sprawdzenia tabeli zgodności [1]. Po ustaleniu wersji możesz użyć porównania hostingów do wstępnej selekcji pakietów sklepowych. Brakujący parametr potwierdź u operatora; nie interpretuj pustej rubryki jako spełnionego wymagania.
Opracowanie WebBay, weryfikacja dokumentacji 28.10.2026. To procedura doboru i odbioru środowiska, bez własnych testów wydajności dostawców.

Plan wyboru hostingu PrestaShop
- Macierz wersji i wymagań
- Zasoby dla koszyka, panelu i importów
- Trzy scenariusze obciążenia sklepu
- Próba odbiorowa przed przełączeniem produkcji
- Kopie danych i plan odzyskiwania zamówień
- Koszt i końcowa decyzja zakupowa
Przykład: import towarów w małym sklepie
Hosting PrestaShop sprawdź także podczas zaplanowanego importu produktów. Zanim uruchomisz kopię, zapewnij jej osobny katalog i bazę, ochronę dostępu oraz wyłączenie produkcyjnego SMTP, płatności, kuriera, magazynu, webhooków i zadań. Potrzebne integracje podłącz wyłącznie do ich środowisk testowych. Sam dopisek „test” w zamówieniu nie blokuje wysyłki paczki. Dopiero wtedy wgraj próbny plik z kilkoma towarami, uruchom import i sprawdź ceny, stany oraz log. Złóż kontrolowane zamówienie w trybie testowym i porównaj wynik. Przy błędzie pamięci porównaj wymaganie modułu z limitem procesu PHP, zanim kupisz większy dysk.
Hosting PrestaShop: zgodność wersji sklepu i PHP
Spisz pełny numer PrestaShop, motyw, moduły płatności i dostaw, integrację magazynu oraz dodatki zmieniające koszyk. Wymagania rdzenia są pierwszą warstwą zgodności. Płatny moduł może mieć węższy zakres obsługiwanych wersji niż sam sklep. Potwierdź go w dokumentacji producenta lub u wykonawcy, który odpowiada za utrzymanie danego rozszerzenia. Samo poprawne otwarcie strony głównej nie sprawdza całej transakcji.
W tabeli PrestaShop 9.0 PHP 8.4 jest wersją rekomendowaną, a PHP 8.5 nie jest obsługiwane. Dla PrestaShop 9.1 rekomendowane jest PHP 8.5, a PHP 8.4 pozostaje obsługiwane [1]. To stan dokumentacji w dniu odczytu, a nie bezterminowa recepta dla wszystkich instalacji. Dla sklepu w innej linii sprawdź dokumentację tej linii. Nie zmieniaj globalnego PHP serwera, jeśli utrzymujesz na nim także inne aplikacje.
Dokumentacja wskazuje Apache 2.4 lub nowszy oraz możliwość pracy z Nginx przy właściwej konfiguracji. Dla bazy podaje minimum MySQL 5.7 lub MariaDB 10.2 i zaleca nowszą wersję. Minimum zgodności nie jest zaleceniem uruchamiania dziś starej, nieutrzymywanej gałęzi. Operator powinien zapewnić wspierane środowisko, a Ty musisz sprawdzić zgodność sklepu z konkretnym oferowanym wariantem.
| Wymaganie | Co potwierdzić | Dowód podczas próby |
|---|---|---|
| Wersja PHP | Osobny wybór dla domeny i zgodność rdzenia oraz modułów | Raport środowiska i pełny zakup testowy |
| Baza danych | Wersja, limit rozmiaru, połączeń i importu | Import kopii, zapis zamówienia, filtrowanie katalogu |
| Pamięć skryptu PHP | Rekomendowane minimum memory_limit 512M dla PrestaShop 9 | Brak błędów pamięci przy reprezentatywnym zadaniu |
| Rozszerzenia PHP | Pełna lista z dokumentacji i wymagania modułów | Sprawdzenie środowiska, generowanie miniatur, połączenia integracji |
| HTTPS i reguły serwera | Certyfikat domeny, przekierowania i adresy przyjazne | Otwieranie produktu, koszyka i panelu bez błędów |
| Zadania cykliczne | Dostępność harmonogramu i ograniczenia wykonywania | Zakończona synchronizacja bez narastającej kolejki |
Do listy rozszerzeń PrestaShop zalicza między innymi cURL, DOM, Fileinfo, GD, Intl, Mbstring, OpenSSL, PDO MySQL, SimpleXML i Zip. Nie traktuj tego skrótu jako pełnej specyfikacji: do zgłoszenia dołącz listę z dokumentacji konkretnej wersji i osobne wymagania swoich modułów. Dzięki temu operator odpowie na sprawdzalny zestaw, zamiast potwierdzić ogólne hasło „obsługujemy PrestaShop”.

Rozdziel pamięć skryptu od pamięci całego konta
Wymienione 512M dotyczy rekomendowanego ustawienia memory_limit, czyli ograniczenia pamięci przydzielanej skryptowi PHP. Nie oznacza 512 MB pamięci fizycznej dla całego sklepu ani gwarantowanego zapasu dla wielu procesów. Znaczenie tej dyrektywy wyjaśnia dokumentacja PHP [3]. Zapytaj osobno o RAM konta, równoległe procesy i sposób rozliczania zadań uruchamianych z harmonogramu.
Większa liczba procesów pomaga tylko wtedy, gdy konto ma zasoby do ich obsługi. Jeżeli kilka ciężkich operacji jednocześnie dobije do limitu pamięci lub procesora, samo podniesienie jednego parametru nie usunie ograniczenia. Z drugiej strony większy przydział RAM nie naprawi zewnętrznego API, na którego odpowiedź czeka moduł. Wniosek o dopłacie powinien wynikać z obserwacji konkretnego zadania, nie z pojedynczego dużego numeru w specyfikacji.
Sprawdzając hosting PrestaShop, uwzględnij operacje dyskowe, pojemność bazy i limit liczby plików. Katalog zdjęć wraz z wariantami miniatur może zajmować znacznie więcej miejsca niż oryginalne fotografie. Dodaj przestrzeń na środowisko testowe i operacje administracyjne, na przykład rozpakowanie aktualizacji. Nie zapełniaj konta do ostatniego gigabajta; wymaganą rezerwę określ na podstawie aktualnego zużycia i planowanych prac, a nie uniwersalnego procentu dla każdego sklepu.
Przykład do samodzielnego uzupełnienia: katalog i zdjęcia 12 GB, baza 2 GB, testowa kopia 14 GB oraz archiwa 8 GB dają razem 36 GB. To model, nie pomiar standardowego sklepu. Jeśli limit 50 GB obejmuje także pocztę i pliki tymczasowe, sprawdź je przed uznaniem pozostałych 14 GB za wolny zapas. Osobno ustal, czy kopie operatora wliczają się do przestrzeni konta.
Gdy wybierasz hosting PrestaShop, takie rozdzielenie limitów ułatwia porównanie ofert. W zestawieniu parametrów i warunków hostingów wybierz kandydatów spełniających zakres funkcjonalny, a następnie poproś ich o brakujące limity dla swojego scenariusza. Nazwa technologii albo ocena redakcyjna nie zastępują zgody na potrzebne operacje i potwierdzenia zasobów konkretnego pakietu.
Trzy scenariusze sklepu wymagają różnych prób
1. Niewielki katalog i sporadyczne aktualizacje
Hosting PrestaShop dla małego sklepu może być usługą współdzieloną, jeśli środowisko jest zgodne, a rzeczywista próba nie ujawnia ograniczeń. Sprawdź podstronę produktu z wariantami, obliczenie dostawy i finalizację zakupu. Oceniaj też panel: wyszukanie zamówienia, zmianę stanu i dodanie zdjęcia. Rzadki ruch nie usprawiedliwia braku kopii ani korzystania z niezgodnej wersji PHP.
2. Częste importy i integracja magazynu
W tym scenariuszu najważniejsze zadanie może nie być widoczne dla odwiedzającego. Import aktualizuje bazę, przetwarza obrazy i współpracuje z integracjami. Sprawdź wielkość partii, czas jej zakończenia oraz zachowanie sklepu podczas importu. Ustal z wykonawcą, czy można rozdzielić zadanie na mniejsze części i wykonywać je poza godzinami największej sprzedaży. Nie zakładaj jednak, że nocą serwer zawsze ma nieograniczoną moc.
3. Kampania i wiele operacji w krótkim czasie
Przygotuj test działań, które naprawdę wykonują kupujący, a nie wyłącznie odpytywanie strony głównej. Koszyk, kupon, wybór dostawy, płatność testowa i zmiana dostępności produktu są ważniejsze niż licznik żądań bez kontekstu. Próbę obciążenia uzgodnij z operatorem i wykonawcą na kontrolowanym środowisku. Zapisz konfigurację, liczbę równoległych sesji i kryterium przerwania. Bez takiego pomiaru nie podajemy obietnicy obsługi określonej liczby klientów.

Sprawdzenie działania: poprawne dane przed wynikiem szybkości
Hosting PrestaShop odbieraj na chronionej kopii z wyłączoną prawdziwą wysyłką do klientów, kampaniami oraz płatnościami produkcyjnymi. Nie wystawiaj danych klientów w publicznym podglądzie. Uzgodnij, które integracje mają środowisko testowe, a które należy wyłączyć. Test ma ograniczać ryzyko, a nie tworzyć drugą instancję wykonującą te same zamówienia i synchronizacje co działający sklep.
- Sprawdź produkt prosty i produkt z wariantami, ceny oraz dostępność.
- Otwórz dwa odrębne koszyki i upewnij się, że zawartości oraz dane klientów nie mieszają się.
- Przetestuj kupon, podatek, dostawę i sumę końcową dla reprezentatywnego zamówienia.
- Wykonaj płatność w trybie testowym; sprawdź zapis stanu zamówienia i zachowanie po ponownym powiadomieniu.
- Zweryfikuj obniżenie stanu magazynu oraz komunikat przekazany do integracji.
- Uruchom kontrolowany import i sprawdź, czy kolejka zadań kończy pracę.
- Oceń działanie po wylogowaniu, odświeżeniu danych i wyczyszczeniu właściwego cache.
Cache gotowych stron może przyspieszać katalog, ale nie może utrwalać cudzych danych sesji. Konfigurację koszyka i konta sprawdź dla konkretnego rozwiązania, motywu i modułów. Nie przenoś automatycznie wyjątków z WordPressa. PrestaShop i WooCommerce to inne aplikacje; poradnik hostingu WooCommerce przydaje się przy porównaniu platform, lecz nie jest instrukcją ustawień PrestaShop.
Zapisz wynik każdej operacji i przyczynę odmowy odbioru. Przykładowo: niezgodna wersja modułu płatności, błędy pamięci importu albo brak dostępu do kopii to konkretne problemy do rozwiązania. Nie zastępuj ich ogólnym komentarzem „serwer słaby”. Z takim raportem można ustalić, czy potrzebujesz zmiany konfiguracji aplikacji, wyższego pakietu czy innego rodzaju usługi.
Przed próbą ustal, co oznacza zakończone zadanie
Sam komunikat o zakończeniu importu nie wystarcza. Dla wybranego przykładowego produktu porównaj cenę, dostępność, warianty i zdjęcia przed operacją oraz po niej. Przy aktualizacji stanów sprawdź także towar niedostępny. Wynik powinien odpowiadać danym wejściowym i regułom integracji. Jeśli nie znasz oczekiwanego rezultatu, najpierw ustal go z osobą obsługującą katalog. W przeciwnym razie szybki import może jedynie szybko zapisać błędne dane.
Dla kontrolowanego zamówienia określ kolejność statusów i to, która aplikacja je zmienia. Zapis zamówienia, potwierdzenie płatności testowej, zmniejszenie stanu i wysłanie powiadomienia są oddzielnymi krokami. Błąd jednego z nich może mieć źródło w module lub zewnętrznym systemie. Zapisz czas wystąpienia i konkretny objaw, zamiast wnioskować o zbyt małym RAM z samego niedotarcia wiadomości.
| Zadanie | Oczekiwany rezultat | Dowód do zachowania |
|---|---|---|
| Import kilku wskazanych produktów | Zgodne ceny, stany, warianty i liczba zaktualizowanych rekordów | Zanonimizowany raport integracji i kontrola próbki |
| Koszyk w dwóch sesjach | Niezależne produkty, kupony i dane każdego użytkownika | Opis kroków i obserwowanego zachowania |
| Płatność w trybie testowym | Zgodny status w sklepie i środowisku testowym bramki | Numer operacji testowej bez danych wrażliwych |
| Aktualizacja na kopii | Panel i kluczowe funkcje działają po zmianie | Wersje przed/po i lista sprawdzonych operacji |
| Przywrócenie kopii | Spójny zestaw plików i bazy w osobnym środowisku | Czas kopii oraz wynik kontroli przykładowych danych |
Próbka powinna obejmować elementy istotne dla danego sklepu, a nie przypadkowe rekordy. Sklep z wariantami rozmiarów i kolorów wymaga innej kontroli niż katalog prostych produktów. Jeśli działa integracja magazynu, wskaż system będący źródłem stanów. Nie uruchamiaj na kopii dwóch niezależnych procesów aktualizujących te same dane produkcyjne. Uzgodnienie źródła danych jest częścią poprawności próby, nie parametrem kupowanego serwera.
Oddziel powtarzalny problem zasobów od pojedynczego błędu
Gdy zadanie nie kończy się poprawnie, zachowaj warunki próby: wersję sklepu, rozmiar partii, uruchomione w tym samym czasie operacje i komunikat błędu. Nie publikuj haseł, kluczy API ani danych klientów w zgłoszeniu. Przekaż wykonawcy lub operatorowi tylko potrzebny wycinek przez uzgodniony kanał. Jeśli błąd wymaga pełniejszego dostępu, zakres i czas powinny odpowiadać konkretnej diagnozie.
Następnie zmieniaj jeden warunek naraz. Możesz uzgodnić mniejszą partię importu albo osobną godzinę jego wykonania, a potem porównać rezultat. Nie zmieniaj równocześnie pakietu, wersji PHP, motywu i modułu płatności, bo trudno ustalić, co rozwiązało problem. Z kolei prawidłowa próba pojedynczego importu nie stanowi gwarancji obsługi dowolnej kampanii sprzedażowej.
W decyzji zakupowej rozdziel problem wykryty, przyczynę potwierdzoną i rozwiązanie do sprawdzenia. Przykład zapisu: import zatrzymuje się z komunikatem pamięci; wykonawca sprawdza zużycie i wymagania konkretnego zadania; operator potwierdza limit procesu oraz konta. Dopiero po diagnozie ustalasz zmianę konfiguracji lub planu. Nie przedstawiaj przypuszczenia jako dowodu, że dany dostawca jest niewydajny albo że VPS na pewno naprawi aplikację.
Kopia ma obejmować pliki i bazę oraz umożliwiać powrót
Dokumentacja PrestaShop rozdziela kopię plików i bazy [2]. Same pliki nie zawierają aktualnych zamówień, a sama baza nie odtwarza zdjęć, modułów i motywu. Ustal częstotliwość obu części i sposób przywrócenia zgodnego zestawu. Nie przechowuj archiwum w publicznie dostępnym katalogu sklepu. Dodatkową kopię poza kontem zabezpiecz przed nieuprawnionym dostępem.
Zanim zamówisz hosting PrestaShop, odpowiedz, ile danych możesz zaakceptować jako utracone od ostatniej kopii i ile czasu możesz czekać na odzyskanie sklepu. To dwie odrębne decyzje. Codzienna kopia może być niewystarczająca dla aktywnej sprzedaży, nawet jeśli odtworzenie zajmuje krótko. Częstsza kopia nie rozwiąże natomiast problemu, gdy nikt nie potrafi jej sprawnie przywrócić. Uzgodnij wymagania z osobą odpowiedzialną za obsługę zamówień.
Sprawdź odtworzenie w osobnym środowisku, bez nadpisywania działającego serwisu. Ustal też sposób uzgodnienia zamówień powstałych po dacie przywracanej kopii. Powrót do starej bazy bez takiej kontroli może cofnąć informacje o sprzedaży i dostępności. Przy zmianie operatora potrzebujesz końcowej synchronizacji oraz jasnej decyzji, gdzie w danym momencie zapisują się nowe dane.
Organizację przełączenia i kontroli poczty przedstawia nasz plan migracji strony i skrzynek. Część dotycząca WordPressa nie zastępuje procedury migracji PrestaShop; użyj jej jako listy ogólnych punktów organizacyjnych i ustal szczegóły swojej platformy z wykonawcą. Nie łącz migracji, dużej aktualizacji sklepu i zmiany PHP bez osobnego planu wycofania każdego kroku.

Hosting PrestaShop: odpowiedzialność i koszt całej usługi
Wyślij operatorowi specyfikację, na którą da się odpowiedzieć
Zamawiając hosting PrestaShop, przygotuj krótkie zgłoszenie: „Utrzymuję PrestaShop w wersji …, motyw … i moduły płatności … . Katalog zajmuje … GB, baza … GB, a import obejmuje … rekordów w jednej partii. Potrzebuję środowiska testowego, PHP zgodnego z tą wersją oraz możliwości uruchamiania zadań integracji. Proszę potwierdzić limity konkretnego pakietu, sposób rozbudowy i zakres pomocy podczas błędu aplikacji”. Wielokropki zastąp własnymi informacjami; nie wysyłaj danych klientów ani haseł.
Odpowiedzi zapisuj w tej samej macierzy. Jeśli jeden dostawca podaje limit konta, a drugi limit procesu PHP, pozostaw je w osobnych wierszach. Poproś o wyjaśnienie nieporównywalnych jednostek, zamiast przeliczać je według domysłów. Do warunków odbioru dopisz, czy możesz przeprowadzić uzgodniony test w okresie próbnym oraz kto pomoże odczytać wykresy przekroczenia zasobów. Sam dostęp do konta demonstracyjnego nie potwierdza parametrów kupowanego planu.
Instalacja gotowego sklepu a budowanie go ze źródeł
Dokumentacja osobno opisuje dodatkowe wymagania wersji deweloperskiej, w tym narzędzia Composer i Node.js [1]. Nie przenoś całej listy narzędzi budowania na wymagania każdej gotowej instalacji produkcyjnej. Jeśli wykonawca potrzebuje kompilować zasoby motywu albo instalować zależności na serwerze, dopisz tę potrzebę do specyfikacji. Ustal, czy wykonuje to lokalnie, w osobnym środowisku budowania, czy na hostingu i czy operator dopuszcza taki proces.
Rozdzielenie tych sytuacji zapobiega kupowaniu VPS wyłącznie dlatego, że dokumentacja projektu wymienia narzędzie używane przez programistów. Jednocześnie nie zakładaj dostępności SSH lub konkretnych narzędzi na każdym współdzielonym koncie. Wykonawca powinien wskazać wymagane polecenia i wersje, a dostawca potwierdzić ich obsługę dla wybranego wariantu. Takie uzgodnienie jest częścią odbioru, nie obietnicą wynikającą z nazwy „hosting pod sklep”.
Hosting może zapewniać działanie infrastruktury i podstawową pomoc, a nie naprawę dowolnego modułu. Zapytaj, kto diagnozuje błąd aplikacji, kto wykonuje aktualizacje i kto podejmuje decyzję o odtworzeniu. Gdy sklep prowadzi agencja, przyda się uzgodniony kanał zgłoszeń i dostęp techniczny w minimalnym potrzebnym zakresie. „Wsparcie 24/7” samo w sobie nie definiuje terminu rozwiązania problemu.
Planując hosting PrestaShop, uwzględnij w koszcie usługę serwera, odnowienie, domenę, pocztę, potrzebne licencje oraz administrację. Przy VPS dochodzą obowiązki dotyczące systemu, monitoringu i kopii, chyba że odpowiedni zakres obejmuje umowa zarządzania. VPS nie jest automatycznie konieczny dla każdego PrestaShop i nie daje nieograniczonej wydajności. Uzasadnieniem jest potrzeba kontroli środowiska albo zasobów, której nie spełnia sprawdzona usługa współdzielona.
Terminy oraz kompletny rachunek opisuje przewodnik kosztu hostingu przez 36 miesięcy. Dla sklepu dopisz koszt pracy i skutki przerwy; oznacz je jako własne założenia, a nie pewne straty. Dzięki temu możesz porównać wyższą opłatę za potrzebny zakres obsługi z ceną samodzielnej administracji, zamiast zestawiać tylko dwa promocyjne abonamenty.
Ostatecznie wybierz hosting PrestaShop, który spełnia macierz zgodności, kończy reprezentatywne zadania i pozwala odzyskać dane w uzgodnionym czasie. Poproś o potwierdzenie braków przed zapłatą. Gdy masz wyniki próby i zakres odpowiedzialności, wróć do porównania ofert przed zakupem hostingu dla sklepu. Ofertę traktuj jako kandydata do sprawdzenia na własnym projekcie, bez gwarancji wynikających z samej nazwy pakietu.
Źródła i data weryfikacji
Źródła i tabelę zgodności ponownie sprawdzono 29.10.2026. Tabela wersji dotyczy dokumentacji PrestaShop 9, a nie wszystkich historycznych instalacji. Scenariusze, macierz pytań, plan testu i przykład przestrzeni są opracowaniem WebBay. Nie wykonywaliśmy pomiarów wydajności ani migracji u opisywanych operatorów.




2 komentarze
Możliwość komentowania została wyłączona.