Payload CMS 2026: Tại sao Figma mua lại và bạn có nên áp dụng không?

Payload CMS 2026: Tại sao Figma mua lại (Và bạn có nên áp dụng nó?)

Payload là một headless CMS mã nguồn mở, native TypeScript, tồn tại bên trong ứng dụng Next.js của bạn — không phải chạy song song, cũng không nằm trong một container riêng biệt, mà thực sự nằm chung trong thư mục /app. Nếu bạn từng gặp rắc rối với các nền tảng CMS trả phí theo số lượng người dùng (seat) hoặc khóa nội dung của bạn đằng sau các API độc quyền, thì Payload xứng đáng để bạn cân nhắc nghiêm túc.

Tuy nhiên, năm 2026 mang đến một bất ngờ: Figma đã mua lại Payload, Payload Cloud tạm dừng đăng ký mới, và các nhà phát triển đột ngột phải tự mình lo chuyện hosting. Hướng dẫn này bao quát mọi thứ từ cài đặt lần đầu đến triển khai production, kèm theo các ví dụ mã nguồn Payload 3 cập nhật nhất và những nhận định trung thực về điểm mạnh cũng như hạn chế của Payload.

Payload CMS là gì? (Và tại sao các Developer yêu thích nó)

Payload là một framework ứng dụng và headless CMS mã nguồn mở, native TypeScript, chạy ngay bên trong ứng dụng Next.js của bạn. Khác với các nền tảng CMS được lưu trữ (hosted), Payload cung cấp cấu hình code-first, ba API tích hợp sẵn (REST, GraphQL, Local) và một bảng điều khiển admin hoàn toàn tùy chỉnh, tất cả từ một codebase duy nhất. Theo tài liệu chính thức của Payload, nó được thiết kế để trở thành "cách tốt nhất để xây dựng backend hiện đại."

Dự án khởi đầu vào năm 2021 dưới dạng một CMS Node.js/Express. Payload 2 ra mắt năm 2023 với hỗ trợ TypeScript được cải thiện. Sau đó, Payload 3 đã thay đổi cuộc chơi hoàn toàn: CMS di chuyển vào bên trong ứng dụng Next.js của bạn. Không còn tiến trình server riêng. Không còn triển khai riêng biệt. CMS và frontend của bạn chia sẻ cùng runtime Next.js, cùng các route và cùng quy trình build.

Đó là một kiến trúc thực sự khác biệt so với những gì Sanity, Strapi hay Contentful cung cấp. Và điều này có những hệ quả thực tế đối với cách bạn xây dựng, triển khai và tư duy về lớp nội dung (content layer) của mình.

Triết lý Code-First

Hầu hết các nền tảng CMS cung cấp giao diện đồ họa (GUI) để định nghĩa mô hình nội dung. Bạn nhấp "thêm trường", chọn "văn bản", đặt tên là "tiêu đề". Payload đảo ngược quy trình này: bạn định nghĩa mọi thứ trong các file TypeScript. Schema của bạn là code. Nó nằm trong hệ thống quản lý phiên bản (version control). Bạn có thể review nó trong các pull request.

Điều này có nghĩa là không có sự lệch lạc schema giữa các môi trường, không có những bất ngờ kiểu "ai đó đã thay đổi mô hình nội dung trên staging và không ai biết chuyện gì đã xảy ra". Nếu bạn từng làm việc trong một đội nhóm nơi mô hình nội dung nằm trên dashboard đám mây, bạn sẽ hiểu rõ tại sao điều này lại quan trọng.

Kiến trúc Payload 3, Native Next.js

Payload 3 không chạy cạnh ứng dụng Next.js của bạn. Nó chạy bên trong nó. Bảng điều khiển admin nằm tại /app/(payload)/admin, các route API của bạn nằm trong /app/(payload)/api, và các trang frontend cùng tồn tại trong cùng một dự án. Nếu bạn đã từng sử dụng Next.js trong production, bạn sẽ cảm thấy rất quen thuộc.

Các tính năng chính giúp Payload nổi bật

Các tính năng nổi bật của Payload bao gồm Collections để mô hình hóa nội dung, lớp API ba tầng (REST, GraphQL, Local), kiểm soát truy cập dựa trên vai trò với độ chi tiết đến từng trường, xác thực tích hợp sẵn, trình soạn thảo văn bản phong phú Lexical và xem trước trực tiếp (live preview) cho chỉnh sửa trực quan. Dưới đây là ý nghĩa thực tế của từng tính năng đối với codebase của bạn.

