Payload CMS: our review after 4 months in production

Updated on October 28, 2026: added a summary, a comparison with Strapi, WordPress and Webflow, figures from our own project, the arrival of Payload 4, a section on AI, four new questions and a list of sources.

Since June 2026, the site you are reading has been running on Payload CMS and Next.js, a widely used framework for building websites. We migrated nearly 200 articles from Webflow, along with our case studies and service pages, in both French and English. Here’s how Payload changes daily operations, what it really costs, when we wouldn’t recommend it, and the pitfalls of a migration. Technical facts verified on October 27, 2026, on Payload 3.

In short

• What it is: a free, open source CMS (MIT license), installed in the same project as the Next.js site. The code and the content belong to you.
• Who it’s for: sites with lots of interconnected content, several languages, specific features or room to grow.
• The real cost: the software is free; you pay for hosting (less than €10 ex-VAT per month for our typical showcase website setup), development and maintenance.
• The limit: it’s an application that needs looking after. If no one handles the technical side after launch, or if your team wants to change the design itself, an all-in-one tool like Webflow remains a better fit.

Payload CMS at a glance, and what has changed since 2024

Payload is an open source headless CMS (MIT license), designed for Next.js. A CMS is the tool used to manage a site’s content: it’s the admin panel where you write text and add images. “Headless” means this admin panel doesn’t control the layout: it stores the content, and the custom-built site displays it as needed. “Open source” means Payload’s code is public and free to use, even for commercial sites. The project has more than 45,000 stars on GitHub, the usual popularity indicator for open source software.

With Payload, content types, their fields and user permissions are defined in the project’s code (official overview). Since version 3, released on November 19, 2024, Payload installs directly into a Next.js application: the site and its admin panel form a single project. It works with the most common databases (PostgreSQL, MongoDB, SQLite).

Three developments matter for a decision in 2026:

• Joining Figma, and the end of managed hosting for everyone. Figma announced on June 17, 2025 that the Payload team was joining it, and committed to keeping the software open source. However, the creation of new projects on Payload Cloud, the publisher’s managed hosting, is suspended; hosting by Payload is now only offered in the Enterprise plan, Payload’s paid offering for large organizations. In practice, the site is hosted elsewhere: on a rented server, or with specialized providers like Vercel or Cloudflare, for which Payload provides ready-to-use templates.
• A steady release pace. Payload ships a new version almost every week: version 3 went from 3.0 to 3.92 in under two years (release history). Keeping up with these updates is regular work to factor into maintenance.
• A close tie with Next.js. Not all Next.js versions are compatible with Payload: updating one means checking the other.

Payload 4: what’s coming

The team presented Payload 4 on June 9, 2026, and the first beta versions (test versions, not yet recommended for production) have been published since October 9, 2026. The announced work: a redesigned admin panel, built-in folders and content hierarchies, better handling of images and files, a simpler connection to AI assistants, and the option to use Payload with a framework other than Next.js (TanStack first).

Our take: there’s no need to wait for Payload 4 to start a project. A version 3 site will be able to move to version 4 the same way it moves from one version to the next today, with time set aside for testing.

What we actually have in production

Our own site. Next.js 16 and Payload 3 in the same application, a PostgreSQL database, a server with OVH and a separate staging site (a copy of the site for testing before going live). The blog, case studies, service and sector pages, menu and footer are all managed in the admin panel. We set one rule: any visible text on the site must be editable without touching the code.

Zéro Doute, a directory of verified service businesses in Charente. We developed the site and its admin panel: company profiles, testimonials linked to each business, articles, and contact requests logged in the CRM. Today, the Zéro Doute team runs the site on its own: they add newly certified companies, publish audio testimonials from their clients and update ratings. The content model (the list of content types, their fields and the links between them) also carries business rules: a testimonial cannot be published while the company it’s linked to is still a draft.

Parallaxe Studio, an architectural photography studio: starting from a static prototype, the site is now fully managed in Payload (pages, projects, services, images).

These projects are featured on the page our Payload CMS case studies.

Our site in figures

Measured on October 27, 2026, in our site’s code and on the public site:

• Versions: Payload 3.88, Next.js 16.3.
• 11 content types (“collections”): articles, case studies, pages, media, testimonials, team members, contact requests…
• 61 single-instance pages and settings (“globals”): home page, service and sector pages, site settings…
• 245 blog articles online, in French and English.
• 234 database changes (“migrations”) since launch.
• About 1,270 recorded code changes since going live on June 12, 2026.
• 30 versions kept per document.

What these figures say: a Payload site isn’t frozen at delivery. Every new service page, every added field goes through the code and then through a database migration, tested on staging before going live. That’s what keeps the admin panel clean, and it’s also why you need a technical team in the loop.

To make it concrete, here is how we enable drafts, autosave and version history on our articles. These four lines are all it takes; the admin panel handles the rest:

versions: {
  drafts: { autosave: true },
  maxPerDoc: 30,
},

When Payload is the right choice

