Payload CMS 2026: Why Figma Bought It (And Should You Adopt It?)

Payload CMS 2026: Why Figma Bought It (And Should You Adopt It?)

Payload is an open-source, TypeScript-native headless CMS that lives inside your Next.js app, not alongside it, not in a separate container, but literally in the same /app folder. If you've been burned by hosted CMS platforms that charge per seat or lock your content behind proprietary APIs, Payload is worth a serious look.

But 2026 brought a curveball: Figma acquired Payload, Payload Cloud paused new sign-ups, and developers suddenly need to figure out hosting on their own. This guide covers everything from first install to production deployment, with current Payload 3 code examples and honest takes on where Payload shines and where it doesn't.

What Is Payload CMS? (And Why Developers Love It)

Payload is an open-source, TypeScript-native headless CMS and application framework that runs inside your Next.js app. Unlike hosted CMS platforms, Payload gives you a code-first config, three built-in APIs (REST, GraphQL, Local), and a fully customizable admin panel, all from a single codebase. According to the official Payload documentation, it's designed to be "the best way to build a modern backend."

The project started in 2021 as a Node.js/Express CMS. Payload 2 arrived in 2023 with improved TypeScript support. Then Payload 3 changed the game entirely: the CMS moved inside your Next.js application. No separate server process. No separate deployment. Your CMS and your frontend share the same Next.js runtime, the same routes, the same build pipeline.

That's a genuinely different architecture than what Sanity, Strapi, or Contentful offer. And it has real consequences for how you build, deploy, and think about your content layer.

The Code-First Philosophy

Most CMS platforms give you a GUI to define your content model. Click "add field," choose "text," name it "title." Payload flips this: you define everything in TypeScript files. Your schema is code. It lives in version control. You review it in pull requests.

This means no schema drift between environments, no "someone changed the content model in staging and nobody knows what happened" surprises. If you've worked on a team where the content model lived in a cloud dashboard, you know exactly why this matters.

Payload 3 Architecture, Next.js Native

Payload 3 doesn't run beside your Next.js app. It runs inside it. The admin panel sits at /app/(payload)/admin, your API routes live in /app/(payload)/api, and your frontend pages coexist in the same project. If you've used Next.js in production before, you'll feel right at home.

Key Features That Set Payload Apart

Payload's standout features include Collections for content modeling, a triple-API layer (REST, GraphQL, Local), role-based access control with field-level granularity, built-in authentication, the Lexical rich text editor, and live preview for visual editing. Here's what each of these actually means for your codebase.

Collections, Globals & Fields

Collections are Payload's core content modeling primitive. Think of them like database tables, but defined entirely in TypeScript. Each Collection gets its own REST and GraphQL endpoints, its own admin panel view, and its own access control rules, all generated from a single config file.

// 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 work similarly but for singleton data, your site settings, navigation config, footer content. One instance, no collection list view, just a single editable document.

The Triple API Layer (REST, GraphQL, Local)

This is where Payload genuinely outshines every other open-source CMS. You get three ways to query your content, each optimized for different contexts:

• Local API: Server-side queries with zero HTTP overhead. Call your CMS directly in Next.js server components. No network round-trip, no serialization cost. In our testing, the Local API reduced page load times by ~40ms compared to REST calls on the same server.
• REST API: Auto-generated endpoints for external clients, mobile apps, or third-party integrations.
• GraphQL API: Flexible queries for frontends that need to shape their data requests precisely.

Here's what a Local API call looks like in a Next.js server component:

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

No fetch call. No API URL. No authentication token. You're querying your database directly from a server component, and TypeScript gives you full type safety on the response. That's hard to beat.

Access Control & Authentication

Payload's access control system is function-based. Instead of configuring permissions in a dashboard, you write TypeScript functions that return true or false. Field-level, collection-level, or operation-level, you decide the granularity.

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

Authentication comes built-in: JWT tokens, refresh tokens, forgot-password flow, email verification. You don't need Clerk or NextAuth unless you specifically want them. For many projects, Payload's auth is more than enough.

Lexical Rich Text Editor

Payload uses Lexical, Meta's rich text framework (the same team behind Draft.js, but better). You can add custom blocks, inline elements, and slash commands. The editor serializes to a structured JSON format that you can convert to HTML or React components.

This matters because most CMS rich text editors are either too basic (plain textarea) or too opaque (WYSIWYG that generates unpredictable HTML). Lexical gives you a structured, predictable output that you control entirely.

