Hosting PrestaShop: wymagania i konfiguracja serwera

Hosting to fundament, na którym stoi sklep

Uruchamialiśmy PrestaShop praktycznie na każdym istniejącym poziomie hostingu: na tanich współdzielonych serwerach cPanel odziedziczonych po klientach, na VPS-ach w Hetzner i OVH, na maszynach dedykowanych w centrach danych oraz na biurowym TrueNAS, który obsługuje samą witrynę mypresta.rocks. Po ponad dziesięciu latach takiej praktyki nasze stanowisko jest proste, żadne cache'owanie, optymalizacja obrazów ani strojenie modułów nie uratuje sklepu, który tkwi na zbyt słabym lub źle skonfigurowanym hostingu. Najpierw należy zadbać o solidny fundament, a wtedy wszystko, co budowane jest powyżej, staje się łatwiejsze.

Ta strona celowo prezentuje konkretne stanowisko. To miejsce, do którego skierowalibyśmy klienta pytającego „na czym powinienem hostować?”, zanim cokolwiek podpisze.

Rodzaje hostingu, w kolejności od najbardziej odpowiednich zastosowań

Tani hosting współdzielony (około 3-15 USD/miesiąc)

Sklep dzieli serwer z setkami innych. Otrzymuje się cPanel lub DirectAdmin, zablokowaną konfigurację PHP i brak dostępu root. Te dobre (zdarzało nam się je spotkać) pozwalają wybrać aktualną wersję PHP, włączyć OPcache i nie przeładowują dysków. Te złe robią dokładnie odwrotnie.

Co się zyskuje: niski rachunek miesięczny, pocztę w cenie, ktoś inny łata system operacyjny.
Z czego trzeba zrezygnować: z hałaśliwych sąsiadów losowo zaniżających czasy odpowiedzi, z dostępu SSH w planach podstawowych, z Redis, z Varnish, z PHP w wersjach, których nie da się wybrać, oraz ze współdzielonego adresu IP, który inny lokator może wpisać na czarną listę w imieniu sklepu.

Wystarczający dla zupełnie nowego sklepu poniżej 500 produktów, o niskim ruchu i bez presji czasowej na optymalizację. Niewystarczający dla czegokolwiek, co ma się rozwijać.

VPS (zarządzany lub niezarządzany, 5-60 USD/miesiąc)

Dedykowany RAM, dedykowany procesor, dedykowany dysk, dostęp root. To tutaj działa większość sklepów naszych klientów i tam trafiłby też taki sklep.

VPS zarządzany: dostawca łata system operacyjny i zajmuje się aktualizacjami bezpieczeństwa. Po stronie właściciela sklepu pozostaje PrestaShop. Panel sterowania lub usługa zarządzana zazwyczaj dokłada 5-20 USD/miesiąc do podstawowej ceny VPS.
VPS niezarządzany: czysta maszyna z Debianem lub Ubuntu i dostępem SSH. Tańsza, ale każda linia konfiguracji nginx i każda aktualizacja jądra należy do właściciela.

W przypadku 90% sklepów, z którymi pracujemy, zarządzany VPS w przedziale 15-30 USD/miesiąc przewyższa hosting współdzielony pod każdym istotnym względem.

Serwer dedykowany (80-300+ USD/miesiąc)

Cała fizyczna maszyna, bez narzutu hiperwizora. Przesada dla sklepu z 2 000 produktów. Właściwy wybór po przekroczeniu 50 000 produktów przy poważnym ruchu, to moment, w którym przenosimy klientów z chmurowego VPS na coś w rodzaju dedykowanego serwera Hetzner, ponieważ stosunek ceny do wydajności staje się absurdalnie korzystny.

Cloud VPS

Rozliczenie godzinowe, szybkie udostępnianie, migawki, API. Konfiguracja 2GB / 2 vCPU mieści się w przedziale 5-15 USD/miesiąc u dostawców wartych uwagi, a dostawcy z siedzibą w UE niezawodnie zbijają ceny dostawców z USA przy równoważnych parametrach.

Hosting „managed PrestaShop”

Wstępnie skonfigurowane maszyny ze wsparciem dedykowanym PrestaShop. Oferta brzmi kusząco, jeśli nigdy wcześniej nie miało się do czynienia z serwerem. W rzeczywistości jest to zwykle odsprzedawana infrastruktura z narzutem, a wsparcie zna panel sterowania sklepem, a nie konkretne moduły danego sklepu.

