Payload CMS 2026: Figma Neden Satın Aldı — Siz de Geçmeli misiniz?

Payload, Next.js uygulamanızın içinde çalışan, açık kaynaklı ve TypeScript tabanlı bir headless CMS'dir -- yanında değil, ayrı bir container'da değil, tam anlamıyla aynı /app klasöründe. Kullanıcı başına ücret alan ya da içeriğinizi özel API'lar arkasında kilitleyen hosted CMS platformlarından bıktıysanız, Payload ciddiye alınmayı hak ediyor.

Ama 2026 bir sürpriz getirdi: Figma Payload'ı satın aldı, Payload Cloud yeni kayıtları durdurdu ve geliştiriciler artık barındırmayı kendi başlarına çözmek zorunda. Bu rehber, ilk kurulumdan production dağıtımına kadar her şeyi kapsıyor: güncel Payload 3 kod örnekleri ve Payload'ın nerede parlayıp nerede yetersiz kaldığına dair dürüst değerlendirmelerle.

Payload CMS Nedir? (Ve Neden Geliştiriciler Tarafından Sevilir)

Payload, Next.js uygulamanızın içinde çalışan açık kaynaklı, TypeScript tabanlı bir headless CMS ve uygulama framework'üdür. Hosted CMS platformlarının aksine Payload size kod öncelikli bir yapılandırma, üç yerleşik API (REST, GraphQL, Local) ve tamamen özelleştirilebilir bir yönetici paneli sunar -- hepsini tek bir kod tabanından. Resmi Payload belgelerine göre "modern bir backend oluşturmanın en iyi yolu" olarak tasarlanmıştır.

Proje 2021'de Node.js/Express CMS olarak başladı. Payload 2, 2023'te iyileştirilmiş TypeScript desteğiyle geldi. Ardından Payload 3 oyunu tamamen değiştirdi: CMS artık Next.js uygulamanızın içine taşındı. Ayrı bir sunucu süreci yok. Ayrı bir dağıtım yok. CMS'iniz ve ön yüzünüz aynı Next.js runtime'ını, aynı route'ları, aynı build pipeline'ını paylaşıyor.

Bu, Sanity, Strapi veya Contentful'un sunduğundan gerçekten farklı bir mimari. Ve bunun nasıl geliştirdiğiniz, dağıttığınız ve içerik katmanınızı nasıl düşündüğünüz üzerinde gerçek sonuçları var.

Kod Öncelikli Felsefe

Çoğu CMS platformu içerik modelinizi tanımlamak için size bir arayüz sunar. "Alan ekle"ye tıklarsınız, "metin" seçersiniz, "başlık" adını verirsiniz. Payload bunu tersine çevirir: her şeyi TypeScript dosyalarında tanımlarsınız. Şemanız koddur. Versiyon kontrolünde yaşar. Pull request'lerde incelenir.

Bu, ortamlar arasında şema kaymasının olmadığı anlamına gelir; "birisi hazırlama ortamında içerik modelini değiştirdi ve kimse ne olduğunu bilmiyor" sürprizleri de yok. İçerik modelinin bir bulut panosunda yaşadığı bir ekipte çalıştıysanız, bunun neden önemli olduğunu tam olarak anlarsınız.

Payload 3 Mimarisi -- Next.js Native

Payload 3, Next.js uygulamanızın yanında değil içinde çalışır. Yönetici paneli /app/(payload)/admin konumundadır, API route'larınız /app/(payload)/api içinde yer alır ve ön yüz sayfalarınız aynı projede bir arada bulunur. Daha önce Next.js'i production'da kullandıysanız, kendinizi hemen evinizde hissedeceksiniz.

Payload'ı Farklı Kılan Temel Özellikler

Payload'ın öne çıkan özellikleri arasında içerik modelleme için Collection'lar, üçlü API katmanı (REST, GraphQL, Local), alan düzeyinde ayrıntı sunan rol tabanlı erişim kontrolü, yerleşik kimlik doğrulama, Lexical zengin metin editörü ve görsel düzenleme için canlı önizleme yer alıyor. İşte bunların her birinin kod tabanınız için gerçekte ne anlama geldiği.

Collection'lar, Global'lar ve Alanlar

Collection'lar, Payload'ın temel içerik modelleme yapı taşıdır. Tamamen TypeScript'te tanımlanan veritabanı tabloları gibi düşünün. Her Collection kendi REST ve GraphQL endpoint'lerini, kendi yönetici paneli görünümünü ve kendi erişim kontrol kurallarını alır -- hepsi tek bir yapılandırma dosyasından üretilir.

