Payload CMS 2026：為何 Figma 收購它（以及你該採用嗎？）

Payload CMS 2026：為何 Figma 收購它（以及你該採用嗎？）

Payload 是一個開源、原生 TypeScript 的無頭 CMS（Headless CMS），它直接存在於你的 Next.js 應用程式中——不是並排運行，也不是在獨立的容器中，而是 literally 位於同一個 /app 資料夾內。如果你曾因那些按席位收費或透過專有 API 鎖定內容的託管 CMS 平台而受苦，Payload 絕對值得你認真考慮。

但 2026 年出現了一個轉折點：Figma 收購了 Payload，Payload Cloud 暫停新用戶註冊，開發者突然需要自行解決主機託管問題。本指南將涵蓋從初次安裝到生產環境部署的一切，提供最新的 Payload 3 程式碼範例，並誠實分析 Payload 的優勢與不足。

什麼是 Payload CMS？（以及為何開發者喜愛它）

Payload 是一個開源、原生 TypeScript 的無頭 CMS 與應用程式框架，運行於你的 Next.js 應用程式內部。與託管式 CMS 平台不同，Payload 提供程式碼優先（code-first）的配置、三個內建 API（REST、GraphQL、Local），以及完全可自訂的管理後台，全部來自單一程式碼庫。根據 Payload 官方文件，其設計目標是成為「建構現代後端的最佳方式」。

該專案始於 2021 年，最初是一個 Node.js/Express CMS。2023 年推出的 Payload 2 改進了 TypeScript 支援。隨後，Payload 3 徹底改變了遊戲規則：CMS 直接移入你的 Next.js 應用程式中。沒有獨立的伺服器進程，沒有獨立的部署。你的 CMS 與前端共享相同的 Next.js 運行時、相同的路由以及相同的建置流程。

這與 Sanity、Strapi 或 Contentful 提供的架構截然不同。這種差異對你建構、部署以及思考內容層的方式產生了實質影響。

程式碼優先哲學

大多數 CMS 平台提供圖形使用者介面（GUI）來定義內容模型。點擊「新增欄位」，選擇「文字」，命名為「title」。Payload 則反其道而行：你在 TypeScript 檔案中定義一切。你的結構描述（Schema）就是程式碼。它存在於版本控制中。你可以在 Pull Request 中審查它。

這意味著環境之間不會出現結構描述漂移，也不會發生「有人在測試環境更改了內容模型卻沒人知道發生了什麼事」的意外。如果你曾在內容模型存放在雲端儀表板的團隊中工作過，你就會明白這有多重要。

Payload 3 架構，原生 Next.js

Payload 3 並非在你的 Next.js 應用程式旁邊運行，而是運行在其中。管理後台位於 /app/(payload)/admin，你的 API 路由位於 /app/(payload)/api，而你的前端頁面則共存於同一個專案中。如果你曾在生產環境中使用過 Next.js，你會感到非常熟悉。

讓 Payload 脫穎而出的關鍵功能

Payload 的突出功能包括用於內容建模的 Collections、三重 API 層（REST、GraphQL、Local）、具備欄位級粒度的基於角色的訪問控制、內建身份驗證、Lexical 富文本編輯器，以及用於視覺化編輯的即時預覽。以下是這些功能對你的程式碼庫實際意味著什麼。

Collections、Globals 與 Fields

Collections 是 Payload 核心的內容建模原語。你可以將它們想像成資料庫表，但完全使用 TypeScript 定義。每個 Collection 都會從單一配置檔案生成自己的 REST 和 GraphQL 端點、獨立的管理後台視圖以及專屬的訪問控制規則。

// 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 的工作方式類似，但適用於單例數據，例如網站設置、導航配置、頁腳內容。只有一個實例，沒有集合列表視圖，只有一份可編輯的文件。

三重 API 層（REST、GraphQL、Local）

這是 Payload 真正勝過其他開源 CMS 的地方。你擁有三種查詢內容的方式，每種都針對不同情境進行了優化：

• Local API：零 HTTP 開銷的伺服器端查詢。直接在 Next.js 伺服器元件中呼叫你的 CMS。沒有網路往返，沒有序列化成本。在我們的測試中，與同一伺服器上的 REST 呼叫相比，Local API 將頁面載入時間減少了約 40 毫秒。
• REST API：自動生成的端點，供外部客戶端、移動應用程式或第三方整合使用。
• GraphQL API：靈活的查詢，適用於需要精確塑造數據請求的前端。