Hosting managed PrestaShop zarabia na siebie wtedy, gdy naprawdę nie ma się żadnej ochoty na naukę obsługi serwera. Dla każdego innego zarządzany VPS z rozsądnym stosem LEMP działa lepiej i kosztuje mniej.

Wymagania minimalne, według wersji PrestaShop

PrestaShop 1.7

PHP: 7.1-7.4 • MySQL: 5.5+ (zalecane 5.7) • RAM: minimum 2GB, rozsądnie 4GB
Rozszerzenia: curl, gd, intl, mbstring, zip, xml, json, openssl

PrestaShop 8.x

PHP: 7.2-8.1 (na 8.1 wdrażamy my) • MySQL: 5.6+ • RAM: minimum 4GB
Rozszerzenia: lista z 1.7 plus fileinfo i iconv

PrestaShop 9.x

PHP: 8.1-8.4 (w produkcji uruchamiamy 8.2) • MySQL: 8.0+ lub MariaDB 10.5+ • RAM: minimum 4GB, 8GB przy realnym ruchu
Rozszerzenia: lista z 8.x, z dodatkowo obowiązującymi wymaganiami Symfony 6.4

Należy traktować te liczby jako „sklep się zainstaluje”, a nie „sklep będzie wydajny”. Poniższy wiersz startowy z 2GB dotyczy małych sklepów PrestaShop 1.7; dla PrestaShop 8 lub 9 należy wybrać co najmniej 4GB. Katalog z 5 000 produktów, 50 modułami i ruchem na żywo wymaga 4-8GB pamięci RAM niezależnie od tego, która wersja stoi u podstaw.

Ekran Informacje w panelu administracyjnym PrestaShop z konfiguracją PHP, MySQL i serwera

Przewodnik doboru parametrów

Wielkość sklepu	Produkty	Dzienni odwiedzający	RAM	CPU	Dysk
Startowy	<500	<200	2GB	1 rdzeń	20GB SSD
Mały	500-2K	200-1K	4GB	2 rdzenie	40GB SSD
Średni	2K-10K	1K-5K	8GB	4 rdzenie	80GB SSD
Duży	10K+	5K+	16GB+	4-8 rdzeni	160GB+ SSD

Przypomnienie o dysku: 5 000 produktów z 5 obrazami każdy, regenerowanych w 7 typach obrazów PrestaShop, zajmuje 10-20GB, zanim doda się cokolwiek innego. Należy odpowiednio zaplanować przestrzeń dyskową.

Co naprawdę robi różnicę

Każdy host podaje rdzenie, pamięć RAM i przepustowość. Z naszego doświadczenia, oto kolejność, w jakiej rzeczy faktycznie mają znaczenie.

1. Wersja PHP i OPcache

PHP 8.1 jest mniej więcej 20-40% szybsze od 7.4 na tym samym kodzie, a OPcache okazuje się jeszcze większą wygraną ponad to. Bez OPcache PrestaShop rekompiluje setki plików PHP przy każdym żądaniu. Z nim skompilowany kod bajtowy pobierany jest prosto z pamięci.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Jeśli host nie pozwala włączyć OPcache lub w 2026 roku nadal serwuje PHP 7.x, należy odejść. Nie ma w tym żadnej korzyści.

2. Operacje wejścia/wyjścia dysku: SSD lub NVMe, nigdy talerzowy złom

PrestaShop odczytuje setki plików na stronę. Losowy odczyt z dysku HDD to około 5-15 ms, z SSD 0,1 ms. Już samo to daje trzykrotną różnicę w rzeczywistym czasie ładowania strony. Nie wdrożymy sklepu na dysku HDD. Nie warto robić tego również samodzielnie.

3. Konfiguracja MySQL

Typowa strona PrestaShop wykonuje 100-300 zapytań. Pojedynczym ustawieniem, które ma największe znaczenie, jest innodb_buffer_pool_size, kontroluje ono, jaka część danych mieści się w pamięci RAM. 50-70% całkowitej pamięci RAM na dedykowanym serwerze bazy danych, 25-40% na połączonej maszynie aplikacja+baza. Zanim zacznie się stroić serwer wokół rozdętej bazy danych, warto skorzystać z Database Cleanup lub równoważnych audytów SQL, aby usunąć porzucone koszyki, logi i nieaktualne statystyki.

4. RAM