Collections, Globals & Fields

Collections là nguyên tắc cốt lõi để mô hình hóa nội dung trong Payload. Hãy nghĩ chúng giống như các bảng cơ sở dữ liệu, nhưng được định nghĩa hoàn toàn bằng TypeScript. Mỗi Collection có các endpoint REST và GraphQL riêng, giao diện admin riêng và các quy tắc kiểm soát truy cập riêng, tất cả đều được tạo ra từ một file cấu hình duy nhất.

// 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 hoạt động tương tự nhưng dành cho dữ liệu đơn lẻ (singleton), chẳng hạn như cài đặt trang web, cấu hình điều hướng, nội dung footer. Chỉ có một instance, không có danh sách collection, chỉ là một tài liệu duy nhất có thể chỉnh sửa.

Lớp API ba tầng (REST, GraphQL, Local)

Đây là điểm mà Payload thực sự vượt trội hơn mọi CMS mã nguồn mở khác. Bạn có ba cách để truy vấn nội dung, mỗi cách được tối ưu hóa cho các ngữ cảnh khác nhau:

• Local API: Truy vấn phía server với chi phí HTTP bằng không. Gọi CMS của bạn trực tiếp trong các server component của Next.js. Không có vòng lặp mạng, không có chi phí tuần tự hóa. Trong quá trình thử nghiệm, Local API đã giảm thời gian tải trang xuống khoảng ~40ms so với các lệnh gọi REST trên cùng một server.
• REST API: Các endpoint tự động tạo cho các client bên ngoài, ứng dụng di động hoặc tích hợp bên thứ ba.
• GraphQL API: Các truy vấn linh hoạt cho các frontend cần định hình chính xác yêu cầu dữ liệu của họ.

Dưới đây là cách một lệnh gọi Local API trông như thế nào trong một server component của 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>
}

Không có lệnh fetch. Không có URL API. Không có token xác thực. Bạn đang truy vấn cơ sở dữ liệu của mình trực tiếp từ một server component, và TypeScript cung cấp cho bạn độ an toàn kiểu dữ liệu đầy đủ trên phản hồi. Điều này thật khó để đánh bại.

Kiểm soát truy cập & Xác thực

Hệ thống kiểm soát truy cập của Payload dựa trên hàm. Thay vì cấu hình quyền trong dashboard, bạn viết các hàm TypeScript trả về true hoặc false. Ở cấp độ trường, cấp độ collection hoặc cấp độ thao tác, bạn quyết định mức độ chi tiết.

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

Xác thực được tích hợp sẵn: token JWT, refresh tokens, quy trình quên mật khẩu, xác minh email. Bạn không cần Clerk hay NextAuth trừ khi bạn thực sự muốn dùng chúng. Đối với nhiều dự án, khả năng xác thực của Payload là quá đủ.

Trình soạn thảo Rich Text Lexical

Payload sử dụng Lexical, framework rich text của Meta (cùng đội ngũ đứng sau Draft.js, nhưng tốt hơn). Bạn có thể thêm các khối tùy chỉnh, phần tử inline và lệnh slash. Trình soạn thảo tuần tự hóa sang định dạng JSON có cấu trúc mà bạn có thể chuyển đổi thành HTML hoặc các component React.

Điều này quan trọng vì hầu hết các trình soạn thảo rich text của CMS hoặc là quá cơ bản (textarea thuần) hoặc quá mơ hồ (WYSIWYG tạo ra HTML không thể đoán trước). Lexical cung cấp cho bạn đầu ra có cấu trúc, dễ dự đoán và bạn kiểm soát hoàn toàn.

Live Preview & Chỉnh sửa trực quan

Payload 3 đi kèm với live preview: biên tập viên thấy các thay đổi nội dung của họ được phản ánh trên frontend thực tế theo thời gian thực, hiển thị cạnh bảng điều khiển admin. Đây là một điểm cộng lớn so với Strapi, vốn hoàn toàn không có chỉnh sửa trực quan.

Nó chưa thực sự bóng bẩy như các tính năng cộng tác thời gian thực của Sanity Studio — chỉnh sửa trực quan của Sanity thực sự là tốt nhất trong ngành. Nhưng đối với các đội nhóm cần xem trước trực quan "đủ tốt" mà không phải trả giá theo số lượng người dùng của Sanity, thì cách triển khai của Payload vẫn đáp ứng được nhu cầu.