// 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' },
  ],
}

Global'lar benzer şekilde çalışır ama tekil veriler için -- site ayarlarınız, navigasyon yapılandırmanız, alt bilgi içeriğiniz. Tek bir örnek, koleksiyon liste görünümü yok, yalnızca düzenlenebilir tek bir belge.

Üçlü API Katmanı (REST, GraphQL, Local)

İşte Payload'ın diğer tüm açık kaynak CMS'lerin gerçekten önüne geçtiği yer burası. Üç farklı bağlama göre optimize edilmiş üç içerik sorgulama yöntemi sunuluyor:

• Local API: Sıfır HTTP yüküyle sunucu taraflı sorgular. Next.js server component'lerinde CMS'inizi doğrudan çağırın. Ağ gidiş-dönüşü yok, serileştirme maliyeti yok. Testlerimizde Local API, aynı sunucudaki REST çağrılarına kıyasla sayfa yükleme sürelerini ~40ms azalttı.
• REST API: Harici istemciler, mobil uygulamalar veya üçüncü taraf entegrasyonlar için otomatik oluşturulan endpoint'ler.
• GraphQL API: Veri isteklerini tam olarak şekillendirmesi gereken ön yüzler için esnek sorgular.

Next.js server component'indeki bir Local API çağrısının nasıl göründüğü:

// 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>
}

Fetch çağrısı yok. API URL'si yok. Kimlik doğrulama token'ı yok. Bir server component'inden doğrudan veritabanınızı sorguluyorsunuz ve TypeScript size yanıt üzerinde tam tip güvenliği sağlıyor. Bu gerçekten geçilmesi zor bir avantaj.

Erişim Kontrolü ve Kimlik Doğrulama

Payload'ın erişim kontrol sistemi fonksiyon tabanlıdır. İzinleri bir panoda yapılandırmak yerine true veya false döndüren TypeScript fonksiyonları yazarsınız. Alan düzeyi, koleksiyon düzeyi veya işlem düzeyi -- ayrıntı düzeyine siz karar verirsiniz.

