Payload

Payload was an independent company; Figma acquired the Payload team on June 17, 2025. Figma's official announcement states Payload remains open source and nothing changes for existing users in the immediate future. The Payload team is now building Figma Sites' CMS alongside continuing the open-source project.

Payload 1.0 originally launched 2018; Payload 3.0 (Next.js-native rewrite) launched December 2024.

Payload describes itself as 'the Next.js fullstack framework' - a code-first headless CMS that installs directly into a Next.js app and generates an admin panel, database layer, and REST/GraphQL APIs from a config file.

Fully open source, MIT licensed. Self-hostable anywhere Node.js runs, or via Vercel/Cloudflare instant-deploy templates.

Payload itself is free forever and fully open source (MIT) for self-hosting - no usage limits based on users, content types, or API requests. Separately, Payload Cloud offers a free 'Personal' plan for single-admin-user projects (portfolio sites, small APIs).

Payload Cloud's exact trial terms for paid tiers could not be verified from official pages - the cloud-pricing page is heavily client-rendered (React/Next.js hydration) and did not return trial-length text via automated fetch. Self-hosted use has no trial because it's free/open source.

Self-hosted Payload has no license cost (MIT, free); cheapest way to get a custom domain live is self-hosting on your own Node.js infrastructure or via Vercel/Cloudflare's Payload starter templates, both of which have their own separate hosting costs not set by Payload. Payload Cloud's paid tier pricing could not be confirmed from official sources (see typical_total_cost_notes).

Payload Cloud's specific paid-tier price points (e.g., a 'Standard' or 'Pro' cloud plan) are shown on payloadcms.com/cloud-pricing but that page renders its pricing table client-side; the numbers could not be confirmed via static fetch of the official page, and SiteVersus policy is to not cite third-party/affiliate pricing aggregators. Enterprise is confirmed custom/contact-sales.

Payload's ecommerce capability is a free, open-source plugin (@payloadcms/plugin-ecommerce) with no separate license fee; cost is whatever hosting/database/Stripe fees you incur. Not a distinct priced tier from the vendor.

No evidence of promotional intro pricing that steps up at renewal; the open-source software itself is always free. Payload Cloud's official Terms of Service state fees are invoiced on an ongoing subscription basis with no mention of introductory-vs-renewal pricing tiers.

No official money-back guarantee period found for Payload Cloud subscriptions; not applicable to the free, self-hosted open-source software.

Collections, fields, and access control are defined in a TypeScript config file; the admin panel UI is auto-generated from that config rather than built visually. An Enterprise 'Visual Editor' for in-context page editing is listed as 'Coming Soon,' not shipped.

No drag-and-drop visual page building; layout/blocks are assembled via code-defined 'Blocks' fields, then rendered by developer-written frontend components.

Content editing happens in the admin panel's form UI, not by clicking directly on the live rendered page. Live Preview shows an iframe of the frontend next to the form but edits still happen in form fields. A true click-to-edit 'Visual Editor' is listed as Enterprise/Coming Soon.

Native, per-collection-configurable versioning stores a full history of every saved document with restore/rollback via REST, GraphQL, or Local API. Configurable as versions-only, versions+drafts, or versions+drafts+autosave, with retention limits (default 100 per document, 0 = unlimited).

Autosave is an opt-in tier of the versions system (versions + drafts + autosave), configurable per collection.

No native Payload mobile app; the admin panel is a responsive web app usable in a mobile browser but there is no dedicated iOS/Android editing app documented.

N/A in the visual-builder sense - Payload has no theme/template marketplace to switch between. Frontend presentation is fully custom-coded by developers against the Payload API, so there's no vendor concept of a safe template switch.

Payload requires comfort with TypeScript, Next.js, and database concepts to set up and extend. There is no no-code path; you must write config files and build your own frontend. This is a deliberate developer-tool tradeoff, not a flaw, but it puts Payload well above hosted site builders on learning curve.

Payload is not a visual site builder and ships no design templates for end sites. It provides starter code templates (e.g., 'Website Template,' 'Ecommerce Starter Kit') that are developer boilerplates, not selectable visual themes.

N/A to Payload's own admin UI theming in the visual-builder sense, but since the frontend is fully custom-coded Next.js, any font can be used; this is a developer implementation detail, not a Payload-provided feature.

Since the frontend is hand-built Next.js/React/CSS code, developers have complete control over responsive behavior; Payload itself imposes no responsive constraints because it doesn't render the public site.

