Kontakt 24/7: 534 646 606

Serwery i utrzymanie infrastruktury dla Magento 2 .

Konfigurujemy i utrzymujemy serwery pod Magento 2 Open Source i Adobe Commerce — Redis, Varnish, Elasticsearch i skalowanie zasobów — tak, żeby sklep był szybki również w szczycie sprzedaży.

Co zapewniamy dla Magento

Pełen stack techniczny — skonfigurowany, utrzymywany i optymalizowany przez nasz zespół, żebyś Ty mógł zajmować się sprzedażą.

Panel administracyjny Magento 2 — dashboard sklepu
  1. Redis i full-page cache

    Konfigurujemy Redis dla sesji i cache oraz Varnish jako FPC — krótki czas odpowiedzi także pod dużym ruchem.

  2. Elasticsearch i wyszukiwanie

    Elasticsearch lub OpenSearch wdrożony i dostrojony pod Magento — szybkie wyszukiwanie i sprawne filtrowanie kategorii.

  3. Bezpieczeństwo i izolacja

    Dedykowane środowisko, WAF, aktualizacje bezpieczeństwa i szyfrowanie transmisji SSL/TLS w standardzie.

  4. Monitoring i alerty 24/7

    Zabbix i własna platforma monitoringu śledzą wydajność serwera i kluczowych procesów Magento przez całą dobę.

  5. Skalowanie zasobów

    Skalujemy zasoby w odpowiedzi na ruch — kampanie promocyjne, Black Friday i sprzedaż sezonowa bez przestojów.

  6. CI/CD i wdrożenia

    Pipeline zero-downtime z Capistrano lub GitHub Actions — zmiany na produkcji bez przerwy w sprzedaży.

Dlaczego infrastruktura ma takie znaczenie w Magento

Magento to jedna z najbardziej wymagających platform e-commerce. Każde wejście na stronę kategorii, każde wyszukiwanie i każde dodanie produktu do koszyka to dziesiątki zapytań do bazy danych i indeksu wyszukiwarki. Na współdzielonym hostingu albo źle dobranym serwerze sklep zwyczajnie muli — a problemy nasilają się dokładnie wtedy, kiedy ruch jest największy i każda minuta przestoju kosztuje najwięcej.

Dla klientów sklepu różnica jest odczuwalna od pierwszego kliknięcia. Szybki sklep sprzedaje lepiej — nikt nie czeka na wolno ładujące się strony, a każda dodatkowa sekunda to porzucone koszyki. Sprawna wyszukiwarka oparta o Elasticsearch zwraca wyniki natychmiast i nie zamula filtrowania kategorii, więc klient znajduje produkt, zamiast wyjść do konkurencji. Szybkość ładowania to również czynnik rankingowy w Google (Core Web Vitals) — dobra infrastruktura pracuje na widoczność sklepu w wynikach wyszukiwania.

Jest jeszcze druga strona: koszty i spokój. Stack dobrany do realnej skali sklepu kosztuje mniej niż przewymiarowany serwer trzymany „na zapas", a możliwość skalowania zasobów sprawia, że kampania reklamowa czy Black Friday przestają być loterią — to właśnie wtedy sklep musi działać najlepiej, nie najgorzej.

Minimalne wymagania Magento 2

Magento 2.4 ma konkretne wymagania techniczne. Bez ich spełnienia sklep nie wystartuje albo będzie działał znacznie poniżej możliwości:

PHP 8.3 lub 8.4 (PHP-FPM) z rozszerzeniami m.in. intl, soap, bcmath, gd — plus poprawnie ustawiony OPcache
Baza danych MySQL 8.0/8.4 lub MariaDB 10.11+ — z buforami dobranymi do rozmiaru katalogu produktów
Wyszukiwarka OpenSearch 2.x lub Elasticsearch — od Magento 2.4 wymagane, bez tego nie działa katalog
Cache i sesje Redis dla cache aplikacji i sesji; Varnish jako full-page cache (zalecany na produkcji)
Kolejki RabbitMQ dla przetwarzania asynchronicznego (opcjonalny, ale odciąża sklep przy dużej liczbie operacji)
Pamięć RAM 2 GB to absolutne minimum do instalacji — produkcyjny sklep potrzebuje realnie od 8 GB wzwyż

„Minimalne" nie znaczy „produkcyjne". Konfiguracja, która wystarcza do uruchomienia Magento, rzadko wystarcza do sprzedawania — dlatego wymagania zawsze przeliczamy na realny katalog, ruch i integracje konkretnego sklepu.

Dlaczego oddzielamy bazę danych od aplikacji

W typowej instalacji „wszystko na jednym serwerze" PHP-FPM, MySQL i Elasticsearch konkurują o te same zasoby. Wystarczy cięższa reindeksacja katalogu albo skok ruchu i baza zaczyna zabierać pamięć aplikacji — sklep zwalnia, chociaż na papierze serwer ma jeszcze zapas.

Dlatego w środowiskach produkcyjnych rozdzielamy warstwę bazodanową od aplikacyjnej. Każda z nich dostaje wtedy zasoby na wyłączność i konfigurację pod swoją rolę: MySQL własną pamięć na bufory i szybkie dyski, PHP-FPM własne CPU pod obsługę ruchu. Warstwy skalują się niezależnie — aplikację rozbudowujesz pod rosnący ruch, bazę pod rosnący katalog, bez przenoszenia całego sklepu.