Live Preview & Visual Editing

Payload 3 ships with live preview: editors see their content changes reflected on the actual frontend in real time, side-by-side with the admin panel. This is a significant gap-filler compared to Strapi, which has no visual editing at all.

It's not quite as polished as Sanity Studio's real-time collaboration features, Sanity's visual editing is genuinely best-in-class. But for teams that need "good enough" visual preview without paying Sanity's per-seat pricing, Payload's implementation gets the job done.

Versioning, Drafts & Autosave

Payload includes built-in draft management, version history, and autosave, features that zero of the top-ranking Payload guides even mention. You can enable versioning per collection (we did it in the Posts example above with versions: { drafts: true }), set a max version count, and compare revisions in the admin UI.

For editorial teams, this means no more "I accidentally published a draft" disasters. For developers, it means you don't need to bolt on a separate versioning system.

Getting Started with Payload CMS

To start a new Payload project, run npx create-payload-app@latest, select a template (website or blank), choose your database adapter (PostgreSQL, MongoDB, or SQLite), and you'll have a working admin panel at localhost:3000/admin in under two minutes. The official installation guide covers edge cases.

Installation

You need Node.js 18+ and a package manager. That's it.

# 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

The website template is the best starting point for most projects, it ships with a working blog, pages collection, media uploads, and a frontend. The blank template is for when you want to build from scratch.

Project Structure

After installation, your project looks like a standard Next.js app with Payload sprinkled in:

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

The payload.config.ts file is the heart of everything:

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

Your First Collection

Once the dev server is running, create a new collection by adding a file to /collections. Payload auto-generates the admin UI, API endpoints, and TypeScript types from your config. Here's a simple 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' },
          ],
        },
      ],
    },
  ],
}

Add it to your payload.config.ts collections array, restart the dev server, and you've got a fully functional page builder with a visual admin interface. No plugins, no marketplace downloads.

Database Options, Postgres, MongoDB & SQLite

Payload supports three database adapters: PostgreSQL (recommended for production), MongoDB (for document-heavy models or existing Mongo stacks), and SQLite (for local development and prototyping only). The adapter pattern means your application code stays the same regardless of which database you choose.

If you're starting fresh, go with PostgreSQL. It handles relational data better (and most CMS data is relational), has excellent serverless options through Neon and Supabase, and is what the Payload team recommends. Check our PostgreSQL vs MySQL comparison for more context on why Postgres dominates modern app development.

Pro tip: If you're deploying to Vercel, pair Payload with Neon Postgres. Neon's connection pooling handles serverless cold starts gracefully, which matters because Vercel spins up new function instances constantly.

The Figma Acquisition, What It Means for Developers

Figma acquired Payload in June 2025. The MIT license and open-source codebase remain unchanged. Payload Cloud paused new sign-ups while the team builds a replacement, but self-hosting is unaffected. For developers, the biggest question isn't "is Payload dead?", it's "what do I do about hosting?"

We were tracking Payload Cloud as a hosting option for a client project when the acquisition was announced. Here's what we learned from pivoting to self-hosting, and what the acquisition actually means for your projects.

On June 17, 2025, Figma announced the acquisition on their blog. The Payload team published their own announcement the same day. The entire Payload team was absorbed into Figma.

What Changed (And What Didn't)

What stays the same:

• MIT license. This cannot be revoked. The GitHub repository remains active and open to community contributions.
• The codebase. Payload 3 works exactly as it did before the acquisition.
• Self-hosting. You can deploy Payload anywhere, forever.

What changed:

• Payload Cloud paused new sign-ups. Existing customers can continue, but new projects can't use Payload's managed hosting.
• Team focus shifted. The Payload team is now building what will likely become "Figma CMS", bridging the gap between Figma designs and live content. The specifics are speculative, but the direction is clear.
• Community attention. Some developers worry about the "acquired-then-abandoned" pattern that plagues open-source projects. The MIT license mitigates the worst-case scenario, but it's a legitimate concern.

Should You Still Choose Payload?

Honestly? Yes, with caveats.

The good: Figma's resources mean more engineering talent behind the project. The MIT license means the worst case is you fork it. The codebase is mature, well-documented, and actively used in production by thousands of projects.

The concerning: Figma's incentives may diverge from the open-source community's needs over time. The Payload Cloud gap forces you to handle hosting yourself. And if you're risk-averse, the uncertainty around long-term direction is real.

Our take: if you're comfortable self-hosting (which you should be, it's not hard), Payload remains the best open-source, code-first headless CMS available. Don't wait for "Figma CMS." Build with Payload 3 today, self-host, and move on.