以下是在 Next.js 伺服器元件中呼叫 Local API 的樣子：

// 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 呼叫。沒有 API URL。沒有身份驗證令牌。你直接從伺服器元件查詢資料庫，且 TypeScript 為回應提供完整的類型安全。這很難被超越。

訪問控制與身份驗證

Payload 的訪問控制系統是基於函式的。你不是在儀表板中配置權限，而是編寫返回 true 或 false 的 TypeScript 函式。無論是欄位級、集合級還是操作級，粒度由你決定。

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

身份驗證是內建的：JWT 令牌、刷新令牌、忘記密碼流程、電子郵件驗證。除非你有特定需求，否則不需要 Clerk 或 NextAuth。對於許多專案來說，Payload 的身份驗證功能已經足夠強大。

Lexical 富文本編輯器

Payload 使用 Lexical，這是 Meta 的富文本框架（與 Draft.js 同一團隊，但更好）。你可以添加自訂區塊、行內元素和斜線命令。編輯器將內容序列化為結構化的 JSON 格式，你可以將其轉換為 HTML 或 React 元件。

這很重要，因為大多數 CMS 的富文本編輯器要麼太基礎（純文字區域），要麼太不透明（生成不可預測 HTML 的所見即所得編輯器）。Lexical 提供結構化、可預測的輸出，完全由你控制。

即時預覽與視覺化編輯

Payload 3 附帶即時預覽功能：編輯者可以在管理後台旁實時看到內容更改反映在實際前端上。與完全沒有視覺化編輯功能的 Strapi 相比，這是一個重要的補充。

雖然它不如 Sanity Studio 的即時協作功能那麼精緻（Sanity 的視覺化編輯確實是同類中最好的），但對於需要「足夠好」的視覺預覽而不想支付 Sanity 按席位定價的團隊來說，Payload 的實現足以勝任。

版本控制、草稿與自動儲存

Payload 包含內建的草稿管理、版本歷史記錄和自動儲存功能，這些功能在排名靠前的 Payload 指南中甚至很少被提及。你可以為每個集合啟用版本控制（我們在上面的 Posts 範例中使用 versions: { drafts: true } 啟用了它），設置最大版本數量，並在管理 UI 中比較修訂版本。

對於編輯團隊來說，這意味著不再發生「我不小心發布了草稿」的災難。對於開發者來說，這意味著你不需要額外安裝獨立的版本控制系統。

開始使用 Payload CMS

要啟動新的 Payload 專案，運行 npx create-payload-app@latest，選擇模板（網站或空白），選擇你的資料庫適配器（PostgreSQL、MongoDB 或 SQLite），不到兩分鐘你就能在 localhost:3000/admin 看到一個可用的管理後台。官方安裝指南 涵蓋了邊緣情況。

安裝

你需要 Node.js 18+ 和一個套件管理器。就這麼簡單。

# 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

網站模板是大多數專案的最佳起點，它附帶一個可用的部落格、頁面集合、媒體上傳功能和前端。空白模板則適用於想要從零開始建構的情況。

專案結構

安裝後，你的專案看起來像是一個標準的 Next.js 應用程式，只是融入了 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

payload.config.ts 檔案是一切的核心：

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

你的第一個 Collection

當開發伺服器運行時，透過在 /collections 中添加檔案來建立新的 collection。Payload 會從你的配置中自動生成管理 UI、API 端點和 TypeScript 類型。以下是一個簡單的 Pages collection：

// 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 collections 陣列中，重啟開發伺服器，你就擁有了一個帶有視覺化管理介面的功能完備的頁面建構器。無需插件，無需從市場下載。

資料庫選項：Postgres、MongoDB 與 SQLite

Payload 支援三種資料庫適配器：PostgreSQL（推薦用於生產環境）、MongoDB（適用於文件密集型模型或現有的 Mongo 技術棧）以及 SQLite（僅用於本地開發和原型設計）。適配器模式意味著無論你選擇哪種資料庫，你的應用程式程式碼都保持不變。

如果你從頭開始，請選擇 PostgreSQL。它能更好地處理關聯式數據（大多數 CMS 數據都是關聯式的），透過 Neon 和 Supabase 提供優秀的無伺服器選項，這也是 Payload 團隊推薦的。查看我們的 PostgreSQL vs MySQL 比較，了解更多關於為何 Postgres 主宰現代應用程式開發的背景。