Phiên bản, Bản nháp & Tự động lưu

Payload bao gồm quản lý bản nháp tích hợp, lịch sử phiên bản và tự động lưu — những tính năng mà không có hướng dẫn nào về Payload xếp hạng cao đề cập đến. Bạn có thể bật tính năng phiên bản cho từng collection (chúng tôi đã làm điều này trong ví dụ Posts ở trên với versions: { drafts: true }), đặt số lượng phiên bản tối đa và so sánh các bản sửa đổi trong giao diện admin.

Đối với các đội biên tập, điều này có nghĩa là không còn thảm họa "tôi lỡ tay xuất bản bản nháp". Đối với nhà phát triển, điều này có nghĩa là bạn không cần phải gắn thêm một hệ thống phiên bản riêng biệt.

Bắt đầu với Payload CMS

Để bắt đầu một dự án Payload mới, hãy chạy npx create-payload-app@latest, chọn một template (website hoặc trống), chọn adapter cơ sở dữ liệu của bạn (PostgreSQL, MongoDB hoặc SQLite), và bạn sẽ có một bảng điều khiển admin hoạt động tại localhost:3000/admin trong chưa đầy hai phút. Hướng dẫn cài đặt chính thức bao gồm các trường hợp đặc biệt.

Cài đặt

Bạn cần Node.js 18+ và một trình quản lý gói. Chỉ vậy thôi.

# 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

Template website là điểm khởi đầu tốt nhất cho hầu hết các dự án, nó đi kèm với một blog hoạt động, collection pages, tải lên media và một frontend. Template trống dành cho khi bạn muốn xây dựng từ đầu.

Cấu trúc dự án

Sau khi cài đặt, dự án của bạn trông giống như một ứng dụng Next.js tiêu chuẩn với Payload được tích hợp vào:

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

File payload.config.ts là trái tim của mọi thứ:

// 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 đầu tiên của bạn

Khi dev server đang chạy, hãy tạo một collection mới bằng cách thêm một file vào /collections. Payload tự động tạo giao diện admin, các endpoint API và các kiểu TypeScript từ cấu hình của bạn. Dưới đây là một collection Pages đơn giản:

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

Thêm nó vào mảng collections trong payload.config.ts của bạn, khởi động lại dev server, và bạn đã có một công cụ xây dựng trang hoàn chỉnh với giao diện admin trực quan. Không cần plugin, không cần tải xuống từ marketplace.

Tùy chọn Cơ sở dữ liệu: Postgres, MongoDB & SQLite

Payload hỗ trợ ba adapter cơ sở dữ liệu: PostgreSQL (khuyến nghị cho production), MongoDB (cho các mô hình nặng về tài liệu hoặc các stack Mongo hiện có) và SQLite (chỉ dành cho phát triển cục bộ và tạo mẫu). Mẫu adapter có nghĩa là mã ứng dụng của bạn giữ nguyên bất kể bạn chọn cơ sở dữ liệu nào.

Nếu bạn bắt đầu từ đầu, hãy chọn PostgreSQL. Nó xử lý dữ liệu quan hệ tốt hơn (và hầu hết dữ liệu CMS là quan hệ), có các tùy chọn serverless tuyệt vời thông qua Neon và Supabase, và đây là lựa chọn mà đội ngũ Payload khuyến nghị. Hãy xem so sánh PostgreSQL vs MySQL của chúng tôi để hiểu thêm về lý do tại sao Postgres thống trị phát triển ứng dụng hiện đại.

Mẹo chuyên nghiệp: Nếu bạn triển khai lên Vercel, hãy kết hợp Payload với Neon Postgres. Cơ chế connection pooling của Neon xử lý mượt mà các cold start serverless, điều này rất quan trọng vì Vercel liên tục khởi tạo các instance function mới.

Thương vụ mua lại của Figma: Ý nghĩa đối với Nhà phát triển

Figma đã mua lại Payload vào tháng 6 năm 2025. Giấy phép MIT và codebase mã nguồn mở vẫn không thay đổi. Payload Cloud tạm dừng đăng ký mới trong khi đội ngũ xây dựng giải pháp thay thế, nhưng việc tự host không bị ảnh hưởng. Đối với các nhà phát triển, câu hỏi lớn nhất không phải là "Payload đã chết chưa?", mà là "tôi phải làm gì với hosting?"