// Örnek: Yalnızca yayımlanan gönderiler herkese açık okunabilir
access: {
  read: ({ req }) => {
    if (req.user) return true // Giriş yapmış kullanıcılar her şeyi görür
    return { status: { equals: 'published' } } // Herkese yalnızca yayımlananlar görünür
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

Kimlik doğrulama yerleşik olarak geliyor: JWT token'ları, yenileme token'ları, şifremi unuttum akışı, e-posta doğrulama. Özellikle istemediğiniz sürece Clerk veya NextAuth'a ihtiyacınız yok. Pek çok proje için Payload'ın kimlik doğrulama sistemi fazlasıyla yeterli.

Lexical Zengin Metin Editörü

Payload, Meta'nın zengin metin framework'ü olan Lexical'i kullanıyor (Draft.js'in arkasındaki ekibin yeni versiyonu, ama çok daha iyi). Özel bloklar, satır içi öğeler ve eğik çizgi komutları ekleyebilirsiniz. Editör, HTML veya React component'lerine dönüştürebileceğiniz yapılandırılmış bir JSON formatına serileştiriyor.

Bu önemli çünkü çoğu CMS zengin metin editörü ya çok basit (sade metin alanı) ya da çok karanlık (öngörülemeyen HTML üreten WYSIWYG). Lexical size tamamen kontrol ettiğiniz yapılandırılmış ve öngörülebilir bir çıktı sunuyor.

Canlı Önizleme ve Görsel Düzenleme

Payload 3, canlı önizlemeyle birlikte geliyor: editörler içerik değişikliklerini yönetici paneliyle yan yana gerçek ön yüzde gerçek zamanlı olarak yansıtılmış şekilde görüyor. Bu, görsel düzenlemenin hiç olmadığı Strapi'ye kıyasla önemli bir açığı kapatıyor.

Sanity Studio'nun gerçek zamanlı işbirliği özellikleri kadar cilalı değil -- Sanity'nin görsel düzenleme deneyimi gerçekten sektörün en iyisi. Ama Sanity'nin kullanıcı başına fiyatlandırmasını ödemeden "yeterince iyi" görsel önizlemeye ihtiyaç duyan ekipler için Payload'ın uygulaması işi görüyor.

Sürümleme, Taslaklar ve Otomatik Kaydetme

Payload yerleşik taslak yönetimi, sürüm geçmişi ve otomatik kaydetme içeriyor -- üst sıralardaki Payload rehberlerinin hiçbirinin bile bahsetmediği özellikler. Koleksiyon başına sürümlemeyi etkinleştirebilirsiniz (yukarıdaki Posts örneğinde versions: { drafts: true } ile yaptığımız gibi), maksimum sürüm sayısını ayarlayabilir ve yönetici arayüzünde revizyonları karşılaştırabilirsiniz.

Editöryal ekipler için bu, "yanlışlıkla taslak yayımladım" felaketlerinin sonu anlamına geliyor. Geliştiriciler için ise ayrı bir sürümleme sistemi eklemenize gerek kalmıyor.

Payload CMS ile Başlarken

Yeni bir Payload projesi başlatmak için npx create-payload-app@latest komutunu çalıştırın, bir şablon seçin (website veya boş), veritabanı adaptörünüzü seçin (PostgreSQL, MongoDB veya SQLite) ve iki dakika içinde localhost:3000/admin adresinde çalışan bir yönetici paneliniz olur. Resmi kurulum kılavuzu edge case'leri de kapsıyor.

Kurulum

Node.js 18+ ve bir paket yöneticisi yeterli.

# Yeni bir Payload projesi oluşturun
npx create-payload-app@latest my-cms

# CLI şunları sorar:
# - Proje adı
# - Şablon (website, boş, e-ticaret)
# - Veritabanı (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Yönetici paneli: http://localhost:3000/admin

Website şablonu çoğu proje için en iyi başlangıç noktasıdır -- çalışan bir blog, pages koleksiyonu, medya yüklemeleri ve bir ön yüzle birlikte geliyor. Boş şablon ise sıfırdan başlamak isteyenler içindir.

Proje Yapısı

Kurulumun ardından projeniz, içine Payload serpiştirilmiş standart bir Next.js uygulaması gibi görünür:

my-cms/
  app/
    (frontend)/          # Web sitesi sayfalarınız
    (payload)/
      admin/             # Yönetici paneli route'ları (otomatik üretilen)
      api/               # REST + GraphQL endpoint'leri
  collections/           # İçerik modeli tanımlarınız
  globals/               # Tekil içerik (ayarlar, navigasyon)
  payload.config.ts      # Ana Payload yapılandırması
  payload-types.ts       # Otomatik üretilen TypeScript tipleri

payload.config.ts dosyası her şeyin kalbidir:

// 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' },
})

İlk Collection'ınızı Oluşturmak

Dev sunucusu çalışırken /collections dizinine bir dosya ekleyerek yeni bir koleksiyon oluşturun. Payload yönetici arayüzünü, API endpoint'lerini ve TypeScript tiplerini yapılandırmanızdan otomatik oluşturur. İşte basit bir Pages koleksiyonu:

// 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' },
          ],
        },
      ],
    },
  ],
}

payload.config.ts koleksiyonlar dizisine ekleyin, dev sunucusunu yeniden başlatın; görsel yönetici arayüzüyle tamamen işlevsel bir sayfa oluşturucu elde etmiş olursunuz. Plugin yok, marketplace indirmesi yok.

Veritabanı Seçenekleri -- Postgres, MongoDB ve SQLite

Payload üç veritabanı adaptörünü destekler: PostgreSQL (production için önerilir), MongoDB (belge ağırlıklı modeller veya mevcut Mongo altyapıları için) ve SQLite (yalnızca yerel geliştirme ve prototipleme için). Adaptör deseni, hangi veritabanını seçerseniz seçin uygulama kodunuzun aynı kalması anlamına gelir.

Sıfırdan başlıyorsanız PostgreSQL tercih edin. İlişkisel veriyi daha iyi yönetiyor (CMS verilerinin çoğu ilişkisel), Neon ve Supabase üzerinden mükemmel sunucusuz seçeneklere sahip ve Payload ekibinin de önerdiği bu. Postgres'in modern uygulama geliştirmede neden baskın olduğuna dair daha fazla bağlam için PostgreSQL vs MySQL karşılaştırmamıza bakabilirsiniz.

