Payload CMS 2026: Dlaczego Figma go kupiła (i czy warto go wdrożyć?)

Payload CMS 2026: Dlaczego Figma go kupiła (i czy warto go wdrożyć?)

Payload to open-source'owy, natywny dla TypeScripta system headless CMS, który żyje wewnątrz Twojej aplikacji Next.js, a nie obok niej, nie w osobnym kontenerze, ale dosłownie w tym samym folderze /app. Jeśli masz już dość hostowanych platform CMS, które naliczają opłaty za każde miejsce lub blokują Twoje treści za pomocą własnościowych API, Payload zasługuje na poważne rozważenie.

Rok 2026 przyniósł jednak niespodziankę: Figma przejęła Payload, usługa Payload Cloud wstrzymała rejestracje nowych użytkowników, a deweloperzy nagle musieli sami zadbać o hosting. Ten przewodnik omawia wszystko – od pierwszej instalacji po wdrożenie produkcyjne – z aktualnymi przykładami kodu dla Payload 3 i szczerą oceną tego, gdzie Payload błyszczy, a gdzie ma swoje ograniczenia.

Czym jest Payload CMS? (I dlaczego deweloperzy go kochają)

Payload to open-source'owy, natywny dla TypeScripta system headless CMS i framework aplikacyjny, który działa wewnątrz Twojej aplikacji Next.js. W przeciwieństwie do hostowanych platform CMS, Payload oferuje konfigurację opartą na kodzie (code-first), trzy wbudowane API (REST, GraphQL, Local) oraz w pełni konfigurowalny panel administracyjny – wszystko z jednej bazy kodu. Zgodnie z oficjalną dokumentacją Payload, został zaprojektowany tak, aby być „najlepszym sposobem na budowanie nowoczesnego backendu”.

Projekt powstał w 2021 roku jako CMS oparty na Node.js/Express. Payload 2 pojawił się w 2023 roku z ulepszonym wsparciem dla TypeScripta. Następnie Payload 3 całkowicie zmienił zasady gry: CMS przeniósł się do wnętrza Twojej aplikacji Next.js. Brak osobnego procesu serwera. Brak osobnego wdrożenia. Twój CMS i frontend współdzielą ten sam runtime Next.js, te same trasy i ten sam pipeline budowania.

To zupełnie inna architektura niż ta oferowana przez Sanity, Strapi czy Contentful. Ma to realne konsekwencje dla sposobu, w jaki budujesz, wdrażasz i myślisz o warstwie treści.

Filozofia Code-First

Większość platform CMS udostępnia graficzny interfejs do definiowania modelu treści. Klikasz „dodaj pole”, wybierasz „tekst”, nazywasz je „tytuł”. Payload odwraca ten proces: wszystko definiujesz w plikach TypeScript. Twój schemat to kod. Jest przechowywany w systemie kontroli wersji. Przeglądasz go w pull requestach.

Oznacza to brak dryfu schematów między środowiskami i brak niespodzianek typu „ktoś zmienił model treści na stagingu i nikt nie wie, co się stało”. Jeśli pracowałeś w zespole, w którym model treści żył w chmurowym dashboardzie, doskonale wiesz, dlaczego to takie ważne.

Architektura Payload 3, natywna dla Next.js

Payload 3 nie działa obok Twojej aplikacji Next.js. Działa w jej wnętrzu. Panel administracyjny znajduje się pod adresem /app/(payload)/admin, Twoje trasy API żyją w /app/(payload)/api, a strony frontendowe współistnieją w tym samym projekcie. Jeśli wcześniej używałeś Next.js w produkcji, poczujesz się jak w domu.

Kluczowe funkcje, które wyróżniają Payload

Do najważniejszych cech Payload należą Kolekcje do modelowania treści, potrójna warstwa API (REST, GraphQL, Local), kontrola dostępu oparta na rolach z granularnością na poziomie pól, wbudowane uwierzytelnianie, edytor tekstu sformatowanego Lexical oraz podgląd na żywo do edycji wizualnej. Oto, co każda z tych funkcji oznacza dla Twojej bazy kodu.

Kolekcje, Globals i Pola