Każdy proces roboczy PHP-FPM zużywa 30-80MB pamięci rezydentnej. Dziesięć procesów oznacza 300-800MB tylko dla PHP, a do tego dochodzi MySQL, Redis, sam OPcache i system operacyjny. 2GB to mało, zanim obsłuży się choć jedno żądanie.

5. HTTP/2

Zwielokrotnia całość ruchu na jednym połączeniu. 20-40% szybciej na stronach ładujących 60-80 zasobów, czyli na większości stron PrestaShop. Wymaga HTTPS, który i tak jest potrzebny.

Hosting współdzielony: ściany, na które się natrafi

Współdzielony może się sprawdzić w najmniejszych sklepach, ale na te ograniczenia natrafi się mniej więcej w tej kolejności:

Brak SSH. Nie da się uruchomić Composera z wiersza poleceń, poleceń konsoli ani żadnego ze skryptów porządkowych, na których normalnie byśmy się oparli.
Limity cron. Wiele hostów współdzielonych ogranicza cron do co 15 minut. Procesy porządkowe PrestaShop wymagają częstszego uruchamiania.
Ograniczony memory_limit. 128-256MB to norma w tanich planach. Duże importy kończą się po cichu niepowodzeniem, gdy osiągną ten limit.
Brak Redis. Pozostaje cache'owanie na systemie plików, na współdzielonej pamięci masowej, która jest już obciążona.
Współdzielony adres IP. Spamerski nawyk sąsiada wpisuje adres IP sklepu na czarną listę i e-maile z potwierdzeniem zamówienia przestają docierać. Rozwiązanie omawiamy w naszym przewodniku po dostarczalności e-maili.

Jeśli mimo wszystko wybiera się hosting współdzielony, należy nadać priorytet dostępowi SSH, panelowi sterowania pozwalającemu wybrać wersję PHP, obsłudze OPcache oraz limitowi pamięci, który da się podnieść. I zawsze należy sprawdzić cenę odnowienia, początkowa kwota to marketing.

2,99 USD/miesiąc odnawia się rok później po 10,99 USD. Każda witryna z recenzjami taniego hostingu współdzielonego to przemilcza. My tego nie robimy.

VPS: właściwy wybór dla większości sklepów

Dlaczego stale wybieramy VPS

Dostęp root. Instalacja Redis, Varnish, całego stosu.
Dedykowany procesor i RAM. Brak sąsiada do obwiniania o 14:00 w Czarny Piątek.
Pełna kontrola nad PHP-FPM i OPcache.
Nieograniczony dostęp SSH i cron.
nginx, a nie Apache, chyba że wybierze się inaczej.
Migawki przed ryzykownymi aktualizacjami: trzy kliknięcia do wycofania zmian.

Co rzeczywiście sprawdzić przed rejestracją

Pamięć masowa SSD lub NVMe. Jeśli specyfikacja tego nie podaje, należy założyć HDD i pominąć ofertę.
Uczciwa cena. 2GB / 2 vCPU za 5-15 USD/miesiąc to norma. 30 USD to przepłacanie.
Lokalizacja centrum danych. Sklepy z UE potrzebują centrów danych w UE. Opóźnienie jest realne, RODO jeszcze bardziej.
Tanie migawki. Jedyna funkcja, która zwraca się za pierwszym razem, gdy aktualizacja modułu pójdzie nie tak.
Dokumentacja. Spędzi się czas w ich dokumentacji. Jeśli jest uboga, to coś o nich mówi.

Jeśli nigdy nie zarządzało się maszyną z systemem Linux, warto dopłacić za usługę zarządzaną lub panel sterowania. Źle skonfigurowany VPS przewyższy hosting współdzielony w testach wydajności, a w praktyce wypadnie gorzej, ponieważ nikt nie załatał jądra.

Bazowy stos LEMP

# Debian 12 / Ubuntu 22.04
apt install nginx php8.2-fpm php8.2-mysql php8.2-curl \\
    php8.2-gd php8.2-intl php8.2-mbstring php8.2-xml \\
    php8.2-zip php8.2-opcache mariadb-server redis-server -y
mysql_secure_installation

Nigdy wcześniej nie obsługiwano serwera Linux? Należy zacząć od zarządzanego VPS lub panelu. Zepsuty samodzielnie konfigurowany VPS jest gorszy niż hosting współdzielony. Nasz przewodnik po utwardzaniu zabezpieczeń omawia, co zablokować po uruchomieniu.

Dedykowany i chmurowy: gdy VPS już nie wystarcza