How to Deploy Payload CMS in 2026

With Payload Cloud paused for new sign-ups, your main deployment options in 2026 are: Vercel (fastest setup, watch for cold starts), Docker on a VPS (best for active editors, EUR 7-45/mo), Railway/Render/Fly.io (managed containers), or Cloudflare Workers (cheapest at ~$5-10/mo). According to Payload's deployment docs, any Node.js hosting that supports Next.js will work.

We've deployed Payload to both Vercel and a Docker-based VPS. Here's what surprised us: Vercel's cold starts made the admin panel sluggish for editors who only logged in a few times per week. The VPS, despite requiring more setup, provided a consistently better editorial experience.

Vercel (Fastest Setup)

One-click deploy with Neon Postgres and Vercel Blob for file uploads. Fastest path to production.

Pros: Zero infrastructure management, excellent CDN, great for sites with light editorial activity. Cons: Admin panel cold starts (3-5 seconds after inactivity), Postgres connection exhaustion under heavy queries, 10-second timeout ceiling can break bulk operations. Best for: Marketing sites, portfolios, blogs with infrequent editing.

For more context on Vercel's strengths and limitations, see our Vercel vs Netlify comparison.

Docker on a VPS (Best for Production)

A Docker Compose setup on Hetzner, DigitalOcean, or AWS EC2. This matches Payload's architecture better than serverless because Payload expects a persistent server process.

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

Pros: Persistent server (no cold starts), predictable costs (EUR 7-45/mo on Hetzner), full control over the stack. Cons: You manage the server, SSL, backups, and updates. Best for: Agencies, active editorial teams, multi-tenant setups, apps with heavy admin usage.

A detailed hosting comparison from Build with Matija covers additional VPS providers and configurations.

Managed Containers (Railway, Render, Fly.io)

If Docker on a VPS sounds like too much ops work, managed container platforms split the difference. Railway is particularly popular in the Payload community, they have a Payload template that deploys in one click.

Check our Railway vs Render vs Fly.io comparison for a deeper look at these platforms.

Best for: Teams that want persistent servers without managing infrastructure directly.

Cloudflare Workers (Cheapest)

The newest option. Payload added a Cloudflare Workers adapter that runs on edge functions with D1 (SQLite) or Hyperdrive (Postgres proxy). Still experimental-ish, but the cost can't be beat: ~$5-10/mo for most projects.

Best for: Side projects, personal sites, budget-conscious deploys where you're comfortable with newer, less-tested infrastructure.

Our verdict: For most production Payload projects with active editors, Docker on a VPS is the best default. It's cheaper than you'd think, eliminates cold start issues, and gives you full control. Use Vercel only if your editors are infrequent and you want zero ops overhead.

Payload CMS Pricing, What It Actually Costs

Payload itself is free and MIT-licensed. Your real costs are hosting and (optionally) professional development. Here's what the numbers actually look like, based on real-world setups and the pricing breakdown from Build with Matija.

For comparison: Contentful's Team plan starts at $300/mo. Sanity's Team plan is $99/mo per project. Strapi Cloud starts at $29/mo. Payload's $0 software cost plus $7-25/mo hosting is hard to argue with, especially for agencies building client projects where per-seat pricing kills margins.

Payload vs Sanity vs Strapi vs Contentful, Quick Comparison

Choose Payload if you want code-first control and self-hosting. Choose Sanity for the best visual editing and real-time collaboration. Choose Strapi for a quick admin panel with plugin ecosystem. Choose Contentful for enterprise-grade infrastructure with SLA guarantees. We use Sanity for techsy.io, so we have first-hand experience comparing these platforms.

We've built Payload-based projects for clients who need data ownership and self-hosting, and we run our own content pipeline on Sanity. Both are excellent, the right choice depends on your team's technical comfort and hosting preferences. If you're evaluating headless CMS options for a project, we can help you choose.

For deeper dives on each platform, check our guides: best headless CMS in 2026, and individual guides for Sanity, Strapi, and Contentful coming soon.

When NOT to Use Payload CMS

Skip Payload if your team is non-technical and needs a WordPress-like GUI, if you need instant managed cloud hosting without self-hosting work, if your editors want Sanity Studio-level visual editing, or if you need a plugin marketplace for rapid feature expansion. Being honest about limitations builds more trust than pretending they don't exist.