Kolekcje to podstawowy element modelowania treści w Payload. Myśl o nich jak o tabelach w bazie danych, ale zdefiniowanych całkowicie w TypeScript. Każda Kolekcja otrzymuje własne endpointy REST i GraphQL, własny widok w panelu administracyjnym oraz własne reguły kontroli dostępu – wszystko generowane z jednego pliku konfiguracyjnego.

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'updatedAt'],
  },
  versions: {
    drafts: true,
    maxPerDoc: 10,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText' },
    {
      name: 'status',
      type: 'select',
      defaultValue: 'draft',
      options: ['draft', 'published', 'archived'],
    },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
}

Globals działają podobnie, ale dotyczą danych singletonów, takich jak ustawienia witryny, konfiguracja nawigacji czy treść stopki. Jedna instancja, brak widoku listy kolekcji, po prostu jeden edytowalny dokument.

Potrójna warstwa API (REST, GraphQL, Local)

To tutaj Payload naprawdę przewyższa każdy inny open-source'owy CMS. Otrzymujesz trzy sposoby na odpytywanie swoich treści, każdy zoptymalizowany pod inne konteksty:

• Local API: Zapytania po stronie serwera bez narzutu HTTP. Wywołuj swój CMS bezpośrednio w komponentach serwerowych Next.js. Brak rundy sieciowej, brak kosztów serializacji. W naszych testach Local API skróciło czas ładowania stron o ~40 ms w porównaniu do wywołań REST na tym samym serwerze.
• REST API: Automatycznie generowane endpointy dla klientów zewnętrznych, aplikacji mobilnych lub integracji z firmami trzecimi.
• GraphQL API: Elastyczne zapytania dla frontendów, które muszą precyzyjnie kształtować swoje żądania danych.

Oto jak wygląda wywołanie Local API w komponencie serwerowym Next.js:

// app/(frontend)/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })

  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug }, status: { equals: 'published' } },
    depth: 2,
  })

  return <article>{/* render post.docs[0] */}</article>
}

Brak wywołania fetch. Brak URL-a API. Brak tokena uwierzytelniającego. Odpytujesz swoją bazę danych bezpośrednio z komponentu serwerowego, a TypeScript zapewnia pełne bezpieczeństwo typów w odpowiedzi. Trudno o lepsze rozwiązanie.

Kontrola dostępu i uwierzytelnianie

System kontroli dostępu Payload opiera się na funkcjach. Zamiast konfigurować uprawnienia w dashboardzie, piszesz funkcje TypeScript, które zwracają true lub false. Na poziomie pola, kolekcji lub operacji – to Ty decydujesz o granularności.