專業提示： 如果你部署到 Vercel，請將 Payload 與 Neon Postgres 搭配使用。Neon 的連接池能優雅地處理無伺服器冷啟動，這很重要，因為 Vercel 會不斷啟動新的函式實例。

Figma 收購案：對開發者意味著什麼

Figma 於 2025 年 6 月收購了 Payload。MIT 授權條款和開源程式碼庫保持不變。Payload Cloud 在團隊建構替代方案期間暫停新用戶註冊，但自行託管不受影響。對於開發者來說，最大的問題不是「Payload 死了嗎？」，而是「我該如何處理主機託管？」

當收購消息宣布時，我們正為一個客戶專案追蹤 Payload Cloud 作為託管選項。以下是我們從轉向自行託管中學到的經驗，以及這次收購對你專案的實際意義。

2025 年 6 月 17 日，Figma 在其部落格上宣布了收購消息。Payload 團隊在同一天發布了他們自己的公告。整個 Payload 團隊併入了 Figma。

改變了什麼（以及沒改變什麼）

保持不變的部分：

• MIT 授權條款。這無法被撤銷。GitHub 倉庫 仍然活躍並開放給社群貢獻。
• 程式碼庫。Payload 3 的工作方式與收購前完全相同。
• 自行託管。你可以隨時隨地部署 Payload，永久有效。

改變的部分：

• Payload Cloud 暫停新用戶註冊。現有客戶可以繼續使用，但新專案無法使用 Payload 的託管服務。
• 團隊焦點轉移。Payload 團隊現在正在建構可能成為「Figma CMS」的產品，彌合 Figma 設計與即時內容之間的差距。具體細節尚屬猜測，但方向很明確。
• 社群關注度。一些開發者擔心開源專案常見的「收購後棄置」模式。MIT 授權條款減輕了最壞情況的影響，但這是一個合理的擔憂。

你還應該選擇 Payload 嗎？

老實說？是的，但有前提條件。

好的方面：Figma 的資源意味著專案背後有更多的工程人才。MIT 授權條款意味著最壞的情況是你 fork 它。程式碼庫成熟、文件完善，並被數千個專案積極用於生產環境。

令人擔憂的方面：隨著時間推移，Figma 的激勵措施可能會與開源社群的需求背道而馳。Payload Cloud 的空缺迫使你自行處理託管。如果你厭惡風險，長期方向的不確定性是真實存在的。

我們的看法：如果你習慣自行託管（這並不難，你應該能做到），Payload 仍然是目前最好的開源、程式碼優先的無頭 CMS。不要等待「Figma CMS」。今天就使用 Payload 3 建構，自行託管，然後繼續前進。

如何在 2026 年部署 Payload CMS

隨著 Payload Cloud 暫停新用戶註冊，你在 2026 年的主要部署選項包括：Vercel（設置最快，需注意冷啟動）、VPS 上的 Docker（最適合活躍編輯者，每月 7-45 歐元）、Railway/Render/Fly.io（託管容器），或 Cloudflare Workers（最便宜，約 $5-10/月）。根據 Payload 的部署文件，任何支援 Next.js 的 Node.js 託管服務都可以運作。

我們將 Payload 部署到了 Vercel 和基於 Docker 的 VPS。讓我們驚訝的是：Vercel 的冷啟動使得每週只登入幾次的編輯者覺得管理後台反應遲鈍。儘管 VPS 需要更多設置，但它提供了始終如一的更佳編輯體驗。

Vercel（設置最快）

一鍵部署，搭配 Neon Postgres 和 Vercel Blob 進行文件上傳。通往生產環境的最快路徑。

優點： 零基礎設施管理、優秀的 CDN、適合編輯活動較少的網站。 缺點： 管理後台冷啟動（閒置後 3-5 秒）、重度查詢下 Postgres 連接耗盡、10 秒超時上限可能破壞批量操作。 最佳適用場景： 行銷網站、作品集、編輯頻率低的部落格。

有關 Vercel 優勢和限制的更多背景資訊，請參閱我們的 Vercel vs Netlify 比較。

VPS 上的 Docker（最適合生產環境）

在 Hetzner、DigitalOcean 或 AWS EC2 上設置 Docker Compose。這比無伺服器更符合 Payload 的架構，因為 Payload 期望一個持久的伺服器進程。

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