Chúng tôi đang theo dõi Payload Cloud như một tùy chọn hosting cho một dự án khách hàng khi thương vụ mua lại được công bố. Dưới đây là những gì chúng tôi học được khi chuyển sang tự host, và ý nghĩa thực sự của thương vụ này đối với các dự án của bạn.

Vào ngày 17 tháng 6 năm 2025, Figma đã thông báo việc mua lại trên blog của họ. Đội ngũ Payload đã xuất bản thông báo của riêng họ cùng ngày. Toàn bộ đội ngũ Payload đã được sáp nhập vào Figma.

Những gì thay đổi (Và những gì không)

Những gì giữ nguyên:

• Giấy phép MIT. Điều này không thể bị thu hồi. Kho lưu trữ GitHub vẫn hoạt động và mở cửa cho các đóng góp từ cộng đồng.
• Codebase. Payload 3 hoạt động chính xác như trước khi bị mua lại.
• Tự host. Bạn có thể triển khai Payload ở bất cứ đâu, mãi mãi.

Những gì đã thay đổi:

• Payload Cloud tạm dừng đăng ký mới. Khách hàng hiện tại có thể tiếp tục, nhưng các dự án mới không thể sử dụng dịch vụ hosting được quản lý của Payload.
• Trọng tâm đội ngũ đã thay đổi. Đội ngũ Payload hiện đang xây dựng thứ có khả năng sẽ trở thành "Figma CMS", thu hẹp khoảng cách giữa thiết kế Figma và nội dung trực tiếp. Các chi tiết còn mang tính suy đoán, nhưng hướng đi là rõ ràng.
• Sự chú ý của cộng đồng. Một số nhà phát triển lo ngại về kịch bản "mua lại rồi bỏ rơi" thường gặp ở các dự án mã nguồn mở. Giấy phép MIT giảm thiểu rủi ro worst-case, nhưng đó vẫn là mối quan tâm chính đáng.

Bạn có nên chọn Payload nữa không?

Thành thật mà nói? Có, với một số lưu ý.

Điểm tốt: Nguồn lực của Figma có nghĩa là có thêm nhân tài kỹ thuật đằng sau dự án. Giấy phép MIT có nghĩa là trường hợp xấu nhất là bạn fork nó. Codebase đã trưởng thành, được ghi chép đầy đủ và đang được sử dụng tích cực trong production bởi hàng nghìn dự án.

Điểm đáng lo ngại: Động lực của Figma có thể dần tách rời khỏi nhu cầu của cộng đồng mã nguồn mở theo thời gian. Khoảng trống của Payload Cloud buộc bạn phải tự lo hosting. Và nếu bạn ngại rủi ro, sự không chắc chắn về hướng đi dài hạn là có thật.

Quan điểm của chúng tôi: nếu bạn thoải mái với việc tự host (bạn nên như vậy, nó không khó), Payload vẫn là headless CMS mã nguồn mở, code-first tốt nhất hiện có. Đừng chờ đợi "Figma CMS." Hãy xây dựng với Payload 3 ngay hôm nay, tự host và tiếp tục công việc.

Cách triển khai Payload CMS vào năm 2026

Với việc Payload Cloud tạm dừng đăng ký mới, các tùy chọn triển khai chính của bạn vào năm 2026 là: Vercel (cài đặt nhanh nhất, lưu ý cold starts), Docker trên VPS (tốt nhất cho biên tập viên hoạt động tích cực, 7-45 EUR/tháng), Railway/Render/Fly.io (container được quản lý) hoặc Cloudflare Workers (rẻ nhất khoảng $5-10/tháng). Theo tài liệu triển khai của Payload, bất kỳ hosting Node.js nào hỗ trợ Next.js đều sẽ hoạt động.

Chúng tôi đã triển khai Payload lên cả Vercel và VPS dựa trên Docker. Đây là điều khiến chúng tôi bất ngờ: Cold starts của Vercel làm cho bảng điều khiển admin trở nên chậm chạp đối với các biên tập viên chỉ đăng nhập vài lần mỗi tuần. VPS, mặc dù yêu cầu thiết lập nhiều hơn, lại cung cấp trải nghiệm biên tập ổn định và tốt hơn.

Vercel (Cài đặt nhanh nhất)

Triển khai một cú nhấp chuột với Neon Postgres và Vercel Blob để tải lên file. Con đường nhanh nhất đến production.