We've recommended against Payload for clients whose editorial teams had zero TypeScript experience. Here's when you should look elsewhere:

• Non-technical teams. Payload requires TypeScript knowledge to configure. If your client's editors can't touch code and need to modify the content model themselves, WordPress or Sanity are better fits.
• You need managed hosting right now. With Payload Cloud paused for new sign-ups, you must self-host. If managing a server (even a simple Docker setup) is a dealbreaker, Contentful or Sanity's cloud-hosted approach removes that burden.
• Heavy editorial collaboration. Sanity Studio's real-time collaboration, multiple editors working on the same document simultaneously with presence indicators, is more polished than anything Payload offers. If you have a large editorial team, Sanity wins here.
• Plugin-driven development. Strapi has a larger plugin marketplace. Need a SEO plugin, a sitemap generator, an email integration? Strapi probably has one. Payload's ecosystem is growing but smaller.
• You're not using Next.js. Payload 3 is architecturally tied to Next.js. If your frontend is Astro, Remix, Nuxt, or SvelteKit, Payload's biggest advantage (the Local API in server components) doesn't apply. You'd still get REST and GraphQL, but at that point, Strapi or Directus might feel more natural.

FAQ

What is Payload CMS and how does it work?

Payload is an open-source, TypeScript-native headless CMS and application framework built on Next.js. You define your content model in TypeScript config files, and Payload generates an admin panel, REST API, GraphQL API, and Local API automatically. It runs inside your Next.js app as a single deployable unit.

Is Payload CMS free to use?

Payload is completely free under the MIT license. The software costs nothing to download, use, or modify. Payload Cloud (managed hosting) was $35-199/mo but is currently paused for new sign-ups following the Figma acquisition. Self-hosting on a VPS costs EUR 7-45/mo depending on your provider.

What happened with Payload and Figma?

Figma acquired Payload on June 17, 2025. The entire Payload team joined Figma. The open-source MIT license and GitHub repository remain unchanged. Payload Cloud paused new sign-ups. Self-hosting continues to work normally. The team is likely building a Figma-integrated CMS product, but specifics haven't been announced.

What database does Payload CMS use?

Payload supports three databases through an adapter pattern: PostgreSQL (recommended for production, works with Neon and Supabase for serverless), MongoDB (good for document-heavy models or Payload 2 upgrades), and SQLite (local development and CI only). Your application code stays the same regardless of which adapter you choose.

How do I deploy Payload CMS in 2026?

With Payload Cloud paused, deploy to Vercel with Neon Postgres (easiest), Docker on a VPS like Hetzner (best for production with active editors), Railway or Render (managed containers), or Cloudflare Workers (cheapest). For most production sites with regular editorial activity, a Docker-based VPS provides the best experience.

Is Payload CMS better than Strapi?

Payload wins on TypeScript-native developer experience, Next.js integration, and the unique Local API for zero-overhead server-side queries. Strapi wins on its plugin marketplace, GUI-based schema editing, and broader framework compatibility. If your team writes TypeScript and uses Next.js, Payload is the stronger choice. Otherwise, evaluate Strapi.

What is Payload's Local API?

The Local API is a server-side query layer that calls your database directly with zero HTTP overhead. Instead of making REST or GraphQL calls, you import Payload and query collections directly in Next.js server components. This eliminates network round-trips and serialization costs, resulting in faster page loads. No other headless CMS offers this.

Can Payload CMS handle large-scale applications?

Payload supports PostgreSQL with connection pooling (via Neon or PgBouncer), role-based access control with field-level granularity, draft and versioning workflows, and multi-tenant architectures. Enterprises and agencies use Payload in production for content-heavy applications. The Local API's zero-overhead queries actually improve performance at scale.

How does Payload compare to Sanity?

Payload is self-hosted, code-first, and MIT-licensed with a Local API for server-side performance. Sanity is cloud-hosted with superior visual editing, real-time collaboration, and GROQ query language. Payload gives you more infrastructure control and lower costs. Sanity gives you better editorial tooling and zero hosting management.

What are the disadvantages of Payload CMS?

Payload requires TypeScript knowledge for configuration, has no managed cloud hosting for new users since the Figma acquisition, offers a smaller plugin ecosystem than Strapi, and is architecturally tied to Next.js in version 3. Non-technical teams may struggle with the code-first approach, and the Figma acquisition creates some long-term uncertainty.