優點： 持久伺服器（無冷啟動）、可預測的成本（Hetzner 上每月 7-45 歐元）、對技術棧的完全控制。 缺點： 你需要管理伺服器、SSL、備份和更新。 最佳適用場景： 代理商、活躍的編輯團隊、多租戶設置、管理後台使用頻繁的應用程式。

Build with Matija 提供的詳細主機比較 涵蓋了額外的 VPS 供應商和配置。

託管容器（Railway、Render、Fly.io）

如果覺得在 VPS 上使用 Docker 運維工作太多，託管容器平台提供了折衷方案。Railway 在 Payload 社群中特別受歡迎，他們有一個一鍵部署的 Payload 模板。

查看我們的 Railway vs Render vs Fly.io 比較，深入了解這些平台。

最佳適用場景： 希望擁有持久伺服器但不想直接管理基礎設施的團隊。

Cloudflare Workers（最便宜）

最新的選項。Payload 添加了 Cloudflare Workers 適配器，可在邊緣函式上運行，搭配 D1（SQLite）或 Hyperdrive（Postgres 代理）。仍處於實驗階段，但成本無人能敵：大多數專案每月約 $5-10。

最佳適用場景： 側邊專案、個人網站、預算有限的部署，且你願意接受較新、測試較少的基礎設施。

我們的結論： 對於大多數擁有活躍編輯者的生產環境 Payload 專案，VPS 上的 Docker 是最佳預設選擇。它比你想像的便宜，消除了冷啟動問題，並給予你完全的控制權。僅當你的編輯者不頻繁且希望零運維負擔時，才使用 Vercel。

Payload CMS 定價：實際成本是多少

Payload 本身是免費且採用 MIT 授權。你的實際成本是主機託管和（可選的）專業開發費用。以下是基於真實世界設置和 Build with Matija 的定價細目 的實際數字。

作為比較：Contentful 的 Team 方案起價為 $300/月。Sanity 的 Team 方案為每個專案 $99/月。Strapi Cloud 起價為 $29/月。Payload 的 $0 軟體成本加上 $7-25/月的主機費用很難反駁，特別是對於建構客戶專案的代理商而言，按席位定價會嚴重壓縮利潤空間。

Payload vs Sanity vs Strapi vs Contentful：快速比較

如果你想要程式碼優先控制和自行託管，選擇 Payload。如果你想要最佳的視覺化編輯和即時協作，選擇 Sanity。如果你想要帶有插件生態系統的快速管理後台，選擇 Strapi。如果你想要帶有 SLA 保證的企業級基礎設施，選擇 Contentful。我們在 techsy.io 使用 Sanity，因此我們有 firsthand 經驗比較這些平台。

我們為需要數據所有權和自行託管的客戶建構了基於 Payload 的專案，同時我們也在 Sanity 上運行自己的內容管道。兩者都很優秀，正確的選擇取決於你團隊的技術舒適度和主機偏好。如果你正在為專案評估無頭 CMS 選項，我們可以協助你選擇。

有關每個平台的深入探討，請查看我們的指南：2026 年最佳無頭 CMS，以及即將推出的 Sanity、Strapi 和 Contentful 個別指南。

何時不應使用 Payload CMS

如果你的團隊非技術背景且需要類似 WordPress 的 GUI，如果你需要無需自行託管工作的即時託管雲端主機，如果你的編輯者想要 Sanity Studio 級別的視覺化編輯，或者如果你需要插件市場來快速擴展功能，請跳過 Payload。誠實面對局限性比假裝它們不存在更能建立信任。

我們曾建議那些編輯團隊完全沒有 TypeScript 經驗的客戶不要使用 Payload。以下是你應該尋找其他替代方案的情況：

• 非技術團隊。 Payload 需要 TypeScript 知識進行配置。如果你的客戶編輯者無法接觸程式碼且需要自行修改內容模型，WordPress 或 Sanity 是更好的選擇。
• 你現在就需要託管主機。 由於 Payload Cloud 暫停新用戶註冊，你必須自行託管。如果管理伺服器（即使是簡單的 Docker 設置）是不可接受的障礙，Contentful 或 Sanity 的雲端託管方法可以消除這一負擔。
• 重度編輯協作。 Sanity Studio 的即時協作功能（多位編輯者同時處理同一份文件並顯示在線狀態指示器）比 Payload 提供的任何功能都更精緻。如果你有大型編輯團隊，Sanity 在此方面勝出。
• 插件驅動開發。 Strapi 擁有更大的插件市場。需要 SEO 插件、站點地圖生成器、電子郵件整合？Strapi 可能都有。Payload 的生態系統正在成長，但規模較小。
• 你不使用 Next.js。 Payload 3 在架構上與 Next.js 緊密綁定。如果你的前端是 Astro、Remix、Nuxt 或 SvelteKit，Payload 的最大優勢（伺服器元件中的 Local API）就不適用了。你仍然可以使用 REST 和 GraphQL，但在這種情況下，Strapi 或 Directus 可能會感覺更自然。