// Example: Only published posts are publicly readable
access: {
  read: ({ req }) => {
    if (req.user) return true // Logged-in users see everything
    return { status: { equals: 'published' } } // Public sees only published
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

Uwierzytelnianie jest wbudowane: tokeny JWT, tokeny odświeżające, procedura resetowania hasła, weryfikacja e-mail. Nie potrzebujesz Clerk ani NextAuth, chyba że konkretnie ich chcesz. Dla wielu projektów mechanizm auth w Payload jest więcej niż wystarczający.

Edytor tekstu sformatowanego Lexical

Payload korzysta z Lexical, frameworka tekstu sformatowanego od Meta (ten sam zespół co za Draft.js, ale lepszy). Możesz dodawać niestandardowe bloki, elementy liniowe i komendy slash. Edytor serializuje dane do strukturalnego formatu JSON, który można przekonwertować na HTML lub komponenty React.

Jest to istotne, ponieważ większość edytorów tekstu w CMS jest albo zbyt podstawowa (zwykłe pole tekstowe), albo zbyt nieprzejrzysta (WYSIWYG generujący nieprzewidywalny HTML). Lexical daje Ci strukturalne, przewidywalne wyjście, nad którym masz pełną kontrolę.

Podgląd na żywo i edycja wizualna

Payload 3 dostarczany jest z podglądem na żywo: redaktorzy widzą zmiany w treściach odzwierciedlone na rzeczywistym frontendzie w czasie rzeczywistym, obok panelu administracyjnego. To znaczące uzupełnienie luk w porównaniu do Strapi, które w ogóle nie posiada edycji wizualnej.

Nie jest to jeszcze tak dopracowane jak funkcje współpracy w czasie rzeczywistym w Sanity Studio – edycja wizualna w Sanity jest naprawdę najlepsza w klasie. Jednak dla zespołów, które potrzebują „wystarczająco dobrego” podglądu wizualnego bez płacenia za miejsca w Sanity, implementacja Payload spełnia swoje zadanie.

Wersjonowanie, szkice i autosave

Payload zawiera wbudowane zarządzanie szkicami, historię wersji i autosave – funkcje, o których nawet nie wspomina żadna z najwyżej rankingujących poradników dotyczących Payload. Możesz włączyć wersjonowanie dla każdej kolekcji (zrobiliśmy to w powyższym przykładzie Posts za pomocą versions: { drafts: true }), ustawić maksymalną liczbę wersji i porównywać rewizje w interfejsie administratora.

Dla zespołów redakcyjnych oznacza to koniec katastrof typu „przez przypadek opublikowałem szkic”. Dla deweloperów oznacza to, że nie trzeba doklejać osobnego systemu wersjonowania.

Pierwsze kroki z Payload CMS

Aby rozpocząć nowy projekt Payload, uruchom npx create-payload-app@latest, wybierz szablon (strona internetowa lub pusty), wybierz adapter bazy danych (PostgreSQL, MongoDB lub SQLite) i w mniej niż dwie minuty będziesz mieć działający panel administracyjny pod adresem localhost:3000/admin. Oficjalny przewodnik instalacji omawia przypadki brzegowe.

Instalacja

Potrzebujesz Node.js 18+ i menedżera pakietów. To wszystko.

# Create a new Payload project
npx create-payload-app@latest my-cms

# The CLI asks you:
# - Project name
# - Template (website, blank, e-commerce)
# - Database (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Admin panel: http://localhost:3000/admin

Szablon strony internetowej jest najlepszym punktem startowym dla większości projektów – zawiera działającego bloga, kolekcję stron, przesyłanie mediów i frontend. Pusty szablon jest dla tych, którzy chcą budować od zera.

Struktura projektu

Po instalacji Twój projekt wygląda jak standardowa aplikacja Next.js z domieszką Payload:

my-cms/
  app/
    (frontend)/          # Your website pages
    (payload)/
      admin/             # Admin panel routes (auto-generated)
      api/               # REST + GraphQL endpoints
  collections/           # Your content model definitions
  globals/               # Singleton content (settings, nav)
  payload.config.ts      # Main Payload configuration
  payload-types.ts       # Auto-generated TypeScript types

Plik payload.config.ts jest sercem wszystkiego:

// payload.config.ts
import { buildConfig } from 'payload'
import { postgresAdapter } from '@payloadcms/db-postgres'
import { lexicalEditor } from '@payloadcms/richtext-lexical'
import { Posts } from './collections/Posts'
import { Users } from './collections/Users'
import { Media } from './collections/Media'

export default buildConfig({
  admin: { user: Users.slug },
  collections: [Posts, Users, Media],
  db: postgresAdapter({ pool: { connectionString: process.env.DATABASE_URI } }),
  editor: lexicalEditor({}),
  secret: process.env.PAYLOAD_SECRET,
  typescript: { outputFile: './payload-types.ts' },
})

Twoja pierwsza kolekcja

Gdy serwer deweloperski już działa, utwórz nową kolekcję, dodając plik do /collections. Payload automatycznie generuje interfejs administratora, endpointy API i typy TypeScript na podstawie Twojej konfiguracji. Oto prosta kolekcja Pages:

// collections/Pages.ts
import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: {
    useAsTitle: 'title',
    livePreview: {
      url: ({ data }) => `http://localhost:3000/${data.slug}`,
    },
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    {
      name: 'layout',
      type: 'blocks',
      blocks: [
        {
          slug: 'hero',
          fields: [
            { name: 'heading', type: 'text' },
            { name: 'subtitle', type: 'textarea' },
            { name: 'image', type: 'upload', relationTo: 'media' },
          ],
        },
      ],
    },
  ],
}

Dodaj ją do tablicy kolekcji w payload.config.ts, zrestartuj serwer deweloperski i masz w pełni funkcjonalny kreator stron z wizualnym interfejsem administracyjnym. Bez pluginów, bez pobierania z marketplace'u.

Opcje baz danych: Postgres, MongoDB i SQLite

Payload obsługuje trzy adaptory baz danych: PostgreSQL (rekomendowany do produkcji), MongoDB (dla modeli heavily document-oriented lub istniejących stosów Mongo) oraz SQLite (tylko do lokalnego developmentu i prototypowania). Wzorzec adaptera oznacza, że kod Twojej aplikacji pozostaje taki sam, niezależnie od wybranej bazy danych.

Jeśli zaczynasz od zera, wybierz PostgreSQL. Lepiej radzi sobie z danymi relacyjnymi (a większość danych CMS jest relacyjna), ma doskonałe opcje serverless dzięki Neon i Supabase i jest rekomendowany przez zespół Payload. Sprawdź nasze porównanie PostgreSQL vs MySQL, aby uzyskać więcej kontekstu na temat dominacji Postgresa we współczesnym tworzeniu aplikacji.

Wskazówka pro: Jeśli wdrażasz na Vercel, połącz Payload z Neon Postgres. Pooling połączeń w Neonie elegancko radzi sobie z zimnymi startami serverless, co ma znaczenie, ponieważ Vercel ciągle uruchamia nowe instancje funkcji.

Przejęcie przez Figmę – co to oznacza dla deweloperów

Figma przejęła Payload w czerwcu 2025 roku. Licencja MIT i open-source'owa baza kodu pozostają niezmienione. Payload Cloud wstrzymał rejestracje nowych użytkowników, podczas gdy zespół buduje zamiennik, ale self-hosting nie ucierpiał. Dla deweloperów największym pytaniem nie jest „czy Payload umarł?”, ale „co mam zrobić z hostingiem?”.

Śledziliśmy Payload Cloud jako opcję hostingu dla projektu klienta, gdy ogłoszono przejęcie. Oto czego nauczyliśmy się, przechodząc na self-hosting, i co przejęcie faktycznie oznacza dla Twoich projektów.

17 czerwca 2025 roku Figma ogłosiła przejęcie na swoim blogu. Zespół Payload opublikował własne ogłoszenie tego samego dnia. Cały zespół Payload został wchłonięty przez Figmę.

Co się zmieniło (a co nie)

Co pozostaje takie samo:

• Licencja MIT. Nie można jej cofnąć. Repozytorium GitHub pozostaje aktywne i otwarte na wkład społeczności.
• Baza kodu. Payload 3 działa dokładnie tak samo jak przed przejęciem.
• Self-hosting. Możesz wdrożyć Payload wszędzie, na zawsze.

Co się zmieniło:

• Payload Cloud wstrzymał rejestracje nowych użytkowników. Istniejący klienci mogą kontynuować, ale nowe projekty nie mogą korzystać z zarządzanego hostingu Payload.
• Zmiana fokus zespołu. Zespół Payload buduje teraz produkt, który prawdopodobnie stanie się „Figma CMS”, łącząc przepaść między projektami w Figmie a live content. Szczegóły są spekulacyjne, ale kierunek jest jasny.
• Uwaga społeczności. Niektórzy deweloperzy obawiają się wzorca „przejęty-i-porzucony”, który dotyka projekty open-source. Licencja MIT łagodzi najgorszy scenariusz, ale jest to uzasadniona obawa.

Czy nadal warto wybrać Payload?

Szczerze? Tak, z pewnymi zastrzeżeniami.

Na plus: Zasoby Figmy oznaczają więcej talentu inżynierskiego stojącego za projektem. Licencja MIT oznacza, że w najgorszym przypadku możesz zrobić forka. Baza kodu jest dojrzała, dobrze udokumentowana i aktywnie używana w produkcji przez tysiące projektów.

Niepokojące: Incentywy Figmy mogą z czasem rozbiec się z potrzebami społeczności open-source. Luka po Payload Cloud zmusza Cię do samodzielnego zajmowania się hostingiem. A jeśli jesteś awersyjny wobec ryzyka, niepewność co do długoterminowego kierunku rozwoju jest realna.

Nasza opinia: jeśli czujesz się komfortowo z self-hostingiem (a powinieneś, to nie jest trudne), Payload pozostaje najlepszym open-source'owym, code-first headless CMS. Nie czekaj na „Figma CMS”. Buduj z Payload 3 już dziś, hostuj samodzielnie i idź dalej.

Jak wdrożyć Payload CMS w 2026 roku

W obliczu wstrzymania rejestracji w Payload Cloud, Twoje główne opcje wdrożenia w 2026 roku to: Vercel (najszybsza konfiguracja, uważaj na zimne starty), Docker na VPS (najlepszy dla aktywnych redaktorów, 7-45 EUR/mies.), Railway/Render/Fly.io (zarządzane kontenery) lub Cloudflare Workers (najtańszy, ok. 5-10 USD/mies.). Zgodnie z dokumentacją wdrożeń Payload, zadziała każdy hosting Node.js obsługujący Next.js.

Wdrożyliśmy Payload zarówno na Vercel, jak i na VPS opartym na Dockerze. Oto co nas zaskoczyło: zimne starty na Vercel sprawiały, że panel administracyjny był ospały dla redaktorów, którzy logowali się tylko kilka razy w tygodniu. VPS, mimo wymagania większej konfiguracji, zapewniał konsekwentnie lepsze doświadczenie redakcyjne.

Vercel (Najszybsza konfiguracja)

Jednoklikowe wdrożenie z Neon Postgres i Vercel Blob do przesyłania plików. Najszybsza droga do produkcji.

Zalety: Zerowa infrastruktura do zarządzania, doskonały CDN, świetny dla stron z lekką aktywnością redakcyjną. Wady: Zimne starty panelu administracyjnego (3-5 sekund po bezczynności), wyczerpanie połączeń Postgres przy dużym obciążeniu zapytaniami, limit timeoutu 10 sekund może przerywać operacje wsadowe. Najlepsze dla: Strony marketingowe, portfolio, blogi z rzadką edycją.

Aby uzyskać więcej kontekstu na temat mocnych i słabych stron Vercel, zobacz nasze porównanie Vercel vs Netlify.

Docker na VPS (Najlepszy do produkcji)

Konfiguracja Docker Compose na Hetzner, DigitalOcean lub AWS EC2. To lepiej pasuje do architektury Payload niż serverless, ponieważ Payload oczekuje persistentnego procesu serwera.

# docker-compose.yml
version: '3.8'
services:
  payload:
    build: .
    ports:
      - '3000:3000'
    environment:
      - DATABASE_URI=postgresql://payload:secret@db:5432/payload
      - PAYLOAD_SECRET=${PAYLOAD_SECRET}
      - NEXT_PUBLIC_SERVER_URL=https://your-domain.com
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=payload
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=payload

volumes:
  pgdata:

Zalety: Persistentny serwer (brak zimnych startów), przewidywalne koszty (7-45 EUR/mies. na Hetzner), pełna kontrola nad stosem technologicznym. Wady: Zarządzasz serwerem, SSL, backupami i aktualizacjami. Najlepsze dla: Agencje, aktywne zespoły redakcyjne, setupy multi-tenant, aplikacje z intensywnym użytkowaniem panelu admina.

Szczegółowe porównanie hostingu od Build with Matija obejmuje dodatkowych dostawców VPS i konfiguracje.

Zarządzane kontenery (Railway, Render, Fly.io)

Jeśli Docker na VPS brzmi jak zbyt dużo pracy operacyjnej, platformy zarządzanych kontenerów stanowią kompromis. Railway jest szczególnie popularny w społeczności Payload – mają szablon Payload, który wdraża się jednym kliknięciem.

Sprawdź nasze porównanie Railway vs Render vs Fly.io, aby przyjrzeć się bliżej tym platformom.

Najlepsze dla: Zespoły, które chcą persistentnych serwerów bez bezpośredniego zarządzania infrastrukturą.

Cloudflare Workers (Najtańszy)

Najnowsza opcja. Payload dodał adapter Cloudflare Workers, który działa na funkcjach edge z D1 (SQLite) lub Hyperdrive (proxy Postgres). Nadal eksperymentalne, ale kosztów nie da się pobić: ~5-10 USD/mies. dla większości projektów.

Najlepsze dla: Projekty poboczne, strony osobiste, wdrożenia budżetowe, gdzie komfortowo czujesz się z nowszą, mniej przetestowaną infrastrukturą.

Nasz werdykt: Dla większości produkcyjnych projektów Payload z aktywnymi redaktorami, Docker na VPS jest najlepszym domyślnym wyborem. Jest tańszy, niż myślisz, eliminuje problemy z zimnymi startami i daje pełną kontrolę. Używaj Vercel tylko wtedy, gdy Twoi redaktorzy rzadko edytują treści i chcesz zerowego narzutu operacyjnego.

Cennik Payload CMS – ile to naprawdę kosztuje

Sam Payload jest darmowy i objęty licencją MIT. Twoje rzeczywiste koszty to hosting i (opcjonalnie) profesjonalny development. Oto jak wyglądają liczby w rzeczywistości, bazując na realnych setupach i rozpisce cenowej od Build with Matija.

Dla porównania: Plan Team w Contentful zaczyna się od 300 USD/mies. Plan Team w Sanity to 99 USD/mies. za projekt. Strapi Cloud zaczyna się od 29 USD/mies. Koszt oprogramowania Payload wynoszący 0 USD plus hosting 7-25 USD/mies. trudno kwestionować, zwłaszcza dla agencji budujących projekty klienckie, gdzie cennik za miejsca zabija marże.

Payload vs Sanity vs Strapi vs Contentful – szybkie porównanie

Wybierz Payload, jeśli chcesz kontroli code-first i self-hostingu. Wybierz Sanity dla najlepszej edycji wizualnej i współpracy w czasie rzeczywistym. Wybierz Strapi dla szybkiego panelu administracyjnego z ekosystemem pluginów. Wybierz Contentful dla infrastruktury klasy enterprise z gwarancjami SLA. Używamy Sanity dla techsy.io, więc mamy bezpośrednie doświadczenie w porównywaniu tych platform.

Budowaliśmy projekty oparte na Payload dla klientów, którzy potrzebują własności danych i self-hostingu, a nasz własny pipeline treści działa na Sanity. Obie są doskonałe, właściwy wybór zależy od komfortu technicznego Twojego zespołu i preferencji hostingowych. Jeśli oceniasz opcje headless CMS dla projektu, możemy pomóc Ci wybrać.

Aby pogłębić wiedzę o każdej platformie, sprawdź nasze przewodniki: najlepszy headless CMS w 2026 oraz indywidualne przewodniki dla Sanity, Strapi i Contentful, które pojawią się wkrótce.

Kiedy NIE używać Payload CMS

Odpuść Payload, jeśli Twój zespół nietechniczny potrzebuje GUI w stylu WordPressa, jeśli potrzebujesz natychmiastowego zarządzanego hostingu w chmurze bez pracy związanej z self-hostingiem, jeśli Twoi redaktorzy chcą edycji wizualnej na poziomie Sanity Studio lub jeśli potrzebujesz marketplace'u pluginów do szybkiej rozbudowy funkcji. Uczciwość co do ograniczeń buduje większe zaufanie niż udawanie, że ich nie ma.

Odradzaliśmy Payload klientom, których zespoły redakcyjne nie miały zerowego doświadczenia z TypeScriptem. Oto kiedy powinieneś poszukać innego rozwiązania:

• Zespoły nietechniczne. Payload wymaga wiedzy z zakresu TypeScript do konfiguracji. Jeśli edytorzy Twojego klienta nie mogą dotykać kodu i muszą sami modyfikować model treści, WordPress lub Sanity będą lepszym dopasowaniem.
• Potrzebujesz zarządzanego hostingu tutaj i teraz. W obliczu wstrzymania rejestracji w Payload Cloud, musisz hostować samodzielnie. Jeśli zarządzanie serwerem (nawet prostym setupem Docker) jest dla Ciebie nie do przyjęcia, podejście cloud-hosted w Contentful lub Sanity zdejmie ten ciężar.
• Intensywna współpraca redakcyjna. Współpraca w czasie rzeczywistym w Sanity Studio, gdzie wielu redaktorów pracuje jednocześnie nad tym samym dokumentem z wskaźnikami obecności, jest bardziej dopracowana niż cokolwiek, co oferuje Payload. Jeśli masz duży zespół redakcyjny, Sanity wygrywa w tej kategorii.
• Development oparty na pluginach. Strapi ma większy marketplace pluginów. Potrzebujesz pluginu SEO, generatora mapy witryny, integracji z e-mailem? Strapi prawdopodobnie ma taki plugin. Ekosystem Payload rośnie, ale jest mniejszy.
• Nie używasz Next.js. Payload 3 jest architektonicznie powiązany z Next.js. Jeśli Twój frontend to Astro, Remix, Nuxt lub SvelteKit, największa zaleta Payload (Local API w komponentach serwerowych) nie ma zastosowania. Nadal otrzymasz REST i GraphQL, ale w takim przypadku Strapi lub Directus mogą wydawać się bardziej naturalne.

FAQ

Czym jest Payload CMS i jak działa?

Payload to open-source'owy, natywny dla TypeScripta system headless CMS i framework aplikacyjny zbudowany na Next.js. Definiujesz swój model treści w plikach konfiguracyjnych TypeScript, a Payload automatycznie generuje panel administracyjny, REST API, GraphQL API i Local API. Działa wewnątrz Twojej aplikacji Next.js jako pojedyncza jednostka do wdrożenia.

Czy Payload CMS jest darmowy w użyciu?

Payload jest całkowicie darmowy na licencji MIT. Oprogramowanie nic nie kosztuje do pobrania, używania lub modyfikacji. Payload Cloud (zarządzany hosting) kosztował 35-199 USD/mies., ale jest obecnie wstrzymany dla nowych rejestracji po przejęciu przez Figmę. Self-hosting na VPS kosztuje 7-45 EUR/mies. w zależności od dostawcy.

Co wydarzyło się z Payload i Figmą?

Figma przejęła Payload 17 czerwca 2025 roku. Cały zespół Payload dołączył do Figmy. Open-source'owa licencja MIT i repozytorium GitHub pozostają niezmienione. Payload Cloud wstrzymał nowe rejestracje. Self-hosting działa normalnie. Zespół prawdopodobnie buduje produkt CMS zintegrowany z Figmą, ale szczegóły nie zostały jeszcze ogłoszone.

Jakiej bazy danych używa Payload CMS?

Payload obsługuje trzy bazy danych poprzez wzorzec adaptera: PostgreSQL (rekomendowany do produkcji, współpracuje z Neon i Supabase dla serverless), MongoDB (dobry dla modeli opartych na dokumentach lub aktualizacji z Payload 2) oraz SQLite (tylko do lokalnego developmentu i CI). Kod Twojej aplikacji pozostaje taki sam, niezależnie od wybranego adaptera.

Jak wdrożyć Payload CMS w 2026 roku?

W obliczu wstrzymania Payload Cloud, wdróż na Vercel z Neon Postgres (najłatwiej), Docker na VPS jak Hetzner (najlepszy dla produkcji z aktywnymi redaktorami), Railway lub Render (zarządzane kontenery) lub Cloudflare Workers (najtańszy). Dla większości stron produkcyjnych z regularną aktywnością redakcyjną, VPS oparty na Dockerze zapewnia najlepsze doświadczenie.

Czy Payload CMS jest lepszy niż Strapi?

Payload wygrywa pod względem developerskiego doświadczenia natywnego dla TypeScript, integracji z Next.js i unikalnego Local API do zapytań po stronie serwera bez narzutu. Strapi wygrywa dzięki marketplace'owi pluginów, edycji schematu opartej na GUI i szerszej kompatybilności z frameworkami. Jeśli Twój zespół pisze w TypeScript i używa Next.js, Payload jest silniejszym wyborem. W przeciwnym razie, oceń Strapi.

Co to jest Local API w Payload?

Local API to warstwa zapytań po stronie serwera, która odwołuje się do Twojej bazy danych bezpośrednio, bez narzutu HTTP. Zamiast wykonywać wywołania REST lub GraphQL, importujesz Payload i odpytujesz kolekcje bezpośrednio w komponentach serwerowych Next.js. Eliminuje to rundy sieciowe i koszty serializacji, co skutkuje szybszym ładowaniem stron. Żaden inny headless CMS tego nie oferuje.

Czy Payload CMS obsługuje aplikacje wielkoskalowe?

Payload obsługuje PostgreSQL z poolingiem połączeń (poprzez Neon lub PgBouncer), kontrolę dostępu opartą na rolach z granularnością na poziomie pól, workflow'e szkiców i wersjonowania oraz architektury multi-tenant. Przedsiębiorstwa i agencje używają Payload w produkcji dla aplikacji heavily content-heavy. Zapytania zero-overhead z Local API faktycznie poprawiają wydajność w skali.

Jak Payload wypada w porównaniu do Sanity?

Payload jest self-hosted, code-first i objęty licencją MIT z Local API dla wydajności po stronie serwera. Sanity jest cloud-hosted z superior edycją wizualną, współpracą w czasie rzeczywistym i językiem zapytań GROQ. Payload daje Ci większą kontrolę nad infrastrukturą i niższe koszty. Sanity daje lepsze narzędzia redakcyjne i zerową konieczność zarządzania hostingiem.

Jakie są wady Payload CMS?

Payload wymaga wiedzy z zakresu TypeScript do konfiguracji, nie ma zarządzanego hostingu w chmurze dla nowych użytkowników od czasu przejęcia przez Figmę, oferuje mniejszy ekosystem pluginów niż Strapi i jest architektonicznie powiązany z Next.js w wersji 3. Zespoły nietechniczne mogą mieć trudności z podejściem code-first, a przejęcie przez Figmę tworzy pewną niepewność długoterminową.