Ưu điểm: Không cần quản lý hạ tầng, CDN tuyệt vời, phù hợp cho các trang web có hoạt động biên tập nhẹ. Nhược điểm: Cold starts bảng điều khiển admin (3-5 giây sau khi không hoạt động), cạn kiệt kết nối Postgres dưới các truy vấn nặng, giới hạn timeout 10 giây có thể phá vỡ các thao tác hàng loạt. Phù hợp nhất cho: Trang marketing, portfolio, blog với tần suất chỉnh sửa thấp.

Để hiểu thêm về điểm mạnh và hạn chế của Vercel, hãy xem so sánh Vercel vs Netlify của chúng tôi.

Docker trên VPS (Tốt nhất cho Production)

Thiết lập Docker Compose trên Hetzner, DigitalOcean hoặc AWS EC2. Điều này phù hợp với kiến trúc của Payload hơn là serverless vì Payload mong đợi một tiến trình server liên tục.

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

Ưu điểm: Server liên tục (không có cold starts), chi phí dự đoán được (7-45 EUR/tháng trên Hetzner), kiểm soát hoàn toàn stack. Nhược điểm: Bạn phải quản lý server, SSL, sao lưu và cập nhật. Phù hợp nhất cho: Agency, đội biên tập tích cực, thiết lập multi-tenant, ứng dụng có usage admin nặng.

Một so sánh hosting chi tiết từ Build with Matija bao gồm các nhà cung cấp VPS và cấu hình bổ sung.

Container được quản lý (Railway, Render, Fly.io)

Nếu Docker trên VPS nghe có vẻ như quá nhiều công việc vận hành, các nền tảng container được quản lý sẽ là giải pháp trung gian. Railway đặc biệt phổ biến trong cộng đồng Payload, họ có một template Payload triển khai chỉ với một cú nhấp chuột.

Hãy xem so sánh Railway vs Render vs Fly.io của chúng tôi để tìm hiểu sâu hơn về các nền tảng này.

Phù hợp nhất cho: Các đội nhóm muốn server liên tục mà không cần trực tiếp quản lý hạ tầng.

Cloudflare Workers (Rẻ nhất)

Tùy chọn mới nhất. Payload đã thêm adapter Cloudflare Workers chạy trên các edge function với D1 (SQLite) hoặc Hyperdrive (proxy Postgres). Vẫn còn hơi mang tính thử nghiệm, nhưng chi phí thì không thể bàn cãi: ~$5-10/tháng cho hầu hết các dự án.

Phù hợp nhất cho: Dự án phụ, trang cá nhân, triển khai tiết kiệm ngân sách nơi bạn thoải mái với hạ tầng mới hơn, ít được kiểm chứng hơn.

Kết luận của chúng tôi: Đối với hầu hết các dự án Payload production có biên tập viên hoạt động tích cực, Docker trên VPS là lựa chọn mặc định tốt nhất. Nó rẻ hơn bạn nghĩ, loại bỏ vấn đề cold start và cho bạn toàn quyền kiểm soát. Chỉ sử dụng Vercel nếu biên tập viên của bạn hiếm khi đăng nhập và bạn muốn giảm thiểu hoàn toàn công việc vận hành.

Giá cả Payload CMS: Chi phí thực tế là bao nhiêu?

Bản thân Payload miễn phí và có giấy phép MIT. Chi phí thực sự của bạn là hosting và (tùy chọn) phát triển chuyên nghiệp. Dưới đây là con số thực tế, dựa trên các thiết lập thực tế và phân tích giá từ Build with Matija.

Để so sánh: Gói Team của Contentful bắt đầu từ $300/tháng. Gói Team của Sanity là $99/tháng mỗi dự án. Strapi Cloud bắt đầu từ $29/tháng. Chi phí phần mềm $0 của Payload cộng với hosting $7-25/tháng rất khó để chối từ, đặc biệt đối với các agency xây dựng dự án cho khách hàng nơi giá theo số lượng người dùng làm giảm biên lợi nhuận.

Payload vs Sanity vs Strapi vs Contentful: So sánh nhanh

Chọn Payload nếu bạn muốn kiểm soát code-first và tự host. Chọn Sanity để có trải nghiệm chỉnh sửa trực quan tốt nhất và cộng tác thời gian thực. Chọn Strapi để có bảng điều khiển admin nhanh chóng với hệ sinh thái plugin. Chọn Contentful cho hạ tầng cấp doanh nghiệp với đảm bảo SLA. Chúng tôi sử dụng Sanity cho techsy.io, nên chúng tôi có kinh nghiệm trực tiếp so sánh các nền tảng này.