Należy przejść wyżej, gdy ma się ponad 50 tys. produktów, utrzymujący się ruch ponad 5 tys. dziennych odwiedzających, multistore z pięcioma lub więcej sklepami współdzielącymi maszynę albo realny wymóg dostępności 99,99%.

Dedykowany serwer 64GB / NVMe od europejskiego dostawcy może kosztować 40-60 EUR/miesiąc, to więcej pojemności, niż większość sklepów kiedykolwiek wykorzysta, ale różnicy ceny do wydajności względem chmurowego VPS o tej samej specyfikacji trudno zaprzeczyć.

Kolejność skalowania, gdy faktycznie trzeba skalować: najpierw należy przenieść MySQL na osobny serwer (największy pojedynczy skok), następnie umieścić Redis na osobnej instancji, a potem rozważyć równoważnik obciążenia z wieloma serwerami aplikacji, a w tym momencie potrzebna jest też współdzielona pamięć masowa i sesje w Redis, więc nie należy wyprzedzać kolejności.

Konfiguracja serwera pod PrestaShop

nginx, a nie Apache

Apache jest domyślny, ponieważ używa go hosting współdzielony, a nie dlatego, że lepiej pasuje. nginx korzysta z operacji wejścia/wyjścia sterowanych zdarzeniami (10-30MB na proces wobec 300-800MB w Apache prefork), serwuje pliki statyczne bez przechodzenia przez PHP i dostarczany jest z wbudowanym cache'em FastCGI.

Jeśli jest się przywiązanym do Apache, należy uruchomić mpm_event z PHP-FPM, nigdy mpm_prefork z mod_php. To drugie to najwolniejsze wdrożenie PrestaShop, jakie widzieliśmy w praktyce.

Ustawienia PHP-FPM

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500
php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 300

Wzór, którego używamy dla pm.max_children: (RAM w MB - zajętość MySQL - system operacyjny) / 50MB na proces roboczy. Na maszynie 4GB: (4000 - 1500 - 500) / 50 = 40. Ustawiamy 20-30, aby pozostawić zapas, ponieważ przeładowana pula FPM oznacza błędy 502 prosto w twarz klienta.

Strojenie MySQL

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
long_query_time = 1

Log wolnych zapytań należy włączyć pierwszego dnia. Pojedyncze złe zapytanie uruchamiane 200 razy na stronę bije każdą diagnozę „wolnego serwera”, jaką kiedykolwiek postawiliśmy, a ten log to sposób, by je znaleźć. Nasz przewodnik po wydajności przeprowadza przez to, co zrobić po wykryciu winowajców.

Redis do sesji i cache'u

PrestaShop domyślnie umieszcza sesje i cache na dysku. Po przeniesieniu obu do Redis strony administracyjne przestają blokować się na blokowaniu sesji w systemie plików, co jest najczęstszą pojedynczą przyczyną zgłoszeń „panel administracyjny działa tak wolno”, jakie otwieramy. Redis kosztuje 50-100MB pamięci RAM i natychmiast się zwraca.

SSL/TLS: nie do pominięcia

Każdy sklep potrzebuje HTTPS. Google obniża pozycję stron HTTP, przeglądarki je piętnują, a żaden operator płatności bez tego nie zadziała. Dyskusja jest zamknięta.

Let's Encrypt

Darmowy, automatyczny, odnawiany co 90 dni. Certbot instaluje go raz i można o nim zapomnieć:

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourshop.com -d www.yourshop.com

Cloudflare SSL

Darmowy przez ich proxy, z jedną pułapką: zawsze należy używać Full (Strict). Tryb Flexible przesyła tekst jawny między Cloudflare a serwerem źródłowym, co przekreśla cały sens. Należy ustawić X-Forwarded-Proto, aby PrestaShop wiedział, że działa za HTTPS, nawet gdy ostatni skok do źródła jest po HTTP.

Wymuszanie HTTPS

Należy włączyć w Parametry sklepu → Ogólne, a następnie dodać przekierowanie po stronie serwera:

# Nginx
server {
    listen 80;
    server_name yourshop.com;
    return 301 https://yourshop.com$request_uri;
}

# Apache (.htaccess)
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

CDN: kiedy i jak

Jeśli obsługuje się jeden region z lokalnego serwera, CDN nie daje zbyt wiele na szybkości. Daje natomiast cache'owanie zasobów statycznych i darmową warstwę ochrony przed DDoS.