Full custom CSS since the entire frontend is developer-written code; also the admin panel itself supports CSS customization via Payload's component override system.

Full custom JavaScript/TypeScript throughout, since Payload is a code framework, not a hosted builder with restricted script injection.

Payload provides no native visual animation/interaction tooling; any animation is implemented by developers in the custom frontend code (e.g., with Framer Motion or CSS), not a Payload product feature.

Payload supports 'Globals' - singleton config documents (e.g., site-wide header/footer/theme settings) that function as design-token-like shared configuration consumed by the custom frontend.

Because Payload only supplies the backend/admin/API layer and the frontend is fully custom Next.js code, there are no template or design-system constraints imposed by the platform itself, in contrast to visual builders. This flexibility comes at the direct cost of needing developers to build the entire presentation layer.

Payload Cloud offers managed hosting (including a free Personal tier and paid tiers), and Payload also ships official one-click deploy templates for Vercel and Cloudflare that provision database/storage automatically. None of this is 'included' with the free open-source software itself unless you use Payload Cloud's free tier.

Core value proposition: self-host anywhere Node.js 20.9+ can run, using MongoDB, Postgres, or SQLite.

Not included by the open-source software itself; CDN depends on your chosen deploy target (e.g., Vercel's edge network, Cloudflare's CDN) or Payload Cloud's infrastructure. No standalone CDN ships with self-hosted Payload.

Depends entirely on hosting choice (Vercel/Cloudflare both provide free SSL by default; a bare self-host would need the operator to configure it). Not a fixed Payload platform feature to verify against official docs.

No official uptime SLA percentage found published for Payload Cloud on the pages checked (cloud-pricing and cloud-terms); Enterprise customers may negotiate SLAs via 'Talk to us' but no public figure is documented.

Payload Cloud plan-by-plan bandwidth/storage figures (e.g., GB of database or file storage per tier) are shown on the cloud-pricing page but that page's pricing table is client-rendered and its exact numbers could not be confirmed via automated fetch of the official source. Self-hosted Payload has no platform-imposed limits; storage is whatever your chosen database/object storage supports.

Payload is a server-backed application (admin panel + API + database), not a static site generator itself. However, since it's Next.js-native, the frontend you build with it can use Next.js static generation (SSG/ISR) for public pages while Payload's admin/API layer still requires a running Node.js server.

HTTP Archive's technology CWV endpoint returned an empty result set for both technology=Payload and technology=Payload CMS (cdn.httparchive.org/v1/cwv), for all ranks/geos and the latest available months. This is expected: Payload is a headless, API-only backend with no admin-panel or generated-markup fingerprint on the public-facing pages it powers, so HTTP Archive/Wappalyzer cannot attribute a live site's frontend (arbitrary custom Next.js/React code) back to 'Payload' the way it can detect a visual builder's markup signature. CWV for a Payload-powered site is really a function of how well the custom Next.js frontend is built, not of Payload itself - so this metric is structurally not meaningful for headless CMSs and should be flagged as such rather than treated as a missing data point.

Upload-enabled collections support automatic image resizing to configured imageSizes via the Sharp library, plus focal-point cropping performed before resizing. This runs server-side on upload, separate from Next.js's own next/image optimization that a developer may additionally use on the frontend.

Payload's backend/admin docs do not document a built-in lazy-loading feature for frontend images; since the public frontend is fully custom-coded Next.js, lazy loading (e.g., via next/image) is a developer implementation choice, not a Payload platform feature to verify.

As a code-first framework, developers have full control over caching (Next.js data cache, ISR revalidation, custom headers, DB query caching) since they own the entire request lifecycle; this isn't a fixed vendor dashboard toggle but genuine full control.

The official SEO plugin (@payloadcms/plugin-seo) adds a meta field group (title, description, image) to any collection/global, editable in the admin panel with character counters and a search-result preview.

Slugs are just another field in a code-defined collection; developers commonly add an editable slug field (often with an auto-generate-from-title helper), fully under content-owner control.

No dedicated redirects field ships in core, but a common official pattern/plugin approach (and Next.js middleware/redirects config) is used to manage 301s; since developers control the Next.js layer entirely, redirects are straightforward to implement, though not a single built-in admin-panel toggle out of the box.

Fully controllable since the developer writes the Next.js <head>/metadata output; Payload's SEO plugin fields (title/description/image) can feed into it directly.