Chúng tôi đã xây dựng các dự án dựa trên Payload cho khách hàng cần quyền sở hữu dữ liệu và tự host, và chúng tôi vận hành pipeline nội dung của riêng mình trên Sanity. Cả hai đều xuất sắc, lựa chọn đúng phụ thuộc vào mức độ thoải mái kỹ thuật và sở thích hosting của đội nhóm bạn. Nếu bạn đang đánh giá các tùy chọn headless CMS cho một dự án, chúng tôi có thể giúp bạn lựa chọn.

Để tìm hiểu sâu hơn về từng nền tảng, hãy xem các hướng dẫn của chúng tôi: headless CMS tốt nhất năm 2026, và các hướng dẫn riêng cho Sanity, Strapi và Contentful sẽ sớm ra mắt.

Khi nào KHÔNG nên sử dụng Payload CMS

Bỏ qua Payload nếu đội nhóm của bạn không chuyên về kỹ thuật và cần GUI giống WordPress, nếu bạn cần hosting cloud được quản lý ngay lập tức mà không cần công sức tự host, nếu biên tập viên của bạn muốn chỉnh sửa trực quan ở mức độ Sanity Studio, hoặc nếu bạn cần marketplace plugin để mở rộng tính năng nhanh chóng. Thành thật về hạn chế xây dựng niềm tin hơn là giả vờ chúng không tồn tại.

Chúng tôi đã khuyên không dùng Payload cho các khách hàng có đội biên tập hoàn toàn không có kinh nghiệm TypeScript. Dưới đây là khi nào bạn nên tìm giải pháp khác:

• Đội nhóm không chuyên về kỹ thuật. Payload yêu cầu kiến thức TypeScript để cấu hình. Nếu biên tập viên của khách hàng không thể động vào code và cần tự sửa đổi mô hình nội dung, WordPress hoặc Sanity phù hợp hơn.
• Bạn cần hosting được quản lý ngay bây giờ. Với việc Payload Cloud tạm dừng đăng ký mới, bạn phải tự host. Nếu việc quản lý server (ngay cả thiết lập Docker đơn giản) là điều không thể chấp nhận được, cách tiếp cận cloud-hosted của Contentful hoặc Sanity sẽ loại bỏ gánh nặng đó.
• Cộng tác biên tập nặng nề. Khả năng cộng tác thời gian thực của Sanity Studio, nhiều biên tập viên làm việc trên cùng một tài liệu cùng lúc với chỉ báo trạng thái, bóng bẩy hơn bất cứ thứ gì Payload cung cấp. Nếu bạn có một đội biên tập lớn, Sanity thắng ở điểm này.
• Phát triển dựa trên plugin. Strapi có marketplace plugin lớn hơn. Cần plugin SEO, trình tạo sitemap, tích hợp email? Strapi có lẽ đã có sẵn. Hệ sinh thái của Payload đang phát triển nhưng nhỏ hơn.
• Bạn không sử dụng Next.js. Payload 3 gắn liền về mặt kiến trúc với Next.js. Nếu frontend của bạn là Astro, Remix, Nuxt hoặc SvelteKit, lợi thế lớn nhất của Payload (Local API trong server components) không còn áp dụng. Bạn vẫn sẽ có REST và GraphQL, nhưng ở điểm đó, Strapi hoặc Directus có thể cảm thấy tự nhiên hơn.

FAQ

Payload CMS là gì và nó hoạt động như thế nào?

Payload là một headless CMS và framework ứng dụng mã nguồn mở, native TypeScript được xây dựng trên Next.js. Bạn định nghĩa mô hình nội dung trong các file cấu hình TypeScript, và Payload tự động tạo ra bảng điều khiển admin, REST API, GraphQL API và Local API. Nó chạy bên trong ứng dụng Next.js của bạn như một đơn vị triển khai duy nhất.

Payload CMS có miễn phí sử dụng không?

Payload hoàn toàn miễn phí theo giấy phép MIT. Phần mềm không tốn phí để tải xuống, sử dụng hoặc sửa đổi. Payload Cloud (hosting được quản lý) có giá $35-199/tháng nhưng hiện đã tạm dừng đăng ký mới sau thương vụ mua lại của Figma. Tự host trên VPS có giá EUR 7-45/tháng tùy thuộc vào nhà cung cấp của bạn.