Pro ipucu: Vercel'e deploy ediyorsanız Payload'ı Neon Postgres ile eşleştirin. Neon'un bağlantı havuzlama sistemi sunucusuz cold start'ları zarif biçimde yönetiyor -- Vercel yeni fonksiyon örneklerini sürekli başlattığından bu önemli.

Figma Satın Alımı -- Geliştiriciler İçin Ne Anlama Geliyor?

Figma, Payload'ı Haziran 2025'te satın aldı. MIT lisansı ve açık kaynak kod tabanı değişmedi. Payload Cloud yeni kayıtları ekibin bir yedek inşa ederken durdurdu, ancak kendi barındırma etkilenmedi. Geliştiriciler için en büyük soru "Payload öldü mü?" değil -- "Barındırma konusunda ne yapmalıyım?"

Satın alma duyurulduğunda bir müşteri projesi için Payload Cloud'u barındırma seçeneği olarak değerlendiriyorduk. İşte kendi barındırmaya geçişten öğrendiklerimiz ve satın almanın projeleriniz için gerçekte ne anlama geldiği.

17 Haziran 2025'te Figma satın almayı duyurdu. Payload ekibi aynı gün kendi duyurularını yayımladı. Tüm Payload ekibi Figma bünyesine katıldı.

Değişen (Ve Değişmeyen) Şeyler

Aynı kalan şeyler:

• MIT lisansı. Bu geri alınamaz. GitHub deposu aktif kalmaya ve topluluk katkılarına açık olmaya devam ediyor.
• Kod tabanı. Payload 3, satın alma öncesiyle tamamen aynı şekilde çalışıyor.
• Kendi barındırma. Payload'ı istediğiniz yere, sonsuza kadar deploy edebilirsiniz.

Değişen şeyler:

• Payload Cloud yeni kayıtları durdurdu. Mevcut müşteriler devam edebilir ama yeni projeler Payload'ın yönetilen barındırmasını kullanamıyor.
• Ekibin odak noktası değişti. Payload ekibi artık büyük ihtimalle "Figma CMS" olacak şeyi inşa ediyor -- Figma tasarımları ile canlı içerik arasındaki boşluğu kapatarak. Ayrıntılar spekülatif ama yön net.
• Topluluk endişesi. Bazı geliştiriciler açık kaynak projeleri etkileyen "satın alındı-sonra-terk edildi" örüntüsünden endişe duyuyor. MIT lisansı en kötü senaryoyu hafifletiyor ama bu meşru bir endişe.

Hâlâ Payload'ı Seçmeli misiniz?

Dürüstçe? Evet, bazı çekincelerle.

İyi taraf: Figma'nın kaynakları projenin arkasında daha fazla mühendislik yeteneği anlamına geliyor. MIT lisansı en kötü durumda onu fork edebileceğiniz anlamına geliyor. Kod tabanı olgun, iyi belgelenmiş ve binlerce proje tarafından production'da aktif olarak kullanılıyor.

Endişe verici taraf: Figma'nın teşvikleri zamanla açık kaynak topluluğunun ihtiyaçlarından sapabilir. Payload Cloud boşluğu barındırmayı kendiniz halletmenizi zorunlu kılıyor. Risk almaktan kaçınan biriyseniz, uzun vadeli yön etrafındaki belirsizlik gerçek.

Bizim görüşümüz: kendi barındırmayı halledebildiğiniz sürece (ki bunu yapmalısınız -- zor değil), Payload mevcut en iyi açık kaynak, kod öncelikli headless CMS olmayı sürdürüyor. "Figma CMS"i beklemeyin. Payload 3 ile bugün geliştirin, kendi barındırın ve devam edin.

Payload CMS 2026'da Nasıl Deploy Edilir?

