Magento (Adobe Commerce) to platforma e-commerce klasy enterprise. Obsługuje sklepy z setkami tysięcy produktów, milionami zamówień rocznie i złożoną logiką biznesową. Ale ta moc ma swoją cenę: hosting Magento nie przypomina hostowania WordPressa czy PrestaShop. Źle dobrany serwer potrafi zamienić szybki silnik sprzedażowy w frustrujący labirynt błędów 503, timeoutów przy imporcie katalogów i indeksacji trwającej godzinami.

Ten poradnik powstał z jednego powodu: zbyt wielu właścicieli sklepów Magento trafia na hosting, który nie spełnia minimalnych wymagań platformy. Potem szukają przyczyny wolnego działania w kodzie, wtyczkach, konfiguracji, tymczasem problem leży w infrastrukturze. Pokażemy konkretnie, jakie parametry serwera są potrzebne, czym różnią się poszczególne typy hostingu i którego dostawcę wybrać, żeby sklep działał stabilnie pod obciążeniem.

1. Wymagania techniczne Magento 2.4.8

Magento 2.4.8 (wydanie z końcówki 2025 roku, stabilna wersja na 2026) przyniosło istotne zmiany w stosie technologicznym. Adobe porzuciło wsparcie dla starszych wersji PHP i Elasticsearch, jednocześnie wprowadzając kompatybilność z nowszymi wersjami baz danych. Poniżej pełna specyfikacja.

PHP 8.3 lub 8.4

Magento 2.4.8 wymaga PHP 8.3 jako minimum. Obsługuje też PHP 8.4, które przynosi dodatkowe zyski wydajnościowe (Property Hooks, asymmetric visibility, JIT improvements). PHP 8.1 i 8.2 nie są już wspierane. To istotna zmiana, bo wiele hostingów nadal domyślnie oferuje PHP 8.1.

Jeśli Twój hosting nie ma PHP 8.3 lub 8.4, to po prostu nie uruchomisz aktualnego Magento. Bez dyskusji.

OpenSearch 2.19 (obowiązkowy)

To największa zmiana infrastrukturalna. Magento 2.4.8 porzuciło Elasticsearch 7.x i 8.x na rzecz OpenSearch 2.19 jako jedynego wspieranego silnika wyszukiwania. OpenSearch to fork Elasticsearch rozwijany przez Amazon i społeczność open source, wolny od licencyjnych ograniczeń Elastic.

W praktyce oznacza to, że hosting musi udostępniać instancję OpenSearch 2.19+. To nie jest opcjonalny dodatek. Bez silnika wyszukiwania Magento nie uruchomi się poprawnie, bo cały katalog produktowy, wyszukiwarka, layered navigation i indeksery zależą od OpenSearch.

Baza danych: MySQL 8.4 LTS lub MariaDB 11.4 LTS

Magento 2.4.8 wspiera dwie bazy danych:

• MySQL 8.4 LTS — wersja z długoterminowym wsparciem Oracle
• MariaDB 11.4 LTS — preferowana przez wiele dystrybucji Linux

Obie opcje sprawdzają się dobrze. MariaDB 11.4 bywa nieco szybsza w operacjach odczytu dzięki optymalizacjom w silniku InnoDB (Aria). MySQL 8.4 ma z kolei lepsze wsparcie dla window functions i CTE, co przydaje się przy złożonych raportach.

Cache i akceleracja: Redis + Varnish

Choć Redis i Varnish nie są formalnie „wymagane”, uruchamianie Magento bez nich to jak jazda Ferrari na pierwszym biegu:

• Redis 7.x — in-memory store do cache'owania sesji, backendu cache i full page cache. Zastępuje domyślny plikowy backend cache, który nie nadaje się do produkcji.
• Varnish 7.x — reverse proxy cache, który obsługuje ponad 90% requestów bez angażowania PHP. Na stronach katalogowych i CMS potrafi skrócić TTFB z 800–1200 ms do 15–30 ms.

Minimalne i zalecane zasoby serwera

2. Rodzaje hostingu dla Magento