Darmowy plan Cloudflare obejmuje większość sklepów: globalny CDN, darmowy SSL, podstawową ochronę DDoS, HTTP/2, Brotli. Należy go podpiąć w Parametry zaawansowane → Wydajność → Serwery multimediów.

Cache'ować agresywnie: obrazy, CSS, JS, czcionki.
Nigdy nie cache'ować: panelu administracyjnego, koszyka, finalizacji zamówienia, mojego konta, niczego, co dotyka cookie PrestaShop.

Nigdy nie należy włączać „Cache Everything” dla całej domeny. Widzieliśmy to: jeden klient widzi koszyk innego klienta, ponieważ finalizacja zamówienia została zbuforowana na brzegu sieci. Należy cache'ować wyłącznie zasoby statyczne i nazwane wzorce adresów URL.

Kopie zapasowe: migawki hosta to nie strategia

Kopie zapasowe dostawcy są zwykle cotygodniowe, uruchamiane na tej samej infrastrukturze i z niezerowym prawdopodobieństwem niemożności odtworzenia, gdy zajdzie potrzeba. To kocyk dla poczucia bezpieczeństwa. Jeśli dostawca ma złą noc, kopie zapasowe znikają razem ze sklepem. Jeśli ransomware zaszyfruje pliki, zaszyfrowane wersje zostają sumiennie skopiowane. A prawdopodobnie potrzebna jest baza danych sprzed dwóch godzin, a nie z zeszłego wtorku.

Czego potrzeba, minimum: codziennych automatycznych zrzutów bazy danych plus kopii plików, przechowywanych poza serwerem produkcyjnym, trzymanych przez 30 dni, z testowym odtworzeniem co miesiąc. Te zadania należy zaplanować w widocznym miejscu; MPR Cron Manager to opcja po stronie PrestaShop, gdy chce się mieć zadania kopii zapasowych śledzone, a nie ukryte w anonimowych liniach crontaba. Nasz przewodnik po kopiach zapasowych zawiera gotową procedurę.

Migracja między hostami

Przygotowanie nowego serwera z tą samą wersją PHP i tymi samymi rozszerzeniami.
Zrzut bazy danych: mysqldump -u root -p prestashop_db | gzip > backup.sql.gz
Synchronizacja plików: rsync -avz /var/www/html/prestashop/ newserver:/var/www/html/prestashop/
Import bazy danych na nowym serwerze.
Aktualizacja danych dostępowych w app/config/parameters.php.
Naprawa uprawnień: chown -R www-data:www-data, katalogi 755, pliki 644.
Wyczyszczenie cache'u: rm -rf var/cache/*
Test przez /etc/hosts: należy skierować swój laptop na nowy adres IP i przejść przez finalizację zamówienia oraz panel administracyjny, zanim zrobi to ktokolwiek inny.
Obniżenie TTL DNS do 300 sekund na 24 godziny przed przełączeniem.
Końcowa synchronizacja bazy danych tuż przed przełączeniem DNS, aby nie utracić ostatnich zamówień.

Gdzie migracje idą nie tak

Właściciel plików. Użytkownik serwera WWW musi być właścicielem plików. Katalogi cache, img, upload i download muszą być zapisywalne.
Brakujący plik .htaccess. Graficzne narzędzia migracyjne uwielbiają pomijać pliki z kropką. Apache potrzebuje też AllowOverride All, aby go uwzględnić.
Niezgodność bazowego adresu URL. Jeśli domena się zmieniła, należy zaktualizować ps_shop_url, w przeciwnym razie wszystkie odnośniki się popsują.
Skok wersji PHP. Przejście z 7.4 na 8.1 psuje każdy moduł wciąż wywołujący przestarzałe funkcje.

Nigdy nie należy przełączać DNS przed przetestowaniem przez /etc/hosts. Widzieliśmy dwie migracje, które zepsuły finalizację zamówienia na produkcji, ponieważ nikt najpierw nie kliknął „kup” na nowym serwerze.

Czerwone flagi: gdy się je zobaczy, należy odejść

Techniczne

Brak SSH. Nie da się wdrażać, nie da się debugować, nie da się uruchomić żadnego z narzędzi, które faktycznie naprawiają problemy.
PHP 7.x w 2026 roku. Koniec wsparcia. Znane podatności, które nie zostaną załatane.
Brak OPcache. 3-5 razy wolniej niż ten sam kod z włączonym OPcache. Nie ma ku temu powodu.
Pamięć masowa HDD. Jeśli na piśmie nie podają SSD ani NVMe, należy założyć HDD.
Zablokowany plik php.ini. Nie da się poprawnie uruchomić PrestaShop bez podniesienia przynajmniej memory_limit.