Based on what we’ve built, Payload makes sense in four scenarios:

1. Extensive, interconnected content. Articles, case studies, offers, companies, testimonials: each type has its own fields, and the links between content are true relationships, with rules. Zéro Doute’s testimonial publishing rule is a good example.
2. A multilingual site with fine-grained control. Each field (title, text, button, etc.) has its own version in every language, with different URLs per language if needed (localization documentation). Our site works this way in French and English.
3. A site that needs to connect to other tools or to grow. CRM-connected forms, directories, client portals, internal search: everything is developed within the same project as the site.
4. The desire to own your site. Code and content are yours, the database can be exported, and you choose where it’s hosted, including in France.

When not to choose Payload

• No one to handle the technical side after launch. A Payload site is an application: you need someone, in-house or a provider, for updates, hosting and new features.
• A team that wants to change the design itself. In the admin panel, you edit content and assemble the sections designed for your site; changing the design or creating a new type of section requires code.
• A ready-made multi-level approval workflow (a writer submits, a manager approves), or login with the company account (SSO). Drafts, previews and roles (who can do what) are included; anything else falls under the Enterprise plan, on a quote basis, or requires custom development.
• A small, stable site to launch in a few days. An all-in-one tool like Webflow or Wix does this job very well, with hosting, security and backups included.

Payload, Strapi, WordPress or Webflow: the comparison

Comparison drawn up on October 27, 2026, from the official documentation and pricing pages listed at the end of the article.

Payload

• Open source and free (MIT), Enterprise plan on a quote basis.
• Site and admin panel in a single Next.js project, hosted wherever you want.
• Version history and multilingual support included.
• Design changed by a developer; updates, backups and server to take care of.

Strapi

• Open source, free Community edition (MIT) and paid plans.
• An application separate from the site, hosted wherever you want or on Strapi Cloud.
• Multilingual support included; version history reserved for paid plans.
• Design changed by a developer; the same upkeep as Payload, for two applications.

WordPress

• Open source and free; advanced themes and plugins are often paid.
• Site and admin in the same tool, built on PHP.
• Revisions included, multilingual support through a plugin.
• Design editable by the team through the theme; frequent updates to the core and plugins.

Webflow

• All-in-one tool, subscription per site and per workspace.
• Hosting included, with Webflow only.
• Site backups included, multilingual support as a paid add-on.
• The team changes the design without code; upkeep is handled by Webflow.

Which one to choose?

Our take is straightforward. Webflow remains the right choice when the team wants to keep control over the design and requirements change little; we offer it too (see the strengths and limitations of Webflow CMS). WordPress makes sense mainly with a heavy existing setup or an essential business plugin; it’s the most widespread tool (39.6% of all websites according to W3Techs), but also the most exposed: Patchstack recorded 11,334 new vulnerabilities in its ecosystem in 2025, 91% of them in plugins. Strapi and Directus split the site and the admin into two separate applications; Directus is primarily designed for data management (our review of Directus). Payload’s decisive advantage for us: a single project to develop, host and maintain.

What this changes for the marketing team

Drafts and previews. On our articles and case studies, every edit can be saved as a draft, with autosave while typing, then checked with the Preview button before publishing (how drafts work). The public only sees published content.

Version history. When enabled for a content type, Payload keeps successive copies of each document, shows what changed between two versions and lets you roll back (versions documentation). We keep 30 per document (the default setting is 100). The only limitation: a change made directly in the database, outside Payload, leaves no trace.

A decision to make at the design stage: which content types have drafts. Drafts and version history are configured content type by content type. For pages that rarely change, publishing directly may be enough; for pages being redesigned or edited by several people, drafts become essential. This choice is made when designing the content model: it costs more to change later.

Multilingual support. Each translatable field has a French and an English version; if the English field is empty, the site displays the French version.

Creating a page without a developer. The admin panel lets you assemble a new page from the sections designed for the site.

What remains technical. Some operations still require a developer. Redirects, for example: when you rename the URL of a published page, the old address must redirect to the new one. An official plugin lets you manage them from the admin panel; you need to plan, during development, for the site to apply them. More broadly, the admin panel is only as good as the content model behind it: that’s where the team’s autonomy is decided.

Payload and AI: what already works

Because the whole content model is described in code, Payload lends itself well to AI assistants. Two uses are in place on our site.

An AI assistant that reads and edits content. Payload provides an official MCP plugin (MCP is a standard protocol that lets an assistant like Claude or ChatGPT connect to a piece of software). We enabled it with safeguards: each team member uses their own key, the assistant only has the permissions of the person using it, it only sees content (articles, pages, media), and it cannot delete anything. In practice, you can ask it to find every article that mentions a service, or to prepare a correction, then review it before publishing.

Creating a page from a prompt. With the Scroll AI Builder, which we offer on our Payload sites, a new page can be created in about ten minutes from a prompt, using the site’s sections, then reviewed before publishing.

In both cases, AI prepares and the team approves: nothing is published without review. Payload 4 is set to make the MCP connection simpler to set up.