Nie każdy typ hostingu nadaje się do Magento. Poniżej szczegółowa analiza dostępnych opcji, od najgorszej do najlepszej.

Hosting współdzielony (shared) — absolutnie NIE

Dlaczego? Hosting shared dzieli zasoby (CPU, RAM, dysk) między dziesiątki lub setki kont. Magento potrzebuje minimum 4 GB RAM na sam proces, a na współdzielonym hostingu dostaniesz limit 256–512 MB. Brakuje dostępu root, więc nie zainstalujesz OpenSearch, Redis ani Varnish. Limity czasu wykonania skryptów (30–60 sekund) uniemożliwią indeksację katalogów czy import produktów. A pierwszy „efekt sąsiada” (inny użytkownik na tym samym serwerze obciąża CPU) i Twój sklep pada na kolana.

Jedyny wyjątek: małe demo lub środowisko testowe z kilkoma produktami. Ale nawet wtedy lepiej postawić lokalne środowisko Docker na laptopie.

VPS (Virtual Private Server) — minimum viable

VPS daje dedykowane zasoby, root access i pełną kontrolę nad konfiguracją. To minimum, od którego można sensownie prowadzić sklep Magento.

VPS sprawdza się dobrze dla sklepów o stałym, przewidywalnym ruchu. Kluczowe: wybierz VPS z gwarantowanymi zasobami (nie „do” X GB RAM, ale „dedykowane” X GB RAM) i dyskami NVMe.

Serwer dedykowany — dla dużych sklepów

Fizyczny serwer z pełnymi zasobami, bez warstwy wirtualizacji. Idealny dla sklepów z dużym katalogiem (powyżej 100 tys. SKU), wysokim ruchem (tysiące sesji na minutę) i wymagającymi integracjami (ERP, PIM, hurtownie).

Koszt: od 500–800 PLN/mies. za serwer z 32–64 GB RAM i procesorem Xeon/EPYC. Na rynku polskim dedykowane serwery oferują m.in. OVH, Hetzner (przez polskie datacenter we Wrocławiu) oraz polscy dostawcy jak Centuria czy SMARTX.

Cloud (AWS, GCP, Azure) — skalowalny, ale drogi

Chmura publiczna daje elastyczne skalowanie: możesz automatycznie dodawać instancje przy wzroście ruchu (Black Friday, kampanie reklamowe). Adobe Commerce Cloud (oficjalny hosting od Adobe) działa właśnie na AWS.

Dla polskiego sklepu z obrotem poniżej 5 mln PLN rocznie chmura publiczna jest zwykle przesadzona kosztowo. VPS lub zarządzany hosting da lepszy stosunek wydajności do ceny.

Managed Magento hosting — najlepszy kompromis

Zarządzany hosting Magento łączy moc dedykowanych zasobów z gotową, zoptymalizowaną infrastrukturą. Dostawca zapewnia skonfigurowany stos (PHP + OpenSearch + Redis + Varnish + bazę danych), aktualizacje bezpieczeństwa, monitoring i wsparcie techniczne znające specyfikę Magento.

To rozwiązanie dla firm, które chcą skupić się na sprzedaży, a nie na administracji serwerami. Dostawca przejmuje odpowiedzialność za warstwę infrastrukturalną, Ty zarządzasz aplikacją.

Na polskim rynku taki model oferuje m.in. SMARTX Hosting (kontenery Docker/LXC z pełnym stosem Magento) oraz jchost.pl (specjalistyczny hosting Magento).

3. Na co zwrócić uwagę? 10 kryteriów wyboru

Przy wyborze hostingu Magento nie wystarczy porównać cen i ilości RAM-u. Poniżej 10 kluczowych kryteriów, które decydują o tym, czy Twój sklep będzie działał płynnie.

1. Wersja PHP (8.3 / 8.4)

Upewnij się, że hosting oferuje PHP 8.3 lub 8.4 z możliwością przełączania między wersjami. Sprawdź też, czy są zainstalowane wymagane rozszerzenia: bcmath, ctype, curl, dom, gd, intl, mbstring, openssl, pdo_mysql, soap, sodium, xsl, zip, sockets. Brak jednego rozszerzenia potrafi zablokować instalację Composera.