To także kwestia bezpieczeństwa i utrzymania. Baza działa w sieci prywatnej, bez publicznego adresu i dostępu z internetu — na zewnątrz wystawiony jest wyłącznie front sklepu. Deploy czy restart aplikacji nie dotyka bazy, a backupy i tuning prowadzone są osobno dla każdej warstwy. Ten układ zwraca się najpóźniej przy pierwszej dużej kampanii.

Środowiska Magento budujemy na AWS

Jako certyfikowany partner AWS uruchamiamy sklepy na infrastrukturze Amazon Web Services — w europejskich regionach, z pełną separacją środowisk klientów i danymi przechowywanymi na terenie Unii Europejskiej, zgodnie z wymaganiami RODO.

Dla sklepu Magento oznacza to przede wszystkim elastyczność. Zasoby można zwiększyć przed kampanią i zmniejszyć po niej, zamiast utrzymywać przez cały rok serwer wymiarowany pod jeden szczyt sprzedaży. Baza danych i usługi wewnętrzne pracują w sieci prywatnej (VPC), a snapshoty dysków i kopie przyrostowe pozwalają szybko odtworzyć sklep po awarii — również do środowiska testowego, kiedy trzeba bezpiecznie sprawdzić większą zmianę.

Z naszej praktyki

Trzy problemy, z którymi sklepy Magento trafiają do nas najczęściej — i jak je rozwiązaliśmy.

01 Serwer dedykowany · dyski

Mocny serwer, a sklep i tak zwalniał

Sytuacja. Sklep z dużym ruchem działał na porządnym serwerze dedykowanym — sporo CPU, dużo pamięci. Mimo to w godzinach szczytu strony kategorii ładowały się po kilka sekund, a przy większych promocjach zdarzały się timeouty.

Diagnoza. Cała maszyna pracowała na jednym dysku: baza danych, pliki sklepu, logi i nocne backupy. Procesor się nudził, ale kolejka do dysku rosła — wystarczyło spojrzeć na iowait. Najdroższe podzespoły nie miały znaczenia, bo wszystko czekało na jedno urządzenie.

Rozwiązanie. Rozdzieliliśmy warstwy: baza danych dostała własny szybki wolumen NVMe, aplikacja osobny, a backupy przestały konkurować z produkcją — schodzą przyrostowo poza godzinami szczytu na oddzielne miejsce docelowe. Sesje i cache przenieśliśmy do Redisa, żeby w ogóle nie dotykały dysku.

Efekt. Ten sam sklep, ten sam ruch — stabilne czasy odpowiedzi również w szczycie, bez wymiany serwera na droższy.

02 Dostępność · wdrożenia

Sklep, który regularnie „przepraszał za przerwę techniczną"

Sytuacja. Każda aktualizacja sklepu, większy deploy czy reindeksacja katalogu kończyły się włączeniem trybu konserwacji. Klienci co kilka dni trafiali na stronę „przerwa techniczna" — najczęściej wieczorami, czyli dokładnie wtedy, kiedy kupują.

Diagnoza. Wdrożenia robione były bezpośrednio na katalogu produkcyjnym, a ciężkie operacje — reindeksy, generowanie cache — na tej samej maszynie, która obsługiwała ruch. Do tego nocny backup potrafił zablokować bazę na długie minuty.

Rozwiązanie. Zbudowaliśmy pipeline zero-downtime: nowa wersja sklepu przygotowuje się obok działającej (osobny katalog release, rozgrzany cache), a przełączenie to atomowa podmiana symlinka. Reindeksację przenieśliśmy na harmonogram poza szczytem, backupy na snapshoty, które nie blokują bazy.

Efekt. Od przebudowy sklep wdraża zmiany w środku dnia — bez trybu konserwacji i bez wylogowywania klientów z koszyków.

03 Boty · Cloudflare

Boty SEO i crawlery AI zajeżdżały serwer

Sytuacja. Obciążenie sklepu rosło z tygodnia na tydzień, choć sprzedaż stała w miejscu. W nocy serwer potrafił być bardziej zajęty niż w dzień, a wykresy ruchu nie zgadzały się z Google Analytics.

Diagnoza. W logach zamiast klientów — armia botów: agresywne crawlery „SEO", scrapery cen podszywające się pod przeglądarki i crawlery AI (m.in. GPTBot, ClaudeBot) przechodzące przez wszystkie kombinacje filtrów nawigacji warstwowej. Każde takie wejście omijało cache i generowało ciężkie zapytania do bazy oraz Elasticsearch.

Rozwiązanie. Przed sklep weszedł Cloudflare: reguły WAF i bot management odsiewają podszywający się ruch, rate limiting tnie masowe odpytywanie filtrów, a wątpliwi klienci dostają challenge zamiast dostępu do bazy. Prawdziwe roboty Google i Bing pozostały na białej liście, crawlery AI dostały jasne zasady w robots.txt, a statyka serwowana jest z edge — nie z serwera.

Efekt. Obciążenie wróciło do poziomu realnego ruchu, wykresy znów pokrywają się z analityką, a sklep przestał płacić zasobami za cudze scrapowanie.

Porozmawiajmy o Twoim sklepie Magento

Opowiedz nam, co spowalnia Twój sklep — doradzimy, co można poprawić. Konsultacja jest bezpłatna i bez zobowiązań.

Odpowiadamy w 24h
Bez zobowiązań
Certyfikowany partner AWS