robots.txt is served by the developer's Next.js app (e.g., via a robots.ts route handler or static file); fully editable since there's no Payload-imposed restriction, though it requires code not an admin toggle.

No sitemap is auto-generated by Payload core; developers implement it via Next.js's built-in sitemap.ts route convention pulling from the Payload API, or a plugin. Documented as a build-it-yourself pattern in Payload's Next.js guides rather than an automatic feature.

Payload's SEO plugin documentation notes developers can inject custom fields like json-ld into the meta group, and structured data output is implemented in the developer's Next.js templates; there's no automatic schema.org generation shipped by core Payload.

Payload's native localization system (field-level locales, RTL flag, locale query params) provides the data layer for multilingual content, but hreflang tag output itself is implemented by the developer in the Next.js frontend, not auto-generated by Payload.

The SEO plugin's meta field group includes an Open Graph image field alongside title/description, editable per collection/global entry.

Achievable via a custom field (or SEO plugin extension) plus developer-controlled Next.js metadata output; fully possible, just requires config/code rather than a single built-in checkbox in core.

Upload-enabled collections commonly include an alt text field (developer-defined, but standard practice and directly supported by Payload's field system); fully editable in the admin panel.

Payload has no pre-built 'blog' feature out of the box; a blog is implemented as a custom Collection (e.g., 'Posts') defined by the developer, using core content-modeling primitives rather than a dedicated native blog engine.

Collections and Globals are the core primitive of Payload - fully native, code-defined custom content types with a rich field library (text, richtext, relationship, blocks, array, etc.).

Categories/tags are implemented via Payload's native 'relationship' field type linking documents to a taxonomy Collection; a standard, well-documented pattern rather than a bolt-on plugin.

Combined with the drafts/versions system and custom publish-date logic (commonly via a scheduled Job or hook checking a publishAt field), content scheduling is a supported, documented pattern using Payload's Jobs Queue feature.

Native versioning with configurable retention and REST/GraphQL/Local API restore operations.

Multiple admin-panel users with code-defined roles/access control is a core supported pattern; version history tracks which user made each change.

No native RSS feed generation ships with Payload core; an RSS feed would be a developer-implemented Next.js route pulling from the Payload API, same pattern as sitemaps.

Full REST and GraphQL APIs are auto-generated from the collection/global config with complete CRUD (Find, Find By ID, Count, Create, Update, Delete) plus a Local API for direct in-process Node.js access.

Official first-party plugin (@payloadcms/plugin-ecommerce, currently in Beta) adds Products, Variants, Carts, Orders, Transactions, and Addresses collections with a Payments adapter pattern (Stripe supported out of the box).

Not restricted by product type; since products are custom-modeled Collections, digital goods (no shipping) are fully supported, just requiring developer-side fulfillment logic same as physical goods.

Official ecommerce plugin docs explicitly state subscriptions are not natively handled by the plugin; developers must build recurring billing themselves on top of the provided collections/hooks (e.g., using Stripe's own subscription APIs directly).

The ecommerce plugin documentation confirms multiple currencies are supported natively.

No point-of-sale feature or integration documented; Payload's ecommerce plugin is web/API-only.

Carts are tracked as a native collection, giving developers the raw data to build abandoned-cart recovery themselves, but no automated recovery emails/flow ship with the official plugin per its documented feature list.

Since you own and directly access the underlying database (MongoDB/Postgres/SQLite) plus a full read-write API, content export is complete and unrestricted - there's no vendor-side export gate at all because there's no vendor-hosted data silo by default.

N/A in the visual-builder sense since Payload never owns the design/frontend - the Next.js frontend code is entirely developer-owned from the start, so there is nothing proprietary to 'export'; it already lives in your own codebase.

Payload has no domain registration/locking mechanism; any domain can point to a self-hosted or Payload Cloud-hosted instance.

Core design principle - self-host anywhere Node.js runs, move between Vercel, Cloudflare, or any VPS/cloud provider freely, since Payload Cloud is optional, not required infrastructure.

Full read-write REST, GraphQL, and Local API access to all content with no vendor-imposed data ceiling.

Open source (MIT), self-hostable, direct database access, and a fully custom-owned frontend mean there is essentially no proprietary data or hosting lock-in. The main switching cost is developer time to migrate a code-first schema and rebuild against a different CMS's API shape, not vendor gatekeeping. The 2025 Figma acquisition is a governance factor worth watching but Figma has publicly committed to keeping Payload open source.

REST and GraphQL APIs are the primary way any frontend or external system interacts with Payload content.

Not a dedicated 'webhooks' config UI, but afterChange/afterDelete and other lifecycle Hooks are the documented, first-class mechanism for triggering external HTTP calls on data changes (e.g., notifying a third-party system or CDN); long-running calls can be offloaded to Payload's Jobs Queue.

Full custom code throughout since the entire application is developer-owned TypeScript/Next.js, including the admin panel's own component override system.

create-payload-app CLI scaffolds new projects; Payload also ships a migration CLI for database schema changes.

No official native Zapier or Make integration/app found in Payload's documentation; connecting to either would require building a custom webhook/API bridge via Payload's Hooks and REST API rather than a pre-built connector.

No AI full-site-generation feature in core Payload; not applicable to a headless CMS with no visual site builder. Some AI capabilities are positioned as Enterprise-tier (see ai.notable).

Listed under Payload Enterprise AI as a 'writing assistant' feature; gated to Enterprise, not available in the free open-source core per the official enterprise-ai page.

Payload's Enterprise AI toolset includes 'dynamic image generation' per the official enterprise page; an Enterprise-gated feature, not in core.

The official SEO plugin (available to all users, not Enterprise-gated) supports auto-generating meta title/description/image via custom developer-defined generation functions, which counts as AI-assist-capable tooling if a developer wires an LLM into that function; it is not a built-in AI call out of the box.

Access control is fully code-defined at collection, global, field, and operation (create/read/update/delete) level, with arbitrary custom logic (e.g., role-based, ownership-based, locale-based). Highly granular but requires writing code, not a point-and-click permissions UI in core; Enterprise adds SSO (SAML/OAuth2) on top.

Real-time concurrent/multi-player editing is listed as an Enterprise 'Coming Soon' feature ('Multi-Player Editing'), not currently shipped in any tier.

Drafts + versions provide the data layer for editorial review before publish; Enterprise adds a more structured 'Publishing Workflows' feature for approval processes, per the official enterprise page. Basic draft/publish gating is available to all users via core versions config.

Payload provides Draft Preview (direct link to frontend rendering unpublished content in Next.js Draft Mode) and Live Preview (iframe of the frontend live-updating within the admin panel). This is content-level draft/live preview, not a distinct infrastructure staging environment, which would be a hosting-layer decision outside Payload's scope.

No in-editor commenting/annotation feature found in Payload's documented admin panel or Enterprise feature list.

Listed as an Enterprise feature ('Audit logs and version control') per the official enterprise page; core versioning tracks who changed what and when at the document level for all users, but a dedicated cross-system audit log is Enterprise-tier.

No official page confirms a 24/7 support SLA figure; Enterprise mentions 'dedicated engineering support' without a stated response-time or hours commitment in the pages reviewed.

Payload's documentation is comprehensive, current, and well-organized by feature area (fields, hooks, access control, versions, plugins, etc.) with runnable code examples throughout; it is frequently cited by developers as a differentiator versus competing headless CMSs.

No current official Discord member count or GitHub star count was verified from an official Payload page during this research pass (third-party aggregators show GitHub star counts but per SiteVersus sourcing rules those aren't cited here).

No SOC 2 / ISO certification confirmed on official Payload pages reviewed (cloud-terms, enterprise). Not stated as present or absent explicitly, so left null rather than assumed.

For self-hosted Payload, backups are the operator's responsibility (standard database backup practices for MongoDB/Postgres/SQLite); Payload Cloud likely manages backups for its hosted databases but a specific automatic-backup guarantee was not confirmed on an official page during this pass.

Native field-level localization system: configure unlimited locales with a required defaultLocale, per-locale fallback behavior, and an experimental per-locale publication status feature.

Payload provides the data structure for multi-locale content (fields keyed by locale) but no built-in translation-management workflow (e.g., assign-to-translator, translation memory, machine-translation suggestions) was found in the localization docs; this would need a custom build or third-party integration.

The locale system supports querying content per locale (?locale=es) which developers use to build per-locale URLs and hreflang tags in the Next.js frontend; the underlying data support is native, though hreflang tag rendering itself is a developer implementation task (see seo.hreflang).

Locales can be flagged rtl: true to render the admin panel interface right-to-left for languages like Arabic; RTL for the public frontend itself depends on developer CSS implementation.