VPS dla sklepu headless: architektura i utwardzanie

Sklep headless daje największą wartość wtedy, gdy infrastruktura odzwierciedla jego architekturę: front publiczny, zaplecze prywatne. Idealnie nadaje się do tego VPS — serwer wirtualny, który w pełni kontrolujesz. Ten wpis to czwarta część serii Headless commerce i praktyczny przewodnik: od podziału serwerów po konkretne ustawienia, które warto wdrożyć.

Uwaga: przykłady konfiguracji mają charakter ilustracyjny i zakładają system z rodziny Debian/Ubuntu. Przed wdrożeniem dostosuj je do swojego środowiska i przetestuj poza produkcją.

Dlaczego VPS, a nie hosting współdzielony

Hosting współdzielony ogranicza kontrolę: wspólny serwer, narzucone wersje oprogramowania, brak możliwości zbudowania sieci prywatnej. VPS pozwala:

• zainstalować dowolny stos (Node.js, bazy danych, reverse proxy, kolejki),
• odseparować zaplecze w sieci prywatnej,
• w pełni zarządzać aktualizacjami i konfiguracją zabezpieczeń,
• skalować zasoby wraz z ruchem,
• wybrać lokalizację serwerów (np. w UE) i mieć kontrolę nad danymi,
• zautomatyzować wdrożenia (CI/CD) i odtwarzanie środowiska.

Ceną jest odpowiedzialność za administrację — o tym piszemy w sekcji o kosztach.

Jak wybrać dostawcę VPS

Zwróć uwagę na:

1. Lokalizację centrów danych — najlepiej w UE, ze względu na RODO i opóźnienia.
2. Sieć prywatną — możliwość połączenia kilku serwerów w prywatną podsieć bez ruchu przez publiczny internet.
3. Migawki i kopie — wbudowane snapshoty ułatwiają odtwarzanie (ale nie zastępują własnych kopii poza dostawcą).
4. Ochronę przed DDoS — zakres i sposób działania.
5. API i automatyzację — ułatwia tworzenie środowisk z kodu.
6. IPv6, firewall dostawcy i reputację adresów IP — wpływają na dostarczalność poczty i bezpieczeństwo.
7. Warunki umowy i wsparcie — czas reakcji na awarie.

Przykładowa architektura

1. VPS „front” — publiczny. Pracują na nim: reverse proxy (np. Nginx lub Caddy), storefront (Next.js lub Astro) i warstwa pośrednia (BFF).
2. VPS „backend” — prywatny. Zaplecze sklepu, baza danych i ewentualnie wyszukiwarka, dostępne wyłącznie z serwera „front” i przez VPN dla administratorów.
3. Sieć prywatna / VPN — łączy serwery; ruch między nimi nie wychodzi do internetu.
4. Kopie zapasowe — szyfrowane i przechowywane poza serwerami.
5. Monitoring — dostępność, zasoby, błędy i zdarzenia bezpieczeństwa.

Przy mniejszych projektach całość może działać na jednym serwerze, ale z logicznym rozdzieleniem (osobne kontenery, prywatna sieć wewnętrzna), a zaplecze nadal bez publicznego dostępu. Z czasem warto rozdzielić je fizycznie.

Wymiarowanie: ile zasobów potrzeba

Nie ma jednej liczby, ale kilka reguł pomaga:

• Storefront statyczny lub z pamięcią podręczną (np. Astro) potrzebuje bardzo mało zasobów — większość ruchu obsługuje serwer plików.
• Renderowanie po stronie serwera (Next.js) wymaga więcej procesora i pamięci, zwłaszcza przy dużym ruchu bez cache.
• Zaplecze z bazą danych potrzebuje przede wszystkim pamięci i szybkiego dysku.
• Zaczynaj od skromnej konfiguracji, mierz obciążenie i skaluj w razie potrzeby; przy ruchu sezonowym warto zaplanować rezerwę.

Utwardzanie serwera krok po kroku

1. Dostęp SSH

Logowanie wyłącznie kluczami, bez haseł i bez konta roota. Fragment konfiguracji:

# /etc/ssh/sshd_config (fragment)
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AllowUsers deploy