Payload Cloud yeni kayıtlar için duraklatıldığından 2026'daki ana dağıtım seçenekleriniz şunlar: Vercel (en hızlı kurulum, cold start'lara dikkat), VPS üzerinde Docker (aktif editörler için en iyi, aylık 7-45 EUR), Railway/Render/Fly.io (yönetilen container'lar) veya Cloudflare Workers (en ucuzu, aylık yaklaşık $5-10). Payload'ın dağıtım belgelerine göre Next.js destekleyen herhangi bir Node.js barındırma işe yarayacak.

Payload'ı hem Vercel'e hem de Docker tabanlı bir VPS'e deploy ettik. Bizi şaşırtan şey şu: Vercel'in cold start'ları yönetici panelini haftada yalnızca birkaç kez giriş yapan editörler için yavaşlattı. Daha fazla kurulum gerektirmesine rağmen VPS, tutarlı olarak daha iyi bir editöryal deneyim sağladı.

Vercel (En Hızlı Kurulum)

Neon Postgres ve dosya yüklemeleri için Vercel Blob ile tek tıkla deploy. Production'a giden en hızlı yol.

Artıları: Sıfır altyapı yönetimi, mükemmel CDN, hafif editöryal aktiviteli siteler için ideal. Eksileri: Yönetici paneli cold start'ları (pasiflik sonrası 3-5 saniye), ağır sorgularda Postgres bağlantı tükenmesi, toplu işlemleri bozabilecek 10 saniyelik timeout tavanı. En iyi kullanım: Pazarlama siteleri, portföyler, seyrek düzenlenen bloglar.

Vercel'in güçlü ve zayıf yönleri hakkında daha fazla bağlam için Vercel vs Netlify karşılaştırmamıza bakın.

VPS Üzerinde Docker (Production için En İyi)

Hetzner, DigitalOcean veya AWS EC2 üzerinde Docker Compose kurulumu. Bu, Payload'ın kalıcı bir sunucu süreci beklediği için mimariyle serverless'tan daha uyumlu.

# 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:

Artıları: Kalıcı sunucu (cold start yok), öngörülebilir maliyetler (Hetzner'de aylık 7-45 EUR), yığın üzerinde tam kontrol. Eksileri: Sunucuyu, SSL'i, yedeklemeleri ve güncellemeleri siz yönetirsiniz. En iyi kullanım: Ajanslar, aktif editöryal ekipler, çok kiracılı kurulumlar, yoğun yönetici kullanımlı uygulamalar.

Build with Matija'nın ayrıntılı barındırma karşılaştırması ek VPS sağlayıcılarını ve yapılandırmalarını kapsıyor.

Yönetilen Container'lar (Railway, Render, Fly.io)

VPS üzerinde Docker çok fazla ops işi gibi görünüyorsa, yönetilen container platformları ikisi arasındaki dengeyi kuruyor. Railway özellikle Payload topluluğunda popüler -- tek tıkla deploy eden bir Payload şablonları var.

Bu platformların daha kapsamlı incelemesi için Railway vs Render vs Fly.io karşılaştırmamıza bakabilirsiniz.

En iyi kullanım: Altyapıyı doğrudan yönetmeden kalıcı sunucu isteyen ekipler.

Cloudflare Workers (En Ucuz)

En yeni seçenek. Payload, D1 (SQLite) veya Hyperdrive (Postgres proxy) ile edge fonksiyonlarında çalışan bir Cloudflare Workers adaptörü ekledi. Hâlâ biraz deneysel, ama maliyet rakipsiz: çoğu proje için aylık yaklaşık $5-10.

En iyi kullanım: Yan projeler, kişisel siteler, daha az test edilmiş altyapıyla rahatlayan bütçe bilincindeki kullanıcılar.

Kararımız: Aktif editörlü çoğu production Payload projesi için VPS üzerinde Docker en iyi varsayılan seçenek. Düşündüğünüzden daha ucuz, cold start sorunlarını ortadan kaldırıyor ve size tam kontrol sağlıyor. Vercel'i yalnızca editörleriniz seyrekse ve sıfır ops yükü istiyorsanız kullanın.

Payload CMS Fiyatlandırması -- Gerçekte Ne Kadar Tutuyor?

Payload'ın kendisi ücretsiz ve MIT lisanslı. Gerçek maliyetleriniz barındırma ve (isteğe bağlı olarak) profesyonel geliştirmedir. İşte gerçek dünya kurulumlarına ve Build with Matija'nın fiyatlandırma dökümüne dayanan rakamlar.

Karşılaştırma için: Contentful'un Team planı $300/ay'dan başlıyor. Sanity'nin Team planı proje başına $99/ay. Strapi Cloud $29/ay'dan başlıyor. Payload'ın $0 yazılım maliyeti artı aylık $7-25 barındırma tartışmak güç -- özellikle kullanıcı başına fiyatlandırmanın marjları erittiği müşteri projeleri geliştiren ajanslar için.

Payload vs Sanity vs Strapi vs Contentful -- Hızlı Karşılaştırma

Kod öncelikli kontrol ve kendi barındırma istiyorsanız Payload'ı tercih edin. En iyi görsel düzenleme ve gerçek zamanlı işbirliği için Sanity'yi seçin. Plugin ekosistemiyle hızlı bir yönetici paneli için Strapi'yi değerlendirin. SLA garantileri olan kurumsal düzey altyapı için Contentful'u kullanın. techsy.io için Sanity kullanıyoruz, bu nedenle bu platformları karşılaştırma konusunda bizzat deneyimimiz var.

Kendi barındırma ve veri sahipliğine ihtiyaç duyan müşteriler için Payload tabanlı projeler geliştirdik, kendi içerik pipeline'ımızı ise Sanity üzerinde çalıştırıyoruz. Her ikisi de mükemmel -- doğru seçim ekibinizin teknik yeterliliğine ve barındırma tercihlerine bağlı. Bir proje için headless CMS seçeneklerini değerlendiriyorsanız, seçim yapmanıza yardımcı olabiliriz.

Her platform hakkında daha derin incelemeler için rehberlerimize göz atın: 2026'nın en iyi headless CMS'leri ve ayrı Sanity, Strapi ve Contentful rehberleri.

Payload CMS Kullanmaman Gereken Durumlar

Ekibiniz teknik değilse ve WordPress benzeri bir arayüze ihtiyaç duyuyorsa, kendi barındırma çalışması olmadan anında yönetilen bulut barındırma istiyorsanız, editörleriniz Sanity Studio düzeyinde görsel düzenleme bekliyorsa ya da hızlı özellik genişletmesi için bir plugin marketplace'e ihtiyaç duyuyorsanız Payload'ı atlayın. Sınırlamalar konusunda dürüst olmak, yokmuş gibi davranmaktan daha fazla güven inşa eder.

TypeScript deneyimi sıfır olan editöryal ekiplere sahip müşteriler için Payload'a karşı tavsiyede bulunduğumuz oldu. İşte başka bir yere bakmanız gereken durumlar:

• Teknik olmayan ekipler. Payload yapılandırma için TypeScript bilgisi gerektiriyor. Müşterinizin editörleri koda dokunamıyor ve içerik modelini kendileri değiştirmeleri gerekiyorsa, WordPress veya Sanity daha uygun seçenekler.
• Hemen yönetilen barındırmaya ihtiyacınız var. Payload Cloud yeni kayıtlar için duraklatıldığından kendi barındırmanız gerekiyor. Basit bir Docker kurulumu bile olsa sunucu yönetmek kabul edilemez bir durum olacaksa, Contentful veya Sanity'nin bulut tabanlı yaklaşımı bu yükü ortadan kaldırıyor.
• Yoğun editöryal işbirliği. Sanity Studio'nun gerçek zamanlı işbirliği -- aynı belgede aynı anda çalışan birden fazla editör, varlık göstergeleriyle -- Payload'ın sunduğundan daha cilalı. Büyük bir editöryal ekibiniz varsa Sanity burada kazanıyor.
• Plugin odaklı geliştirme. Strapi daha büyük bir plugin marketplace'e sahip. Bir SEO plugin'i, site haritası üreticisi, e-posta entegrasyonu mu lazım? Strapi'de muhtemelen var. Payload'ın ekosistemi büyüyor ama daha küçük.
• Next.js kullanmıyorsunuz. Payload 3 mimarisi olarak Next.js'e bağlı. Ön yüzünüz Astro, Remix, Nuxt veya SvelteKit ise Payload'ın en büyük avantajı (server component'lerde Local API) geçerli olmuyor. Hâlâ REST ve GraphQL elde ederdiniz, ama bu noktada Strapi veya Directus daha doğal hissettirilebilir.

SSS

Payload CMS nedir ve nasıl çalışır?

Payload, Next.js üzerine inşa edilmiş açık kaynaklı, TypeScript tabanlı bir headless CMS ve uygulama framework'üdür. İçerik modelinizi TypeScript yapılandırma dosyalarında tanımlarsınız; Payload otomatik olarak bir yönetici paneli, REST API, GraphQL API ve Local API üretir. Next.js uygulamanızın içinde tek bir deploy edilebilir birim olarak çalışır.

Payload CMS kullanmak ücretsiz mi?

Payload MIT lisansı kapsamında tamamen ücretsizdir. Yazılımın indirilmesi, kullanılması veya değiştirilmesi herhangi bir ücrete tabi değildir. Payload Cloud (yönetilen barındırma) aylık $35-199 arasındaydı ancak Figma satın alımının ardından yeni kayıtlar için duraklatıldı. VPS üzerinde kendi barındırma, sağlayıcıya göre aylık 7-45 EUR'a mal oluyor.

Payload ile Figma arasında ne yaşandı?

Figma, Payload'ı 17 Haziran 2025'te satın aldı. Tüm Payload ekibi Figma'ya katıldı. Açık kaynak MIT lisansı ve GitHub deposu değişmedi. Payload Cloud yeni kayıtları durdurdu. Kendi barındırma normal şekilde çalışmaya devam ediyor. Ekip büyük ihtimalle Figma entegrasyonlu bir CMS ürünü inşa ediyor, ancak ayrıntılar henüz duyurulmadı.

Payload CMS hangi veritabanını kullanıyor?

Payload adaptör deseni aracılığıyla üç veritabanını destekliyor: PostgreSQL (sunucusuz için Neon ve Supabase ile çalışan, production için önerilen), MongoDB (belge ağırlıklı modeller veya Payload 2 yükseltmeleri için iyi), SQLite (yalnızca yerel geliştirme ve CI). Hangi adaptörü seçerseniz seçin uygulama kodunuz aynı kalıyor.

2026'da Payload CMS nasıl deploy edilir?

Payload Cloud duraklatıldığında şu seçenekler var: Neon Postgres ile Vercel (en kolay), Hetzner gibi bir VPS üzerinde Docker (aktif editörler için production'da en iyi), Railway veya Render (yönetilen container'lar) ya da Cloudflare Workers (en ucuz). Düzenli editöryal aktivitesi olan çoğu production sitesi için Docker tabanlı VPS en iyi deneyimi sunuyor.

Payload CMS Strapi'den daha iyi mi?

Payload, TypeScript'e özgü geliştirici deneyimi, Next.js entegrasyonu ve sunucu taraflı sıfır yüklü sorgular için benzersiz Local API açısından öne çıkıyor. Strapi plugin marketplace, GUI tabanlı şema düzenleme ve daha geniş framework uyumluluğu konusunda kazanıyor. Ekibiniz TypeScript yazıyor ve Next.js kullanıyorsa Payload daha güçlü seçenek. Aksi durumda Strapi'yi değerlendirin.

Payload'ın Local API'sı nedir?

Local API, veritabanınızı doğrudan sıfır HTTP yüküyle çağıran sunucu taraflı bir sorgu katmanıdır. REST veya GraphQL çağrıları yapmak yerine Payload'ı import edip Next.js server component'lerinde koleksiyonları doğrudan sorgularsınız. Bu, ağ gidiş-dönüşlerini ve serileştirme maliyetlerini ortadan kaldırarak daha hızlı sayfa yükleme sürelerine yol açıyor. Başka hiçbir headless CMS bunu sunmuyor.

Payload CMS büyük ölçekli uygulamaları kaldırabilir mi?

Payload; bağlantı havuzlama (Neon veya PgBouncer ile) destekli PostgreSQL, alan düzeyinde ayrıntılı rol tabanlı erişim kontrolü, taslak ve sürümleme iş akışları ve çok kiracılı mimarileri destekliyor. Kurumsal yapılar ve ajanslar içerik ağırlıklı uygulamalar için Payload'ı production'da kullanıyor. Local API'nın sıfır yüklü sorguları ölçekte performansı gerçekten artırıyor.

Payload, Sanity ile nasıl karşılaştırılır?

Payload kendi barındırmalı, kod öncelikli ve MIT lisanslıdır; sunucu taraflı performans için Local API'ya sahip. Sanity bulut barındırmalı olup üstün görsel düzenleme, gerçek zamanlı işbirliği ve GROQ sorgu dili sunuyor. Payload size daha fazla altyapı kontrolü ve düşük maliyet sağlıyor. Sanity ise daha iyi editöryal araçlar ve sıfır barındırma yönetimi sunuyor.

Payload CMS'in dezavantajları nelerdir?

Payload yapılandırma için TypeScript bilgisi gerektiriyor, Figma satın alımından bu yana yeni kullanıcılar için yönetilen bulut barındırma sunmuyor, Strapi'ye kıyasla daha küçük bir plugin ekosistemine sahip ve 3. sürümde mimarisi olarak Next.js'e bağlı. Teknik olmayan ekipler kod öncelikli yaklaşımla zorlanabilir ve Figma satın alımı uzun vadeli yön konusunda belirsizlik yaratıyor.