常見問題

什麼是 Payload CMS，它是如何運作的？

Payload 是一個基於 Next.js 建構的開源、原生 TypeScript 無頭 CMS 和應用程式框架。你在 TypeScript 配置檔案中定義內容模型，Payload 會自動生成管理後台、REST API、GraphQL API 和 Local API。它作為單一可部署單元運行在你的 Next.js 應用程式內部。

Payload CMS 可以免費使用嗎？

Payload 在 MIT 授權下完全免費。軟體下載、使用或修改均無需費用。Payload Cloud（託管主機）價格為 $35-199/月，但在 Figma 收購後目前已暫停新用戶註冊。在 VPS 上自行託管的成本取決於供應商，約為每月 7-45 歐元。

Payload 和 Figma 發生了什麼事？

Figma 於 2025 年 6 月 17 日收購了 Payload。整個 Payload 團隊加入了 Figma。開源 MIT 授權和 GitHub 倉庫保持不變。Payload Cloud 暫停新用戶註冊。自行託管繼續正常運作。該團隊可能正在建構與 Figma 整合的 CMS 產品，但具體細節尚未公布。

Payload CMS 使用什麼資料庫？

Payload 透過適配器模式支援三種資料庫：PostgreSQL（推薦用於生產環境，可與 Neon 和 Supabase 配合實現無伺服器）、MongoDB（適合文件密集型模型或 Payload 2 升級）以及 SQLite（僅限本地開發和 CI）。無論你選擇哪種適配器，你的應用程式程式碼都保持不變。

如何在 2026 年部署 Payload CMS？

隨著 Payload Cloud 暫停服務，你可以部署到搭配 Neon Postgres 的 Vercel（最簡單）、像 Hetzner 這樣的 VPS 上的 Docker（最適合擁有活躍編輯者的生產環境）、Railway 或 Render（託管容器），或 Cloudflare Workers（最便宜）。對於大多數具有定期編輯活動的生產網站，基於 Docker 的 VPS 提供最佳體驗。

Payload CMS 比 Strapi 好吗？

Payload 在原生 TypeScript 開發者體驗、Next.js 整合以及獨特的零開銷伺服器端查詢 Local API 方面勝出。Strapi 在其插件市場、基於 GUI 的結構描述編輯以及更廣泛的框架相容性方面勝出。如果你的團隊編寫 TypeScript 並使用 Next.js，Payload 是更強的選擇。否則，請評估 Strapi。

什麼是 Payload 的 Local API？

Local API 是一個伺服器端查詢層，直接呼叫你的資料庫，零 HTTP 開銷。與其進行 REST 或 GraphQL 呼叫，不如在 Next.js 伺服器元件中匯入 Payload 並直接查詢 collections。這消除了網路往返和序列化成本，從而加快頁面載入速度。沒有其他無頭 CMS 提供此功能。

Payload CMS 能處理大規模應用程式嗎？

Payload 支援帶有連接池的 PostgreSQL（透過 Neon 或 PgBouncer）、具備欄位級粒度的基於角色的訪問控制、草稿和版本控制工作流程，以及多租戶架構。企業和代理商在生產環境中使用 Payload 處理內容密集的應用程式。Local API 的零開銷查詢實際上提高了大規模下的性能。

Payload 與 Sanity 相比如何？

Payload 是自行託管、程式碼優先且採用 MIT 授權，並擁有用於伺服器端性能的 Local API。Sanity 是雲端託管，擁有 superior 視覺化編輯、即時協作和 GROQ 查詢語言。Payload 給你更多的基礎設施控制和更低的成本。Sanity 給你更好的編輯工具和零主機管理負擔。

Payload CMS 的缺點是什麼？

Payload 需要 TypeScript 知識進行配置，自 Figma 收購以來沒有為新用戶提供託管雲端主機，插件生態系統比 Strapi 小，且在版本 3 中架構上與 Next.js 綁定。非技術團隊可能會在程式碼優先方法上遇到困難，且 Figma 收購帶來了一些長期不確定性。