Po zmianie przeładuj usługę i sprawdź logowanie w drugiej sesji, zanim zamkniesz pierwszą. Dla serwera zaplecza rozważ udostępnienie SSH wyłącznie przez VPN.

2. Zapora sieciowa

Domyślnie blokuj wszystko, otwórz tylko to, co potrzebne. Przykład dla serwera frontu (UFW):

ufw default deny incoming
ufw default allow outgoing
ufw allow 80/tcp
ufw allow 443/tcp
ufw limit 22/tcp
ufw enable

Na serwerze zaplecza otwarte powinno być wyłącznie to, co dotyczy sieci prywatnej i VPN — żadnych publicznych portów 80/443. Dodatkowo skorzystaj z zapory u dostawcy VPS jako drugiej warstwy.

3. Automatyczne aktualizacje bezpieczeństwa

Włącz automatyczne poprawki bezpieczeństwa systemu (np. unattended-upgrades) i zaplanuj okna na aktualizacje większe (jądro, PHP, bazy danych). To jedna z najtańszych i najskuteczniejszych form ochrony — zob. bezpieczeństwo sklepów na PHP.

4. Ochrona przed zgadywaniem haseł

Narzędzia w rodzaju fail2ban blokują adresy, z których pochodzą powtarzające się nieudane próby logowania. Fragment przykładowej konfiguracji:

# /etc/fail2ban/jail.local (fragment)
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

5. Docker: pułapka z opublikowanymi portami

Jeśli używasz kontenerów, pamiętaj: opublikowany port kontenera może omijać reguły zapory hosta. Dlatego:

• porty wewnętrzne wiąż z interfejsem lokalnym (127.0.0.1:3000:3000),
• komunikację między usługami prowadź siecią wewnętrzną Dockera,
• nie publikuj portów baz danych i paneli w ogóle.

Przykład (fragment docker-compose.yml):

services:
  storefront:
    image: sklep-storefront:latest
    ports:
      - "127.0.0.1:3000:3000"
    networks: [front]
  bff:
    image: sklep-bff:latest
    networks: [front, private]
networks:
  front: {}
  private:
    internal: true

Sieć oznaczona jako internal nie ma dostępu do internetu — idealna dla komponentów, które nie muszą wychodzić na zewnątrz.

6. Reverse proxy i nagłówki

Reverse proxy przyjmuje ruch z internetu, obsługuje HTTPS i przekazuje żądania do aplikacji. Przykład (Nginx, fragment):

server_tokens off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
proxy_hide_header X-Powered-By;

Dodaj politykę źródeł treści (Content-Security-Policy) dostosowaną do aplikacji oraz automatyczne odnawianie certyfikatów (np. Let’s Encrypt lub serwer Caddy, który robi to domyślnie). Nagłówki to też element ukrywania platformy.

7. Baza danych tylko w sieci prywatnej

Serwer bazy nasłuchuje wyłącznie na adresie sieci prywatnej, a konto aplikacji ma minimalne uprawnienia (bez prawa do tworzenia użytkowników i zmiany struktury w produkcji). Przykład dla MariaDB lub MySQL:

# fragment konfiguracji
bind-address = 10.0.0.2

(adres z Twojej sieci prywatnej). Połączenia z zewnątrz do bazy powinny być zablokowane zaporą.

8. Sekrety poza kodem

Klucze API, hasła i tokeny trzymaj w zmiennych środowiskowych lub menedżerze sekretów, nigdy w repozytorium. Rotuj je regularnie i po każdej zmianie osób w zespole. Klucze zaplecza istnieją tylko na serwerze BFF, nigdy w kodzie przeglądarki — zob. izolacja danych.

9. Dostęp administratorów przez VPN

Panel zaplecza i SSH do serwera prywatnego udostępnij wyłącznie przez VPN (np. WireGuard) z uwierzytelnianiem wieloskładnikowym tam, gdzie to możliwe. Lista osób z dostępem powinna być krótka i regularnie przeglądana.

Wdrożenia: CI/CD i zero przestojów

Ręczne kopiowanie plików na serwer to prosta droga do błędów. Lepsze podejście:

1. Kod trafia do repozytorium, a potok CI buduje i testuje aplikację.
2. Gotowa wersja (obraz kontenera lub paczka) jest wdrażana na serwer przez ograniczone konto z kluczem SSH.
3. Nowa wersja uruchamia się obok starej, a po sprawdzeniu zdrowia usługi ruch jest przełączany (wdrożenie bez przestoju).
4. W razie problemu wracasz do poprzedniej wersji jednym poleceniem.

Dla storefrontu statycznego wdrożenie to w praktyce podmiana katalogu z plikami.

Kopie zapasowe i odtwarzanie

Zasada 3-2-1: trzy kopie, na dwóch różnych nośnikach, jedna poza lokalizacją. Praktycznie:

• szyfrowane kopie bazy i plików (np. narzędziami typu restic lub borg) przechowywane poza dostawcą VPS,
• harmonogram dopasowany do tego, ile danych możesz stracić (RPO),
• opisany i ćwiczony proces odtwarzania, który mieści się w akceptowalnym czasie przestoju (RTO),
• regularny test odtworzenia na osobnym środowisku.

Monitoring i reakcja

Monitoruj co najmniej:

• dostępność strony i kluczowych ścieżek (np. koszyka, płatności),
• zużycie procesora, pamięci, dysku i sieci,
• błędy aplikacji i odpowiedzi 5xx,
• próby logowania i inne podejrzane zdarzenia,
• ważność certyfikatów oraz aktualność systemu.

Alerty powinny trafiać do osoby, która może zareagować, także poza godzinami pracy, jeśli sklep sprzedaje całą dobę. Logi przechowuj poza serwerem, aby nie zniknęły po incydencie.

Wydajność: pamięć podręczna i CDN

Storefront serwowany z pamięci podręcznej (strony statyczne, przyrostowe odświeżanie w Next.js) obciąża serwer znacznie mniej. Opcjonalna sieć CDN skraca czas odpowiedzi i może dostarczać obrazy. Jeśli używasz usługi pośredniczącej (CDN/WAF), rozważ ograniczenie dostępu do serwera źródłowego tylko do jej adresów — wiąże się to z przekazaniem ruchu zewnętrznemu dostawcy, więc oceń to pod kątem RODO i potrzeb.

Koszty i odpowiedzialność

VPS bywa tańszy od rozbudowanego hostingu zarządzanego, ale wymaga administracji: aktualizacji, monitoringu, kopii i reagowania na incydenty. Koszt miesięczny infrastruktury to zwykle kwota rzędu od kilkudziesięciu do kilkuset złotych, zależnie od zasobów — ale prawdziwym kosztem jest czas ludzi, który to utrzyma. Dlatego wielu klientów łączy wdrożenie z naszą opieką techniczną i outsourcingiem IT: my dbamy o aktualizacje, kopie i monitoring, a Ty o biznes.

Najczęstsze błędy

• publiczne porty baz danych i paneli,
• opublikowane porty w Dockerze omijające zaporę,
• brak testu odtwarzania z kopii,
• klucze i hasła w repozytorium,
• jeden serwer „do wszystkiego” bez żadnej izolacji,
• zaniedbane aktualizacje „bo wszystko działa”,
• brak monitoringu — o awarii dowiadujesz się od klientów.

Lista kontrolna przed uruchomieniem

1. SSH tylko kluczami, brak logowania roota.
2. Zapora domyślnie blokuje ruch przychodzący; otwarte tylko 80/443 na froncie.
3. Zaplecze i baza dostępne wyłącznie w sieci prywatnej.
4. Automatyczne aktualizacje bezpieczeństwa włączone.
5. Ochrona przed zgadywaniem haseł skonfigurowana.
6. Nagłówki bezpieczeństwa ustawione, wersje serwerów ukryte.
7. Sekrety poza kodem, rotowane.
8. Kopie zapasowe działają i przetestowano odtworzenie.
9. Monitoring i alerty aktywne.
10. Test z zewnątrz potwierdza, że zaplecze nie jest widoczne.

Co dalej

Poprzednia część serii: izolacja danych. Następna: Next.js czy Astro na storefront. Chcesz omówić infrastrukturę dla swojego sklepu? Zobacz headless commerce i napisz do nas.