2. OpenSearch / Elasticsearch

Dla Magento 2.4.8: OpenSearch 2.19+. Starsze wersje Magento (2.4.6, 2.4.7) mogą jeszcze korzystać z Elasticsearch 7.17 lub 8.x. Kluczowe pytanie do dostawcy: Czy OpenSearch działa na dedykowanej instancji, czy jest współdzielony między kontami? Współdzielony OpenSearch przy indeksacji pełnego katalogu potrafi być wąskim gardłem.

3. Redis

Redis powinien być dostępny z dedykowaną instancją (nie współdzieloną). Magento używa minimum dwóch baz danych Redis: jednej dla cache backendu (db0), drugiej dla sesji (db1). Przy konfiguracji z full page cache w Redis potrzebna jest trzecia baza (db2). Sprawdź, ile pamięci Redis jest dostępne — minimum 512 MB, optymalnie 1–2 GB.

4. Varnish cache

Varnish to największy pojedynczy czynnik wpływający na szybkość Magento dla odwiedzających. Strona katalogowa bez Varnish generuje się 600–1500 ms. Z Varnish: 10–30 ms. To różnica, którą odczuje każdy użytkownik i która wpłynie na konwersję.

Pytanie do dostawcy: Czy mogę zarządzać konfiguracją VCL Varnish? Magento generuje własny plik VCL (bin/magento varnish:vcl:generate), który trzeba załadować do Varnish.

5. Typ dysku: NVMe vs SSD vs HDD

Magento jest intensywne I/O — tysiące małych plików PHP, ciągłe zapisy do bazy, operacje na cache. Dyski NVMe (podłączone przez PCIe) oferują opóźnienia rzędu 0.02 ms i przepustowość powyżej 3 GB/s. SATA SSD: 0.1–0.2 ms, 500 MB/s. HDD: 5–10 ms, 150 MB/s.

Różnica między NVMe a HDD to 250-krotna różnica w opóźnieniach. Dla Magento, gdzie compilation (setup:di:compile) czyta dziesiątki tysięcy plików, to oznacza minuty vs dziesiątki minut.

6. Polityka backupów

Sklep e-commerce to krytyczny system biznesowy. Sprawdź:

• Jak często wykonywane są backupy? (codziennie to minimum)
• Ile kopii jest przechowywanych? (7–14 dni retencji)
• Gdzie przechowywane są backupy? (inny serwer, inna lokalizacja)
• Jak szybko można przywrócić backup?
• Czy backup obejmuje bazę danych + pliki + konfigurację?

7. Certyfikat SSL

SSL to standard. Każdy hosting powinien oferować darmowy certyfikat Let's Encrypt. Dla sklepów e-commerce z płatnościami online certyfikat SSL to wymóg PCI DSS. Sprawdź, czy hosting obsługuje automatyczne odnawianie certyfikatu i czy możesz zainstalować własny certyfikat (np. EV lub wildcard).

8. Jakość i czas reakcji wsparcia

Gdy sklep leży w piątek wieczorem, a zamówienia napływają, czas reakcji supportu decyduje o stratach. Pytania do dostawcy:

• Jaki jest gwarantowany czas reakcji (SLA)?
• Czy support jest dostępny 24/7, czy tylko w godzinach biurowych?
• Czy zespół wsparcia zna Magento, czy tylko Linux/serwery?
• Jakie kanały kontaktu (telefon, chat, ticket)?

9. Lokalizacja serwera

Dla polskich klientów serwer w Polsce (lub Europie Środkowej) to obowiązkowy punkt. Latencja z Katowic do Warszawy: 2–5 ms. Z Katowic do Frankfurtu: 10–15 ms. Z Katowic do USA (Virginia): 90–120 ms.

Każdy dodatkowy milisekund latencji mnożony jest przez liczbę żądań na stronę. Typowa strona Magento generuje 30–80 żądań (obrazy, CSS, JS, AJAX). Serwer bliżej klientów = szybszy sklep = lepsza konwersja.

10. Izolacja zasobów