Data and security

With Payload, you choose where your data lives: our site and its database run on an OVH server, and the encrypted backups are stored off that server. By default, Payload sends anonymous usage statistics to its publisher; a single configuration line turns them off (“telemetry” option). As with any self-hosted software, security relies on regular updates: that’s the “maintenance” item below.

Costs to anticipate

Software: zero. Payload is free, with no mandatory subscription (official page). So is WordPress, but its advanced themes and plugins are often paid. Only the Enterprise plan (single sign-on, approval workflows, visual editing, hosting by Payload, etc.) is paid, on a quote basis. All-in-one tools, on the other hand, run on subscriptions: Webflow, for example, charges a subscription per site, plus a workspace subscription and additional users (Webflow pricing).

Hosting: low. For a showcase website of around ten pages with under 10,000 visitors a month, our typical setup costs less than €10 ex-VAT per month: a small OVH server and the domain name, with the add-on services (emails, analytics, network protection) staying on their free plans. The bill goes up with volume: a heavier database, high traffic, lots of emails.

Development: the main cost. It depends on the number of pages and templates, the level of design, the volume of content to migrate, multilingual needs and integrations with your tools. Part of the budget goes into designing the content model: that work is what makes the admin panel simple to use afterwards. Each project is quoted individually, after an initial conversation about your needs.

Maintenance: the often-overlooked cost. With an all-in-one tool like Webflow or Wix, the platform takes care of servers, security and backups. With a self-hosted Payload site, as with WordPress, someone has to do it. On our site: engine updates every month, an encrypted database backup every night, regular checks that the backup restores correctly, external monitoring that alerts us if the site stops responding, and an alert if a backup fails. We offer this follow-up, if you wish, on the sites we develop.

Changing CMS: five checkpoints from our own migration

Our new site has been live since June 12, 2026. It came from Webflow, but these points apply to any migration, from WordPress as well as from an all-in-one tool. Migrating nearly 200 articles brings out pitfalls the documentation doesn’t mention. Here are the ones we ran into, and the checklist we drew from them.

1. The article body is not the whole article. In the old tool, part of the content may live outside the main text. In our case (Webflow), article FAQs were stored in a separate collection (a standalone content list, a bit like another spreadsheet tab), linked to each article, and an import that doesn’t follow this link leaves them behind. In WordPress, it’s often the fields added by plugins. What we check: an inventory of every field of every content type, including the links between them, before writing the script that copies the content.

2. Compare old and new content automatically. Proofreading by eye isn’t enough across hundreds of pieces of content. What we check: a script automatically compares old and new content, field by field, before going live.

3. Watch out for traces of the old tool. Every tool leaves its own. Webflow’s “empty” paragraphs often contain an invisible character, which creates large gaps between paragraphs if imported as is. In WordPress, it’s for example plugin shortcodes, which mean nothing once outside WordPress. What we check: how imported articles are rendered, not just their text.

4. Check the page actually served, not just the admin panel. The title shown in Google and the page’s reference address (the “canonical URL”) can be correctly set in the admin panel but arrive too late in the page code, because Next.js sends the page in chunks. Next.js states that Google can read them; we prefer not to take the risk and place them at the top of the page. What we check: the page as Google receives it, for each page template.

5. Treat URLs as a project of their own. Redirects from old URLs are prepared before launch, but the work doesn’t stop there: a URL renamed later breaks the links written directly in the text of other articles. What we check: every rename goes through a redirect and an internal link repair.

The full method (audit, content mapping, redirect plan) is described on our Webflow to Payload migration page.

Our take

Payload is now our default choice for sites with a lot of interconnected content, several languages, specific features or room to grow. After four months in production, the verdict holds: our team publishes without a developer, the Zéro Doute team runs its site on its own, and our site has kept evolving every week (234 database changes since June). It’s not a maintenance-free choice: it replaces an all-inclusive subscription with a site you own, which you have to host, back up and update. If no one can take on that work, or if your team mainly wants to change the design itself, an all-in-one tool will remain a better fit. To decide based on your situation, our custom website design and redesign page explains how we choose the right tool with our clients.

Sources

Links consulted and checked on October 27, 2026.

Payload (publisher)

• What is Payload?: official documentation
• Payload 3.0 announcement: November 19, 2024
• Payload 4.0 presentation: June 9, 2026
• Payload has joined Figma: what changes for Payload Cloud
• Get started with Payload and Enterprise plan
• Documentation: versions, drafts, localization, databases, migrations, redirects, MCP plugin, configuration and telemetry
• Source code on GitHub, MIT license and release history

Other sources

• Figma: Payload joins Figma: June 17, 2025
• Next.js: generateMetadata documentation
• Strapi: documentation, internationalization and pricing
• Webflow: pricing
• W3Techs: WordPress market share
• Patchstack: State of WordPress Security in 2026

Figures from our project: measured on October 27, 2026, in the code of agence-scroll.com and through its public API.