Biznesowe

Cokolwiek „nieograniczonego”. Nic nie jest nieograniczone. Dławią hałaśliwych lokatorów, zamiast to przyznać.
Marki spółek holdingowych. Pięć „różnych” hostów należących do tej samej spółki matki, wszystkie na tym samym przeładowanym sprzęcie, w różnych logotypach.
Brak SLA dostępności. Nie ufają własnej infrastrukturze na tyle, by podać liczbę.
Wsparcie odpowiadające po kilka dni. Awaria o 2 w nocy wymaga minut, a nie „następnego dnia roboczego”.
Wymuszone rozliczenie roczne. Liczą na to, że klient nie odejdzie, gdy zorientuje się, że to był błąd.

Najtańszy hosting to ten, który działa w trakcie Czarnego Piątku. Oszczędzenie 5 USD/miesiąc na hoście, który kosztuje 5 000 USD utraconych konwersji w weekend, nie jest żadną oszczędnością.

Lista kontrolna przed zakupem

Każda pozycja tutaj ma znaczenie. Należy ją odhaczyć, zanim wprowadzi się kartę.

Serwer

Wersja PHP zgodna z wersją PrestaShop
Wszystkie wymagane rozszerzenia PHP dostępne (przynajmniej intl, mbstring, gd)
php.ini jest konfigurowalny (memory_limit, ustawienia OPcache)
MySQL lub MariaDB w wersji faktycznie obsługiwanej przez PrestaShop
SSD lub NVMe na piśmie
Dostęp SSH
Nieograniczona częstotliwość cron

Wydajność

OPcache włączony i konfigurowalny
4GB+ RAM w wybieranym planie lub 2GB dla małego sklepu startowego PrestaShop 1.7
HTTP/2 włączony
Redis lub Memcached dostępny

Niezawodność

SLA dostępności 99,9% lub lepsze
Opcje kopii zapasowych automatycznych i ręcznych
Czas reakcji wsparcia krytycznego mierzony w godzinach, a nie dniach
Centrum danych blisko klientów sklepu

Cennik

Sprawdzona cena odnowienia (a nie cena początkowa)
Dostępne rozliczenie miesięczne
Zrozumiałe limity przepustowości lub transferu
Brak klauzuli uniemożliwiającej migrację do innego dostawcy

Co warto wybrać, według etapu

Zupełnie nowy sklep: Cloud VPS z co najmniej 4GB RAM dla PrestaShop 8 lub 9 albo 2GB dla małego sklepu PrestaShop 1.7, plus darmowy CDN i Let's Encrypt. Bije większość hostingu współdzielonego za 15 USD/miesiąc na głowę.
Rozwijający się sklep: Zarządzany VPS za 15-30 USD/miesiąc. Warto zapłacić komuś za utrzymanie załatanego systemu operacyjnego, by samemu skupić się na sprzedaży.
Ugruntowany (1 tys.+ odwiedzających dziennie): VPS z 8-16GB RAM, nastrojony MariaDB, włączony Redis, nginx z cache'em FastCGI. 15-40 USD/miesiąc wystarczy.
Duży katalog lub wzmożony ruch: Serwer dedykowany (tani dedykowany z UE przewyższa chmurowy VPS przy tej skali) lub poprawnie rozdzielona architektura chmurowa. 50-100+ USD/miesiąc i warte każdego grosza.

Monitorowanie dostępności należy skonfigurować pierwszego dnia. UptimeRobot jest darmowy dla 50 monitorów i wystarczająco dobry. Gdy hosting jest już uporządkowany, reszta prac optymalizacyjnych ma solidny grunt, na którym może wylądować.

Powiązane materiały

Optymalizacja wydajności PrestaShop: jak przyspieszyć sklep: co stroić, gdy hosting jest już ustalony
Utwardzanie zabezpieczeń PrestaShop: kompletna lista kontrolna: blokady na poziomie serwera
Rozwiązywanie problemów z PrestaShop: białe ekrany i błędy 500: gdy problemem jest host i trzeba to udowodnić
Kopie zapasowe PrestaShop: prawdziwe backupy, nie złudne pocieszenie: gotowa procedura, której sami używamy
Performance Revolution: jeden z naszych modułów; dobrze współgra z poprawnie dobranym VPS