Wielu właścicieli sklepów stoi przed tym samym dylematem: VPS czy serwer dedykowany. Z jednej strony kusi niższy koszt startu, z drugiej – potrzeba stabilności i zapasu mocy pod kampanie, dropy czy Black Friday. Do tego dochodzą obawy: ile to realnie będzie kosztować, czy „dedyki” nie są zbyt sztywne, a VPS nie „zadławi się”, gdy ruch podwoi się?
W tym artykule wyjaśniamy różnice między tymi rozwiązaniami. Pokażemy, jak wybór wpływa na szybkość sklepu i konwersję, jak planować skalowanie (w górę i wszerz), jakie są koszty w całym cyklu życia (nie tylko abonament), oraz co z bezpieczeństwem, kopiami zapasowymi i wymaganiami typu PCI DSS. Dostaniesz też proste sygnały, że pora przejść z VPS na dedyka oraz ścieżkę migracji z minimalnym ryzykiem. Dzięki temu podejmiesz spokojną, racjonalną decyzję — dopasowaną do etapu rozwoju Twojego sklepu niezależnie od wybranego silnika.
Z tego artykułu dowiesz się:
Na czym polega różnica i dla kogo jest które rozwiązanie
Zanim porównamy konkretne opcje, ustalmy ramy decyzji: liczy się przewidywalność wydajności, możliwość skalowania pod kampanie oraz realny koszt utrzymania w czasie. Poniżej wyjaśniam, czym różni się VPS, serwer dedykowany i prywatna chmura – oraz w jakich sytuacjach każda z nich będzie najlepszym wyborem dla sklepu na Magento, Shopware czy PrestaShop. Dzięki temu szybciej dopasujesz środowisko do etapu rozwoju i planów sprzedażowych.
Czym jest VPS (współdzielony serwer fizyczny, wydzielone zasoby, ograniczenia)
VPS (Virtual Private Server) to „mieszkanie w bloku”. Na jednym mocnym serwerze fizycznym działa wiele wirtualnych serwerów — każdy ma przydzielone CPU, RAM i miejsce na dysku. Dostajesz własny dostęp root, możesz instalować oprogramowanie i konfigurować system pod sklep.
Plusy:
-
niski koszt startu i szybkie uruchomienie,
-
łatwe „dokręcenie” zasobów (np. +2 vCPU, +4 GB RAM),
-
wystarczające dla młodych sklepów, sandboxów i środowisk deweloperskich.
O czym pamiętać:
-
wciąż dzielisz fizyczną maszynę z innymi („sąsiedzi” mogą wpływać na I/O dysku i sieć),
-
limit jednego mocnego wątku CPU i operacji dyskowych bywa „sufitem” dla bazy i indeksacji,
-
przy skokach ruchu (kampanie, premiery) łatwiej o timeouty i kolejki żądań.
Dla kogo: startujące e‑commerce, mniejsze katalogi, projekty pilotażowe i sklepy bez dużych pików ruchu. Dobry „przystanek” przed przesiadką na mocniejszą infrastrukturę.
Czym jest serwer dedykowany (pełna izolacja i kontrola)
Serwer dedykowany to „dom jednorodzinny”. Cała maszyna fizyczna jest tylko dla Ciebie: procesor(y), pamięć, dyski NVMe/HDD, karty sieciowe. Masz pełną izolację i przewidywalność — nikt poza Tobą nie „dotyka” sprzętu.
Plusy:
-
stała i wysoka wydajność (brak efektu „głośnego sąsiada”),
-
pełna kontrola nad konfiguracją: RAID, podział dysków, jądro systemu, wersje usług,
-
lepsza baza pod krytyczne elementy: baza danych, Redis, wyszukiwarka (OpenSearch/ES), kolejki.
Na co uważać:
-
wyższy koszt wejścia niż VPS,
-
jeśli źle dobierzesz specyfikację, możesz przepłacać za niewykorzystane zasoby,
-
sens zyskuje z opieką operacyjną (monitoring 24/7, szybkie reakcje, regularne przeglądy).
Dla kogo: sklepy z większym ruchem i sezonowością, projekty z wieloma integracjami (ERP, PIM, marketplace’y), wymagające stabilnych czasów odpowiedzi i krótkich okien serwisowych.
Kiedy rozważyć prywatną chmurę (elastyczność jak w chmurze, przewidywalność jak na dedyku)
Prywatna chmura (np. klaster kilku serwerów) łączy atuty obu światów. Z zewnątrz skalujesz zasoby „kliknięciem”, a pod spodem wiesz, na jakim sprzęcie to działa i masz nad nim kontrolę. To dobre rozwiązanie, gdy potrzebujesz i elastyczności, i stałej wydajności.
Kiedy to ma sens:
-
masz kilka środowisk (prod/stage/dev) i chcesz łatwo nimi żonglować,
-
liczysz się z pikami x3–x10 i chcesz dokładać węzły bez migracji,
-
planujesz architekturę rozproszoną (HA) — kilka webów, osobne klastry dla bazy i cache,
-
wymagasz twardych parametrów bezpieczeństwa i zgodności (np. lokalizacja danych, audyty).
Co zyskujesz:
-
elastyczne skalowanie poziome (więcej maszyn) i pionowe,
-
przewidywalność kosztów i wydajności — bez „niespodzianek” multi‑tenancy,
-
łatwiejsze wdrożenia bez przestojów (blue/green, rolling update) i lepszą odporność na awarie.
Dla kogo: średnie i duże e‑commerce, które rosną, robią intensywne kampanie, mają ambitne SLA i chcą uniknąć „szklanego sufitu” pojedynczego VPS‑a lub jednego dedyka.
Wydajność i stabilność pod ruchem
Im większy ruch, tym mniej miejsca na „zadyszki” infrastruktury. Dla e‑commerce liczy się nie tylko średnia szybkość, ale to, jak sklep zachowuje się w gorszych chwilach – gdy jednocześnie wchodzi wielu klientów, a baza, cache i dyski są pod obciążeniem. Poniżej – trzy kluczowe obszary, które najszybciej pokazują różnicę między VPS a serwerem dedykowanym (i prywatną chmurą).
CPU, RAM i dyski (I/O) – wpływ „sąsiadów” na VPS vs izolacja na dedyku
Na VPS‑ie współdzielisz fizyczny procesor i podsystem dyskowy z innymi. Gdy „sąsiad” robi kopie, indeksuje lub ma skok ruchu, Twoje operacje dyskowe i czas CPU mogą się wydłużyć. Objawy:
-
skaczący czas odpowiedzi przy identycznym ruchu,
-
kolejki żądań, timeouty, sporadyczne błędy 5xx,
-
„zrywy” w czasie zapisu/odczytu (I/O).
Na serwerze dedykowanym masz pełną izolację: to Ty kontrolujesz CPU, RAM i dyski (np. RAID na NVMe). Dzięki temu czasy są przewidywalne – łatwiej utrzymać stabilny TTFB i czas odpowiedzi API.
Praktyka (proste progi do kontroli):
-
trzymaj średnie użycie CPU w ruchu <70% z zapasem na piki,
-
nie dopuszczaj do stałego użycia pamięci ~100% (zostaw min. 20% luzu),
-
unikaj wymiany na SWAP; jeśli zaczyna „pracować”, to sygnał do powiększenia RAM lub optymalizacji,
-
jeśli panel dostawcy pokazuje „kradzież CPU/steal” – na VPS to znak, że sąsiedzi zabierają czas procesora.
Baza danych, Redis, wyszukiwarka – kiedy VPS zaczyna „dusić” krytyczne usługi
To „serce” sklepu. Gdy zabraknie szybkości jednego rdzenia lub I/O, najpierw cierpi DB i cache:
-
rośnie liczba wolnych zapytań i blokad,
-
Redis zaczyna wyrzucać klucze (evictions) lub kolejki się wydłużają,
-
reindeksacje i crony trwają coraz dłużej.
Na VPS granicą bywa wydajność pojedynczego wątku CPU i dysku współdzielonego. Jeśli:
-
piki sprzedażowe powodują timeouty w koszyku/płatności,
-
odczyt/zapis w DB „faluje” mimo podobnego ruchu,
-
a reindeksacje wpływają na klientów,
…to zwykle czas przenieść DB/Redis/wyszukiwarkę na dedyk (lub do prywatnej chmury z osobnymi węzłami). Zyskujesz stały I/O, więcej pamięci pod cache i możliwość rozdzielenia ról (web ↔ DB ↔ wyszukiwarka).
Czas odpowiedzi a konwersja: jak prosto sprawdzić p95/p99 bez specjalistycznych narzędzi
p95 / p99 — o co chodzi?
-
To miary „ogonów” czasów ładowania. p95 oznacza, że 95% żądań kończy się w tym czasie lub szybciej (5% jest wolniejszych). p99 – 99% żądań kończy się w tym czasie lub szybciej (1% jest wolniejszych).
-
Pokazują stabilność pod obciążeniem lepiej niż średnia.
-
Przykład: p95 = 900 ms, p99 = 1,6 s → większość działa szybko, ale co setne żądanie jest już odczuwalnie wolne.
-
Cel: trzymać p95/p99 możliwie nisko i stabilnie w godzinach szczytu (lista, produkt, koszyk, płatność).
Prosty sposób pomiaru, bez kupowania narzędzi:
-
Otwórz sklep w Chrome DevTools → Network. Przejdź typową ścieżkę: lista → karta produktu → koszyk → checkout (kilka razy, także podczas kampanii, gdy to możliwe).
-
Zapisz HAR (Export HAR).
-
Otwórz plik w Excelu/Arkuszach Google, posortuj po kolumnie Duration (lub Time).
-
Wyznacz p95/p99: weź wartości z pozycji odpowiadających 95% i 99% liczby wpisów (np. przy 200 żądaniach – 190. i 198. wiersz po sortowaniu rosnąco).
Wskazówki interpretacyjne:
-
patrz osobno na TTFB (czas do pierwszego bajtu) i na czas całkowity; wysoki TTFB to zwykle serwer/DB, wysoki czas całkowity – często front/zasoby,
-
porównuj p95/p99 pomiędzy VPS a dedykiem przy zbliżonym ruchu,
-
jeżeli p95 rośnie gwałtownie w godzinach szczytu, a średnia wygląda „ok” – to sygnał, że infrastruktura nie trzyma formy pod obciążeniem (typowy efekt VPS).
Należy dążyć do stabilnego p95 na kluczowych krokach (lista, PDP, koszyk, API płatności). Stabilność jest ważniejsza niż „rekordy” w spokoju – to ona chroni koszyk, gdy ruch skacze.
Skalowanie i gotowość na piki sprzedażowe
Chcę, żeby Twój sklep był szybki wtedy, gdy naprawdę tego potrzebujesz — podczas kampanii, dropów i Black Friday. Dlatego spojrzymy na skalowanie po ludzku: najpierw wyciskam maksimum z tego, co masz, a dopiero potem dokładam moc. Pokażę Ci proste zasady, dzięki którym unikniesz duszenia się serwera i nerwowych decyzji na ostatnią chwilę.
Skalowanie w górę (więcej zasobów) i w szerz (więcej serwerów) – kiedy które ma sens
W górę (pionowo) – dokładam CPU/RAM/dyski w tej samej maszynie.
Sprawdza się, gdy problem jest prosty: brakuje pamięci, pojedynczy procesor „dobija” do 80–90%, a baza danych potrzebuje więcej I/O (operacji dyskowych). Dobre na krótką metę i dla mniejszych sklepów.
W szerz (poziomo) – dokładam kolejne serwery i dzielę rolę: web osobno, baza osobno, Redis/wyszukiwarka osobno.
To daje odporność na awarie i lepszą przewidywalność przy dużym ruchu. Wymaga od sklepu „odklejenia” sesji (np. do Redis), wspólnego storage na media lub mechanizmu ich synchronizacji oraz prostego balansu ruchu (load balancer).
Jak podjąć decyzję?
-
Jeśli pojedynczy wątek CPU jest wąskim gardłem (np. wolne zapytania w DB) — najpierw w górę.
-
Jeśli masz piki i chcesz bezpieczeństwa działania – w szerz, nawet minimalnie (2× web + osobna DB).
-
Jeśli rośniesz i chcesz święty spokój na dłużej — plan pod skalowanie poziome z myślą o HA (wysoka dostępność).
Black Friday i kampanie – jak planować limity i zapas mocy
Nie chodzi o to, by „przepłacać zawsze”. Chodzi o to, by na czas kampanii mieć zapas, a poza nimi działać rozsądnie.
-
Zostaw bufor: celuj w 30–40% zapasu CPU w godzinach szczytu; unikaj stałego użycia RAM blisko 100%.
-
Włącz bezpieczniki: ogranicz równoległą liczbę żądań, ustaw rozsądne time‑outy backendu, dodaj kolejkę.
-
Przed startem kampanii odśwież cache najpopularniejszych stron; unieważniaj cache partiami.
-
Przenieś statyczne zasoby na CDN, aby zmniejszyć obciążenie aplikacji.
-
Wykonaj krótki test obciążenia (5–10 minut, ruch ×2 względem dnia roboczego) i sprawdź p95/p99 oraz błędy 5xx.
-
W szczycie wprowadzaj tylko małe, odwracalne zmiany i miej przygotowany plan szybkiego przywrócenia poprzedniej wersji.
Sygnały, że pora przejść z VPS na serwer dedykowany (wysokie użycie CPU, I/O wait, timeouty, rosnący ruch)
Reaguj, gdy widzisz kilka z tych objawów jednocześnie:
-
stałe obciążenie CPU >70–80% w godzinach szczytu, pojawia się SWAP,
-
rosnący czas oczekiwania na dysk (I/O wait), niestabilne czasy zapisu/odczytu przy podobnym ruchu,
-
błędy 5xx w koszyku lub płatności, wiszące żądania podczas wzmożonego ruchu,
-
wydłużające się reindeksacje, blokady w bazie, wyrzucanie kluczy w Redis,
-
na VPS widoczny „steal time” (kradzież czasu CPU przez współdzielonych sąsiadów),
-
zaplanowane kampanie i nowe kanały sprzedaży, które zwiększą obciążenie.
W takiej sytuacji przejdź na serwer dedykowany (izolacja i przewidywalność) albo do prywatnej chmury (kilka węzłów i łatwe dokładanie mocy), aby zachować stabilność w najważniejszych momentach sprzedaży.
Koszty: dziś vs cały cykl życia (TCO – całkowity koszt posiadania)
Cena „na miesiąc” to tylko początek. TCO (Total Cost of Ownership) obejmuje także czas ludzi, utrzymanie, ryzyko przestojów, kopie zapasowe, testy odtwarzania, a nawet koszt migracji po 24–36 miesiącach. Twoim celem jest przewidywalny koszt na sprzedaż zrealizowaną bez zakłóceń, a nie najtańsza faktura dziś.
Miesięczny abonament to nie wszystko – koszt utraconej sprzedaży przy przestojach
Przestój boli bardziej niż „droższy” serwer.
Policz to w prosty sposób:
sesje/min × współczynnik konwersji × średnia wartość koszyka (AOV) = strata/min
Przykład:
10 sesji/min, CR = 2%, AOV = 250 zł → 50 zł straty za minutę.
20 minut niedostępności = ~1 000 zł.
Dodaj do tego: płatne kampanie, które w tym czasie przepalały ruch, zwroty i reklamacje, spadek zaufania.
Stabilność i szybkie czasy odpowiedzi często są tańsze niż „oszczędność” na infrastrukturze.
„Ukryte” pozycje: transfer, snapshoty, adresy IP, licencje paneli/baz
Zanim porównasz oferty, zrób checklistę kosztów dodatkowych:
-
Transfer i egress (wyjście do internetu) – w chmurach bywa rozliczany osobno; sprawdź stawki i progi.
-
Przestrzeń na backupy i snapshoty – opłata za GB + ewentualne odtworzenia między DC.
-
Dodatkowe adresy IP – przy rozdzieleniu ról (WWW/DB/Redis) IP szybko przybywa.
-
Licencje – panele (np. cPanel/Plesk), bazy (np. MySQL Enterprise), wyszukiwarka, WAF, skanery bezpieczeństwa.
-
CDN – ruch i magazyn na obrazy/statyczne pliki.
-
Środowiska stage/dev – często „zjadacze” zasobów pomijani w kalkulacji.
-
Monitoring i alerty 24/7 – czy są w cenie? jakie progi? kto reaguje i w ile minut?
-
Testy DR i odtwarzania – zaplanuj częstotliwość i policz czas ludzi.
-
Migracje/upgrade sprzętu – co 24–36 miesięcy to realny koszt projektu, nie tylko „przeniesienie plików”.
Bezpieczeństwo, zgodność i odpowiedzialność operacyjna
Szybkość jest ważna, ale bezpieczeństwo i przewidywalność działań decydują o tym, czy sklep utrzyma sprzedaż w krytycznych momentach i spełni wymagania klientów oraz regulatorów. Poniżej dostajesz praktyczne minimum: jak ustalić sensowne parametry kopii, co z wymogami PCI DSS / NIS2 / DORA i jak poukładać odpowiedzialność 24/7, żeby nie było wątpliwości „kto i w ile minut reaguje”.
Kopie zapasowe i odtwarzanie po awarii (RPO/RTO – jak to ustalić po ludzku)
RPO (Recovery Point Objective) – ile danych możesz maksymalnie stracić w razie awarii.
RTO (Recovery Time Objective) – ile czasu możesz być offline, zanim biznes zacznie realnie tracić.
Jak ustalić to sensownie:
-
Wyjdź od liczb: średnia wartość zamówienia × zamówienia/minuta → policz koszt minuty przerwy i straty danych.
-
Ustal RPO dla bazy i plików osobno (np. DB: 5–15 min, media: 1–4 h).
-
Ustal RTO dla produkcji (np. 30–60 min) i dla mniej krytycznych usług (dłużej).
-
Zastosuj prostą zasadę 3‑2‑1: trzy kopie, na dwóch różnych nośnikach, jedna poza główną lokalizacją; rozważ backup niezmienialny (ang. immutable) na okres retencji.
-
Testuj odtwarzanie cyklicznie (np. raz na kwartał): przywrócenie bazy + kluczowych plików do środowiska testowego i krótki przegląd integralności (logowanie, koszyk, płatność, integracje).
-
Opisz w dwóch zdaniach „plan odtwarzania”: kto uruchamia procedurę, w jakiej kolejności, jak wygląda decyzja o przywróceniu z konkretnej kopii.
Wymagania PCI DSS / NIS2 / DORA – co łatwiej spełnić na jakiej platformie
PCI DSS (płatności kartowe).
-
Łatwiej spełnić na serwerze dedykowanym lub w prywatnej chmurze: masz pełną kontrolę nad segmentacją sieci (wydzielenie strefy płatności), logowaniem, wersjami usług, hardeningiem i skanami.
-
Na VPS też można, ale potrzebujesz mocnych gwarancji od dostawcy (segmentacja, logi, skany, aktualizacje hosta), a część kontroli jest poza Tobą — trudniej o spójną dokumentację i audyt ścieżki.
NIS2 (bezpieczeństwo sieci i informacji).
-
Liczy się zarządzanie ryzykiem, ciągłość działania, zgłaszanie incydentów, łańcuch dostaw. Dedyk/prywatna chmura ułatwia wdrożenie polityk (patching, MFA, kopie, monitoring, segmentacja) i dowodów dla audytu.
-
VPS wymaga doprecyzowania podziału odpowiedzialności z dostawcą (host vs maszyna wirtualna), zwłaszcza dla logów i aktualizacji warstwy hypervisora.
DORA (ciągłość i odporność operacyjna w finansach).
-
Kluczowe są testy odporności, scenariusze awarii, plany odtworzeniowe, raportowanie. Prywatna chmura/dedyk daje przewidywalne parametry i łatwiejszą automatyzację testów DR, failoverów i klasyfikację incydentów.
-
Na VPS plan zadziała, ale pamiętaj o ograniczeniach w mierzeniu i dokumentowaniu części kontrolek po stronie warstwy fizycznej.
Praktyczne wskazówki (niezależnie od platformy):
-
wymuś MFA, kontrolę dostępu „najmniejszego uprzywilejowania”, regularne aktualizacje,
-
centralizuj logi (system, www, DB, WAF) i trzymaj je w trybie tylko‑do‑zapisu przez wymaganą retencję,
-
utrzymuj rejestr aktywów i mapę integracji (kto, co, gdzie się łączy),
-
zaplanuj procedurę zgłoszeń incydentów z kontaktami i czasami reakcji.
Kto reaguje 24/7 i w ile minut (SLA, dyżury – własne vs. dostawcy)
Nie zostawiaj tego „domyślnie”. Ustal i zapisz:
-
Matryca odpowiedzialności (RACI): kto przyjmuje alert (1. linia), kto diagnozuje (inżynier), kto eskaluje i kto komunikuje sytuację (np. do działu marketingu i obsługi klienta).
-
Czasy reakcji (SLA): np. 15 min – przyjęcie i weryfikacja alertu, 1 h – pierwsze działania naprawcze, + aktualizacje co 30 min.
-
Kanały i kolejność: monitoring → alert (SMS/phone) → dyżurny 1. linii → inżynier → eskalacja menedżerska.
-
Zakres „w cenie”: doprecyzuj, czy monitoring, patching, WAF/CDN, kopie i testy odtwarzania są w usłudze, czy rozliczane osobno.
Własne dyżury vs. dostawca (SDO):
-
Własne dyżury – pełna kontrola, ale realny koszt ludzi i zastępstw.
-
Dostawca 24/7 (SDO) – krótszy czas reakcji, gotowe runbooki i narzędzia; ważne: zweryfikuj, kto ma dostęp produkcyjny, jakie są okna na zmiany i jak wygląda wspólne post‑mortem po incydencie.
Prosta reguła: jeżeli sklep zarabia także nocą i w weekendy, wybierz model z realnym wsparciem 24/7 i twardym SLA. W innym przypadku – zapewnij przynajmniej dyżury na okresy kampanii oraz jasny scenariusz reakcji poza godzinami pracy.
Dzięki tym ustaleniom infrastruktura nie tylko działa szybko, ale też spełnia wymagania, daje się audytować i – co najważniejsze – pozwala wracać do normalnej pracy po awarii w granicach, które akceptujesz biznesowo.
Podsumowanie i następne kroki
Dobra decyzja hostingowa nie polega na „najtańszym abonamencie”, tylko na przewidywalnej sprzedaży bez przerw. Jeśli Twój sklep rośnie, planujesz kampanie i chcesz spać spokojnie w szczytach, postaw na rozwiązanie, które daje zapas mocy, prosty plan skalowania i jasny podział odpowiedzialności (monitoring, kopie, reakcja 24/7). VPS sprawdzi się na starcie i przy umiarkowanym ruchu. Serwer dedykowany lub prywatna chmura wygrają tam, gdzie liczy się stała wydajność, izolacja i zgodność (PCI DSS / NIS2 / DORA).
Nie musisz przebudowywać wszystkiego od razu. Wystarczy, że krok po kroku uporządkujesz kluczowe elementy: czasy odpowiedzi (p95/p99), kopie i odtwarzanie (RPO/RTO), limity na szczyty oraz rolę „kto reaguje i kiedy”. To od razu przekłada się na stabilność konwersji.
6 pytań kontrolnych przed ostatecznym wyborem
-
Ruch i szczyty – czy wiem, jakich pików spodziewam się w najbliższych 3–6 miesiącach (kampanie, Black Friday, nowe kanały)?
-
Wydajność dziś – czy p95/p99 na liście, karcie produktu, koszyku i płatności mieszczą się w akceptowalnych granicach w godzinach szczytu?
-
Zapas mocy – czy mam realny bufor CPU/RAM i dysków (30–40% w szczycie), a nie „na styk”?
-
Architektura – czy role są rozdzielone (WWW, DB, Redis/wyszukiwarka), a sesje i statyki są uporządkowane (Redis/CDN)?
-
Odzyskiwanie po awarii – czy RPO/RTO są ustalone z biznesem i czy ostatni test odtwarzania zakończył się powodzeniem?
-
Odpowiedzialność 24/7 – czy wiem, kto przyjmuje alerty, w ile minut reaguje (SLA) i jak wygląda eskalacja nocą i w weekendy?
Jeśli na 2–3 pytania odpowiadasz „nie” lub „nie wiem”, to sygnał, że pora wzmocnić infrastrukturę albo procesy i… skontaktować się z nami!
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
