"WordPress jest darmowy i tani w utrzymaniu." To zdanie słyszysz non-stop. Przez pierwszy rok jest w nim sporo prawdy.
Potem zaczyna się właściwy rachunek.
Headless CMS i Sanity jako naturalna droga odejścia od WordPressa — to temat, który wraca regularnie w rozmowach o nowoczesnych stackach webowych. Sanity to dobry wybór dla większości projektów, szczególnie przy integracji z Next.js. Jest jednak jedna rzecz, której Sanity nie daje: pełna własność danych. Treści i pliki przechowywane są na serwerach Sanity — infrastruktura AWS i Vercel. Dla większości klientów to nie problem. Dla niektórych — jest.
O tym jest ten artykuł.
Ile naprawdę kosztuje WordPress
Temat ten poruszyłem już w poście “WordPress nie jest tani. Jest drogi — tylko w inny sposób”.
SiteGround — jeden z najczęściej polecanych hostingów WordPress. Plan Startup: $2.99/mies. przez pierwszy rok. Cena odnowienia? $17.99/mies. — wzrost o 501%. Plan GrowBig, potrzebny gdy w grę wchodzi środowisko stagingowe i kilka stron naraz, kosztuje przy odnowieniu $29.99/mies., czyli ok. $360/rok.
Kinsta nie stosuje takich promocji — zaczyna od $35/mies. bez rabatów. Ale Kinsta nie zawiera hostingu poczty e-mail. Google Workspace doliczyć osobno.
Realny koszt hostingu dla strony firmowej od drugiego roku: $15–35/mies. Nie $3.
Wtyczki: koszt, który nie pojawia się w wycenie
WordPress core jest darmowy. Każda nietrywalna funkcja — już nie.
Każda z tych pozycji ma konkretne uzasadnienie. WP Rocket istnieje dlatego, że WordPress bez cache jest wolny architektonicznie — każde zapytanie przechodzi przez PHP do bazy danych. To nie kwestia słabego serwera, lecz wbudowany koszt tej platformy. WP Rocket jest obejściem problemu, który WordPress ma z założenia.
Wordfence Premium — darmowa wersja aktualizuje sygnatury zagrożeń z 30-dniowym opóźnieniem względem płatnej. Przez miesiąc od wykrycia exploita w popularnej wtyczce witryna pozostaje bez aktualnej ochrony. Przy stronie firmowej przetwarzającej dane klientów to nieakceptowalne.
Realny koszt utrzymania strony firmowej od drugiego roku:
To bez kosztu developera poświęcającego 1–2 godziny miesięcznie na aktualizacje i gaszenie pożarów po konfliktach między wtyczkami. Przy stawce 150 zł/h doliczyć 1 800–3 600 zł rocznie.
Przy WooCommerce do zestawu dochodzą oficjalne rozszerzenia Automattic: subskrypcje $279/rok, porzucone koszyki $79, opcje produktów $79. Przy trzech, czterech rozszerzeniach przekraczasz $500–600/rok zanim policzysz hosting.
Sanity — świetny, ale nie dla każdego projektu
Sanity to solidne narzędzie dla projektów Next.js — edytor, język zapytań GROQ, płynna integracja z Server Components. Dla projektów z zespołem redakcyjnym zarządzającym treścią samodzielnie Sanity sprawdza się bez konkurencji.
Jest jednak scenariusz, w którym odpada już na początku.
Klient korporacyjny stawia warunek: dane muszą zostać na własnej infrastrukturze albo przynajmniej w UE, pod pełną kontrolą organizacji. Sektor medyczny, prawny, finansowy — gdzie kontrakt z klientem explicite określa lokalizację przechowywania danych. Sanity trzyma treści na serwerach w USA. Rozmowa skończona.
Stąd pytanie: czy istnieje coś, co daje headless CMS z TypeScriptem, równie płynnie zintegrowany z Next.js — ale z danymi na własnym serwerze?
Payload CMS to odpowiedź.
Payload CMS — jak to działa w Next.js
Payload v3 nie jest osobną aplikacją wymagającą osobnego wdrożenia. Funkcjonuje bezpośrednio w projekcie Next.js — jedno repozytorium, jeden deploy, jeden serwer:
/app
/(frontend) ← strona właściwa
/(payload) ← panel admina, generowany z konfiguracji
/collections ← definicje struktury danych w TypeScript
/payload.config.ts
Panel administracyjny generuje się automatycznie z konfiguracji TypeScript. Nowe pole w kolekcji pojawia się natychmiast w edytorze i jest otypowane po stronie frontendu. Dane pobierane są w Server Components bez żadnego wywołania HTTP:
const payload = await getPayload({ config })
const posts = await payload.find({ collection: 'posts' })W Sanity każde zapytanie o dane to wywołanie przez sieć. W Payload to lokalna funkcja — zero opóźnień, zero konfiguracji CORS, zero osobnego projektu do utrzymania. Uwierzytelnianie, role i uprawnienia, wersjonowanie treści oraz edytor tekstu sformatowanego (Lexical) dostępne są bez dodatkowych wtyczek.
Infrastruktura — lista decyzji
WordPress nie wymagał żadnych decyzji infrastrukturalnych. cPanel, jeden klik, WordPress gotowy. Payload wymaga czterech świadomych wyborów przed pierwszą linią kodu.
Baza danych — Payload obsługuje PostgreSQL i MongoDB. Dla nowych projektów sprawdza się PostgreSQL przez Neon (serverless Postgres, bezpłatny tier wystarczy na start, płatne plany od $5/mies.) albo Supabase (od $25/mies. ze stałym compute, bez cold startów).
Storage na pliki — Payload nie przechowuje plików lokalnie na produkcji. Cloudflare R2: 10 GB za darmo, zero opłat za egress — w odróżnieniu od AWS S3, który nalicza opłaty za każde pobranie pliku. Payload ma oficjalny adapter R2. Dla większości stron firmowych koszt sprowadza się do $0.
Poczta e-mail — Payload potrzebuje SMTP do resetowania haseł i powiadomień. Resend: 3 000 wiadomości miesięcznie za darmo, szablony jako komponenty React. Plan Pro od $20/mies.
Hosting — trzy podejścia: Vercel Pro ($20/mies.) przy oczekiwaniu zerowej konfiguracji. Railway ($20/mies. za workspace, nie per użytkownik) przy pracy zespołowej — taniej niż Vercel dla dwóch, trzech osób. Hetzner CX22 + Coolify (€4.49/mies.) przy pełnej autonomii i samodzielnym zarządzaniu.
Roczny koszt infrastruktury przy bezpłatnych tierach:
WordPress od drugiego roku: ~$845/rok. Różnica to ok. $600 rocznie. Pierwsza implementacja jest jednorazowo droższa w czasie pracy developera — próg opłacalności wypada zazwyczaj po 12–18 miesiącach.
Kiedy ta decyzja ma sens — trzy scenariusze
Scenariusz 1 — strona firmowa z narastającym długiem technicznym
Kilkadziesiąt wtyczek, brak stagingu, dwa języki obsługiwane przez Polylang, Core Web Vitals na czerwono, hosting współdzielony który "zawsze działał". Klient pyta o odświeżenie projektu i lepszy interfejs do zarządzania treścią.
W tym wariancie są trzy drogi: porządny remont WordPressa i pozostanie na platformie, migracja na Sanity albo wdrożenie Payload. Zastrzeżenie istotne: gdy po stronie klienta nie ma nikogo technicznego na co dzień — Payload nie pasuje. To Sanity albo dopracowany WordPress.
Scenariusz 2 — sklep WooCommerce z niestandardową logiką
Konfigurator produktów, ceny B2B per klient, integracja z ERP, subskrypcje. WooCommerce obsługuje to przez pięć, sześć płatnych rozszerzeń, każde z własnym cyklem aktualizacji i ryzykiem konfliktu przy każdym upgrade. Koszt rozszerzeń przekracza $600/rok, a modyfikacja procesu zakupowego bez rozwiązań obejściowych jest praktycznie niemożliwa.
To jest przypadek, gdzie Medusa.js + Next.js albo Payload jako backend dedykowanej aplikacji ma realne uzasadnienie — nie tylko techniczne, ale ekonomiczne.
Scenariusz 3 — wymogi dotyczące lokalizacji danych
Sektor medyczny lub prawny, kontrakt z klauzulą o miejscu przechowywania danych. Sanity odpada — serwery w USA. WordPress odpada — bezpieczeństwo przy kilkudziesięciu wtyczkach to gra w ruletkę. Payload na VPS w Niemczech (Hetzner) z bazą Postgres i regularnym kopią zapasową to jedyna opcja spełniająca wymogi przy rozsądnym koszcie.
Kiedy Payload CMS to zły wybór
Mały blog firmowy lub landing page z kilkunastoma podstronami. Konfiguracja bazy danych, storage i hostingu dla prostej wizytówki to przerost formy nad treścią. WordPress albo Next.js z Sanity na bezpłatnym tierze rozwiążą to szybciej i taniej.
Klient zarządza stroną samodzielnie, bez zaplecza technicznego. WordPress ma dwie dekady tutoriali, rozległą społeczność i dziesiątki polskich agencji, do których klient może się w każdej chwili zwrócić. Payload wymaga technicznego wsparcia przy zmianach struktury — bez tego klient traci autonomię, którą WordPress mu dawał.
Budżet poniżej 8–10 tys. zł. Zaprojektowanie kolekcji w TypeScript, konfiguracja infrastruktury, budowa frontendu od podstaw — to kilkanaście roboczogodzin zanim powstanie pierwsza strona. Przy niskim budżecie czas konfiguracji zjada marżę i sens projektu.
Brak planów na długoterminowe utrzymanie techniczne. Ktoś musi aktualizować zależności, reagować gdy baza danych ma problem, przeglądać logi gdy coś przestaje działać. Bez takiego zasobu — własnego lub w ramach planowanego wsparcia agencji — WordPress z zarządzanym hostingiem jest bezpieczniejszą decyzją dla obu stron.
Napięty harmonogram bez buforu. Przy WordPress działający prototyp jest gotowy w kilka godzin. Przy Payload pierwsze sensowne środowisko deweloperskie to dzień lub dwa. Przy harmonogramie bez rezerwy ma to znaczenie.
Payload nie jest domyślną odpowiedzią na pytanie "co zamiast WordPressa". To rozwiązanie dla konkretnej grupy projektów.
Zasady wyceny projektu opisałem w “Ile kosztuje nowoczesna strona internetowa w 2026 roku?”
Migracja: czego się spodziewać
Temat na osobny artykuł — ale kilka kwestii wartych przemyślenia przed podjęciem decyzji.
Audyt treści — co migrować (wpisy, strony, własne typy treści, pliki multimedialne, formularze), co zostawić. W typowym WordPressie 30–40% wpisów to treści bez ruchu od lat. Przenoszenie wszystkiego to strata czasu bez żadnych korzyści.
Projektowanie kolekcji w TypeScript — mapowanie struktury WordPressa na kolekcje Payload. Własne typy treści gromadzą często pola z kilku różnych wtyczek — migracja jest przy okazji okazją do zaprojektowania struktury od podstaw, bez nagromadzonego bałaganu.
Skrypt migracyjny — eksport z WordPressa przez XML lub MySQL, import przez Payload Local API. Najtrudniejszy element to pliki. Zasoby z katalogu /wp-content/uploads/ trzeba przenieść do R2 lub S3 i zaktualizować wszystkie odwołania w treści — to zazwyczaj 30–50% całego czasu migracji.
Przekierowania 301 — WordPress generuje adresy URL w formacie /2024/03/tytul-posta/, Next.js będzie miał inną strukturę. Każdy nieprzekierowany stary adres to utracona pozycja w wynikach wyszukiwania. Tablica przekierowań w next.config.js to obowiązkowy element projektu, nie opcja.
Zmiana DNS — TTL na 300 sekund dzień wcześniej, przełączenie, stary WordPress offline dopiero po tygodniu. Na wszelki wypadek.
Podsumowanie
Payload CMS to nie jest lepszy WordPress. To inna filozofia — więcej odpowiedzialności po stronie developera, ale pełna kontrola nad danymi, infrastrukturą i kosztami. Od drugiego roku różnica w kosztach względem WordPressa to ok. $600 rocznie. Pierwsza implementacja jest jednorazowo droższa w czasie.
Dla sporej części projektów Payload po prostu nie pasuje — i warto to powiedzieć wprost, zanim zacznie się projektować kolekcje.