Na hostingu VPS Twoje zasoby powinny być izolowane od innych użytkowników. Najlepsza izolacja: kontenery Docker/LXC z dedykowanymi limitami CPU i RAM. Gorsza: klasyczny VPS na KVM/QEMU, gdzie hypervisor dodaje narzut. Najgorsza: hosting „VPS”, który w rzeczywistości jest podzielonym serwerem bez twardych limitów.

Zapytaj dostawcę o technologię wirtualizacji. Kontenery (Docker, LXC/LXD) dają najlepszy stosunek wydajności do zasobów, bo eliminują narzut hypervisora i jądra gościa.

4. Porównanie hostingów Magento w Polsce 2026

Na polskim rynku hostingowym jest kilkunastu dostawców oferujących usługi pod Magento. Poniżej porównanie najważniejszych graczy z uwzględnieniem parametrów istotnych dla Magento 2.4.8.

* OVH otworzyło datacenter we Wrocławiu. Ceny na luty 2026. „Samodzielna inst.” = hosting daje czysty serwer, konfiguracja stosu po stronie klienta. „Na zapytanie” = usługa dostępna, ale wymaga kontaktu z supportem.

Szczegółowa analiza wybranych dostawców

SMARTX Hosting

SMARTX wyróżnia się podejściem kontenerowym (Docker/LXC). Każdy klient dostaje izolowany kontener z pełnym stosem Magento: PHP-FPM, Nginx, OpenSearch, Redis, MariaDB i Varnish. Zasoby (CPU, RAM) są twardo przydzielone, co eliminuje efekt „głośnego sąsiada”.

Certyfikaty ISO 9001 (zarządzanie jakością) i ISO 27001 (bezpieczeństwo informacji) to rzadkość wśród polskich hostingów. Datacenter w Katowicach (podstawowy) i Londynie (DR/failover) zapewnia niską latencję dla polskich klientów i geograficzną redundancję.

LH.pl

LH.pl jest jednym z większych polskich dostawców hostingu. Hostuje między innymi etuo.pl — jeden z największych polskich sklepów Magento (akcesoria do telefonów, kilkadziesiąt tysięcy produktów). To mocna referencja. LH.pl dominuje w wynikach wyszukiwania na frazę „magento sklep” i ma rozbudowaną bazę wiedzy.

Minusy: mniejsza elastyczność konfiguracji, OpenSearch trzeba często konfigurować indywidualnie (po kontakcie z supportem).

jchost.pl

Specjalista Magento. Oferuje preconfigurowane środowiska zoptymalizowane pod Magento, z gotowym stosem OpenSearch + Redis + Varnish. Dobrze sprawdza się dla firm, które potrzebują hostingu „pod klucz” bez zarządzania serwerem. Wyższe ceny niż generyczne VPS, ale mniej konfiguracji po stronie klienta.

OVH

Najtańsza opcja VPS. OVH oferuje surowe serwery wirtualne za kilkadziesiąt złotych miesięcznie, ale cała konfiguracja stosu Magento leży po stronie klienta. To opcja dla developerów i adminów, którzy potrafią samodzielnie postawić i utrzymać pełne środowisko. Dla firm bez zespołu DevOps — nie polecamy.

5. Docker vs tradycyjny hosting — dlaczego kontenery są lepsze dla Magento

Konteneryzacja (Docker, LXC/LXD) zmienia sposób, w jaki myślimy o hostingu aplikacji. Dla Magento ta zmiana jest szczególnie korzystna ze względu na złożoność stosu technologicznego.

Izolacja zasobów

W tradycyjnym hostingu współdzielonym lub nawet na klasycznym VPS granice między użytkownikami bywają płynne. Kontener Docker/LXC ma twarde limity: przydzielone 4 rdzenie CPU, 8 GB RAM, 100 GB dysku. Żaden inny kontener na tym samym hoście fizycznym nie „pożyczy” sobie Twoich zasobów. To gwarantuje przewidywalną wydajność pod obciążeniem.

Spójne środowisko: dev = staging = produkcja