Chuyện gì đã xảy ra với Payload và Figma?

Figma đã mua lại Payload vào ngày 17 tháng 6 năm 2025. Toàn bộ đội ngũ Payload đã gia nhập Figma. Giấy phép MIT mã nguồn mở và kho lưu trữ GitHub vẫn không thay đổi. Payload Cloud tạm dừng đăng ký mới. Việc tự host vẫn hoạt động bình thường. Đội ngũ có khả năng đang xây dựng một sản phẩm CMS tích hợp với Figma, nhưng các chi tiết cụ thể chưa được công bố.

Payload CMS sử dụng cơ sở dữ liệu nào?

Payload hỗ trợ ba cơ sở dữ liệu thông qua mẫu adapter: PostgreSQL (khuyến nghị cho production, hoạt động với Neon và Supabase cho serverless), MongoDB (tốt cho các mô hình nặng về tài liệu hoặc nâng cấp từ Payload 2) và SQLite (chỉ dành cho phát triển cục bộ và CI). Mã ứng dụng của bạn giữ nguyên bất kể bạn chọn adapter nào.

Làm thế nào để triển khai Payload CMS vào năm 2026?

Với việc Payload Cloud tạm dừng, hãy triển khai lên Vercel với Neon Postgres (dễ nhất), Docker trên VPS như Hetzner (tốt nhất cho production với biên tập viên tích cực), Railway hoặc Render (container được quản lý), hoặc Cloudflare Workers (rẻ nhất). Đối với hầu hết các trang production có hoạt động biên tập thường xuyên, VPS dựa trên Docker cung cấp trải nghiệm tốt nhất.

Payload CMS có tốt hơn Strapi không?

Payload thắng về trải nghiệm developer native TypeScript, tích hợp Next.js và Local API độc đáo cho các truy vấn phía server không tốn chi phí. Strapi thắng về marketplace plugin, chỉnh sửa schema dựa trên GUI và khả năng tương thích framework rộng hơn. Nếu đội nhóm của bạn viết TypeScript và sử dụng Next.js, Payload là lựa chọn mạnh mẽ hơn. Nếu không, hãy đánh giá Strapi.

Local API của Payload là gì?

Local API là một lớp truy vấn phía server gọi trực tiếp cơ sở dữ liệu của bạn với chi phí HTTP bằng không. Thay vì thực hiện các lệnh gọi REST hoặc GraphQL, bạn import Payload và truy vấn các collection trực tiếp trong các server component của Next.js. Điều này loại bỏ các vòng lặp mạng và chi phí tuần tự hóa, dẫn đến tốc độ tải trang nhanh hơn. Không có headless CMS nào khác cung cấp điều này.

Payload CMS có thể xử lý các ứng dụng quy mô lớn không?

Payload hỗ trợ PostgreSQL với connection pooling (qua Neon hoặc PgBouncer), kiểm soát truy cập dựa trên vai trò với độ chi tiết đến từng trường, quy trình làm việc bản nháp và phiên bản, cũng như kiến trúc multi-tenant. Các doanh nghiệp và agency sử dụng Payload trong production cho các ứng dụng nặng về nội dung. Các truy vấn không tốn chi phí của Local API thực sự cải thiện hiệu suất ở quy mô lớn.

Payload so sánh với Sanity như thế nào?

Payload tự host, code-first, có giấy phép MIT với Local API cho hiệu suất phía server. Sanity được host trên cloud với chỉnh sửa trực quan vượt trội, cộng tác thời gian thực và ngôn ngữ truy vấn GROQ. Payload cho bạn nhiều quyền kiểm soát hạ tầng hơn và chi phí thấp hơn. Sanity cung cấp công cụ biên tập tốt hơn và không cần quản lý hosting.

Nhược điểm của Payload CMS là gì?

Payload yêu cầu kiến thức TypeScript để cấu hình, không có hosting cloud được quản lý cho người dùng mới kể từ khi Figma mua lại, hệ sinh thái plugin nhỏ hơn Strapi và gắn liền về mặt kiến trúc với Next.js trong phiên bản 3. Các đội nhóm không chuyên về kỹ thuật có thể gặp khó khăn với cách tiếp cận code-first, và thương vụ mua lại của Figma tạo ra một số bất định dài hạn.