Jednym z największych problemów w projektach Magento jest „u mnie działa”. Developer ma PHP 8.4 z jedną konfiguracją OPcache, staging ma PHP 8.3 z inną, a produkcja jeszcze coś innego. Docker eliminuje ten problem: definiujesz obraz kontenera raz, i ten sam obraz działa wszędzie.

# Przykładowy Dockerfile dla Magento 2.4.8
FROM php:8.4-fpm-alpine

RUN apk add --no-cache \\
    nginx opensearch redis varnish \\
    icu-dev libxml2-dev libxslt-dev \\
    freetype-dev libjpeg-turbo-dev libpng-dev libzip-dev

RUN docker-php-ext-configure gd --with-freetype --with-jpeg \\
    && docker-php-ext-install -j$(nproc) \\
    bcmath ctype dom gd intl mbstring \\
    pdo_mysql soap sodium xsl zip sockets opcache

COPY nginx.conf /etc/nginx/nginx.conf
COPY php-fpm.conf /usr/local/etc/php-fpm.d/www.conf

Szybki deployment i rollback

Wdrożenie nowej wersji Magento na kontenerze to kwestia minut: budujemy nowy obraz, uruchamiamy nowy kontener, przełączamy ruch. Jeśli coś pójdzie nie tak — rollback do poprzedniego obrazu trwa sekundy. W tradycyjnym hostingu deployment oznacza ręczne kopiowanie plików, uruchamianie setup:upgrade i modlenie się, żeby nic się nie zepsuło.

Skalowanie

Potrzebujesz więcej mocy przed Black Friday? W architekturze kontenerowej możesz:

• Skalować pionowo: zwiększyć limity CPU/RAM kontenera
• Skalować poziomo: uruchomić kilka kontenerów PHP-FPM za load balancerem
• Wydzielić usługi: osobny kontener dla OpenSearch, Redis, bazy danych

Bezpieczeństwo

Kontenery zapewniają izolację na poziomie namespace i cgroup. Nawet jeśli atakujący przejmie kontrolę nad aplikacją PHP w kontenerze, nie wydostanie się na host fizyczny ani do innych kontenerów. W tradycyjnym hostingu współdzielonym przejęcie jednego konta może otworzyć drogę do eskalacji uprawnień na serwerze.

6. Optymalizacja Magento na serwerze

Nawet najlepszy hosting wymaga odpowiedniej konfiguracji. Poniżej konkretne ustawienia, które wyciągną maksimum wydajności z Magento 2.4.8.

OPcache — obowiązkowa konfiguracja

OPcache kompiluje skrypty PHP do bytecodu i trzyma je w pamięci. Magento ma tysiące plików PHP, więc bez OPcache każdy request oznacza parsowanie i kompilację od zera.

; /etc/php/8.4/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=512
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=130987
opcache.validate_timestamps=0
opcache.save_comments=1
opcache.enable_file_override=1
opcache.max_wasted_percentage=10

Kluczowe parametry:

• memory_consumption=512 — Magento potrzebuje 300–500 MB na cache bytecodu. 512 MB to bezpieczna wartość dla sklepu z kilkudziesięcioma rozszerzeniami.
• max_accelerated_files=130987 — maksymalna liczba plików w cache. Magento z rozszerzeniami ma 50–100 tys. plików PHP. Wartość musi być liczbą pierwszą — 130987 to najbliższa powyżej 130000.
• validate_timestamps=0 — wyłącza sprawdzanie zmian w plikach. Na produkcji pliki nie powinny się zmieniać między deployami. Po każdym deploy trzeba wykonać opcache_reset() lub restart PHP-FPM.

Redis — trzy bazy, trzy zadania

Magento powinien używać Redis do trzech oddzielnych celów, każdy na innej bazie (database number):

# app/etc/env.php (fragmenty)

# Backend cache (db0)
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\\\\Framework\\\\Cache\\\\Backend\\\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => 6379,
                'database' => 0,
                'compress_data' => 1,
                'compression_lib' => 'lz4'
            ]
        ],
        # Full Page Cache (db2)
        'page_cache' => [
            'backend' => 'Magento\\\\Framework\\\\Cache\\\\Backend\\\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => 6379,
                'database' => 2,
                'compress_data' => 0
            ]
        ]
    ]
],

# Sesje (db1)
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => 6379,
        'database' => 1,
        'disable_locking' => 1,
        'max_concurrency' => 20
    ]
]

Dlaczego trzy bazy? Ponieważ cache backendu jest flushowany przy cache:flush, a sesje nie powinny być kasowane razem z cache. Full page cache ma inny cykl życia niż cache backendu. Rozdzielenie na bazy pozwala niezależnie zarządzać każdym typem danych.

Varnish VCL dla Magento

Magento generuje gotowy plik VCL (Varnish Configuration Language):

php bin/magento varnish:vcl:generate \\
    --backend-host=127.0.0.1 \\
    --backend-port=8080 \\
    --access-list="127.0.0.1" \\
    --grace-period=300 \\
    --output-file=/etc/varnish/magento.vcl

Po wygenerowaniu VCL, Varnish powinien nasłuchiwać na porcie 80 (lub 443 za SSL terminatorem), a Nginx/Apache na porcie 8080. Kluczowe parametry Varnish:

# /etc/default/varnish
VARNISH_LISTEN_PORT=80
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
VARNISH_STORAGE="malloc,2G"

malloc,2G przydziela 2 GB RAM na cache Varnish. Dla sklepu z dużym katalogiem i wieloma wariantami stron (kategorie, filtry, paginacja) 2–4 GB to optymalna wartość.

PHP-FPM tuning

PHP-FPM zarządza pulą procesów PHP. Zbyt mało procesów = kolejki i 502/504. Zbyt dużo = wyczerpanie RAM i OOM killer.

; /etc/php/8.4/fpm/pool.d/magento.conf
[magento]
user = magento
group = magento

pm = dynamic
pm.max_children = 30
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 1000

request_terminate_timeout = 300
php_admin_value[memory_limit] = 768M

Obliczanie pm.max_children: każdy proces PHP-FPM z Magento zajmuje 128–256 MB RAM. Przy 8 GB RAM na serwerze (minus 2 GB na OS + Redis + OpenSearch + bazę) zostaje ~6 GB na PHP. 6 GB / 200 MB = ~30 procesów. To maksymalna bezpieczna wartość.

MySQL / MariaDB — kluczowe parametry

# /etc/mysql/conf.d/magento.cnf
[mysqld]
innodb_buffer_pool_size = 3G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_read_io_threads = 8
innodb_write_io_threads = 8

max_connections = 200
tmp_table_size = 256M
max_heap_table_size = 256M
join_buffer_size = 4M
sort_buffer_size = 4M
query_cache_type = 0

Najważniejszy parametr to innodb_buffer_pool_size. Powinien wynosić 60–70% dostępnej pamięci RAM przydzielonej bazie danych. Dla serwera z 8 GB RAM, gdzie baza ma do dyspozycji ~4 GB, optymalnie 3 GB na buffer pool.

innodb_flush_log_at_trx_commit = 2 zmniejsza liczbę operacji zapisu na dysk kosztem minimalnego ryzyka utraty danych (do 1 sekundy transakcji przy awarii zasilania). Dla sklepów, gdzie krytyczne dane i tak replikowane są przez payment gateway, to akceptowalny kompromis.

Nginx vs Apache

Oba serwery WWW obsługują Magento, ale Nginx jest rekomendowany. Powody:

• Niższe zużycie pamięci (event-driven vs process/thread per connection)
• Lepsza obsługa plików statycznych (CSS, JS, obrazy)
• Natywne wsparcie dla upstream (PHP-FPM) i reverse proxy
• Prostszy w konfiguracji z Varnish
• Lepsze zachowanie pod dużym obciążeniem (10000+ jednoczesnych połączeń)

Magento zawiera gotową konfigurację Nginx w nginx.conf.sample w katalogu głównym projektu. Wystarczy ją includować i dostosować ścieżki.

Tryb produkcyjny i kompilacja

Magento ma trzy tryby: default, developer i production. Na serwerze produkcyjnym zawsze powinien być tryb production:

# Pełny deploy produkcyjny
php bin/magento maintenance:enable
php bin/magento deploy:mode:set production --skip-compilation
php bin/magento setup:upgrade --keep-generated
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy pl_PL en_US -j 4
php bin/magento indexer:reindex
php bin/magento cache:flush
php bin/magento maintenance:disable

Tryb produkcyjny wyłącza generowanie klas w locie, serwuje prekompilowane pliki statyczne i blokuje wyświetlanie błędów. Różnica w TTFB między trybem developer a production to typowo 3–5x.

Flat catalog dla dużych sklepów

Magento domyślnie używa modelu EAV (Entity-Attribute-Value), który jest elastyczny, ale powolny przy dużej liczbie atrybutów. Flat catalog tworzy denormalizowane tabele z kolumnami dla każdego atrybutu, co przyspiesza odczyty katalogowe.

Włączenie: Stores > Configuration > Catalog > Catalog > Storefront > Use Flat Catalog Category i Use Flat Catalog Product. Po włączeniu konieczna pełna reindeksacja.

Flat catalog ma sens przy ponad 10 tys. produktów i dużej liczbie atrybutów filtrowanych. Dla małych sklepów (poniżej 5 tys. SKU) zysk jest marginalny.

7. Mage-OS — alternatywa z mniejszymi wymaganiami?

Mage-OS to niezależny fork Magento rozwijany przez społeczność europejskich developerów. Powstał w odpowiedzi na obawy związane z kierunkiem rozwoju Adobe Commerce i rosnącą złożonością platformy.

Z perspektywy hostingu Mage-OS ma kilka interesujących cech:

• Mniejsze wymagania RAM — zoptymalizowany bootstrap ładuje mniej klas, co zmniejsza footprint pamięci o 15–25% w porównaniu z Adobe Commerce
• Szybsza instalacja — mniej zależności Composera, krótszy czas setup:install
• Kompatybilność z modułami Magento — większość rozszerzeń Magento 2 działa bez zmian
• Ten sam stos technologiczny — PHP, OpenSearch, Redis, MySQL/MariaDB. Wymagania systemowe są zbliżone, ale próg minimalny jest niższy

Mage-OS to dobra opcja dla mniejszych sklepów (do 10–20 tys. produktów), które potrzebują siły Magento, ale nie korzystają z ekosystemu Adobe (Sensei AI, Adobe Experience Platform, Live Search). Wymagania hostingowe są analogiczne, ale niższy próg wejścia pozwala wystartować na tańszym VPS.

8. Najczęstsze pytania (FAQ)

9. Podsumowanie

Wybór hostingu Magento to decyzja, która wpływa na wydajność sklepu, doświadczenie klientów i ostatecznie — na sprzedaż. Magento nie jest WordPressem. Nie postawisz go na hostingu za 20 PLN i nie będzie „jakoś” działać.

Podsumowując kluczowe wnioski:

1. Minimum to VPS z 4 GB RAM, ale dla produkcji realistyczne jest 8 GB. Hosting shared odpada.
2. Magento 2.4.8 wymaga PHP 8.3+, OpenSearch 2.19+ i MySQL 8.4/MariaDB 11.4. Sprawdź te wersje przed zakupem.
3. Redis i Varnish to nie opcja, to konieczność na produkcji. Bez nich Magento będzie 10–50x wolniejsze.
4. Kontenery Docker/LXC oferują najlepszą izolację i wydajność przy minimalnym narzucie.
5. Lokalizacja serwera ma znaczenie — dla polskich klientów wybierz datacenter w Polsce lub Europie Środkowej.
6. Konfiguracja serwera jest równie ważna jak hardware — OPcache, PHP-FPM tuning, InnoDB buffer pool decydują o realnej wydajności.

Nie ma jednego „najlepszego” hostingu dla wszystkich. Mały sklep startujący z 500 produktami ma inne potrzeby niż platforma B2B z 200 tys. SKU i integracjami z SAP. Dopasuj hosting do skali swojego biznesu, ale nigdy nie oszczędzaj kosztem infrastruktury — bo tani hosting, który kładzie sklep przy pierwszej kampanii reklamowej, jest w rzeczywistości najdroższym możliwym wyborem.