Payload CMS acquired by Figma: what the deal means for developers, designers, and content teams

When Figma acquired Payload CMS, it brought together a collaborative design platform and a developer-focused content management system, two products built around modern digital workflows.

The news raised practical questions for Payload users. Will Payload remain open source? Will Figma change the roadmap? Should new projects still choose Payload? And how can teams connect design systems, content, and production websites without creating another disconnected workflow?

This guide explains what the acquisition means, what hasn’t changed, where the relationship could go next, and what fifteen months of public record actually show.

What is Payload CMS?

Payload is an open-source, TypeScript-based headless CMS designed for developers who want to build and customize the underlying application rather than work around the limits of a hosted website builder.

It runs within a JavaScript and TypeScript application stack and is commonly used with Next.js. Payload supports content modeling, authentication, media management, access control, localization, and custom admin interfaces through code and configuration. The project is MIT licensed. This article is about what the acquisition changed; our practical guide to Payload CMS covers what the platform is, how collections, hooks and access control work, and what a self-hosted stack costs to run.

Unlike a traditional page builder, Payload doesn’t require a team to use a fixed visual layout. Developers define collections, fields, relationships, roles, and workflows. Editors then manage content through the administrative interface created from that setup.

That structure makes Payload a fit for projects such as:

• Marketing websites
• Documentation platforms
• Editorial publications
• Ecommerce catalogs
• Membership portals
• Internal content tools
• Multi-site publishing systems
• Applications that need both structured content and custom business logic

The distinction matters. A CMS can be easy to start with but difficult to adapt later. Payload’s appeal comes from keeping the content layer close to the application code.

What did Figma acquire?

Figma announced its acquisition of Payload on 17 June 2025. Both companies posted the same day: Payload’s founder James Mikrut wrote Payload is joining Figma, and Figma’s chief technology officer Kris Rasmussen wrote Welcoming Payload to the Figma team. The announcement connected Payload’s developer-oriented publishing capabilities with Figma’s work in interface design, collaboration, and web creation.

Those two posts are the primary source for the transaction itself. For whatever comes next, these are the pages that will carry it first:

• Figma’s official blog
• Payload’s official blog
• Payload documentation

The deal does not automatically mean that Payload has become a closed, proprietary CMS. It also doesn’t mean that existing Payload projects need to migrate to a Figma product. Unless the companies publish a specific change to the license, hosting model, or product roadmap, do not treat speculation as a product decision.

That distinction is useful for project owners. Acquisition news often creates uncertainty because several separate questions get mixed together:

1. Who owns the company or project?
2. What happens to the open-source repository?
3. Will the licensing model change?
4. Will the CMS remain self-hostable?
5. Will the product integrate with Figma?
6. Will existing APIs and projects continue to work?
7. Should new customers choose another platform?

That was the position on day one. Fifteen months of public record now exist, so most of those questions have an answer with a date on it rather than a wait.

Why would Figma acquire Payload?

The acquisition makes sense when viewed through the gap between design and production.

Design teams create interfaces in Figma. Developers turn those designs into working applications. Content teams then manage the words, images, products, and data that appear in those applications. These stages often rely on separate tools, handoffs, and approval processes.

Payload sits closer to the production side of that workflow. It gives developers control over the content model and application architecture, while still providing editors with a structured administrative interface.

Figma brings a large design and collaboration ecosystem to that relationship. Its S-1, filed on 1 July 2025 two weeks after the Payload announcement, put the platform at over 13 million monthly active users in the first quarter of that year, about 30% of them developers working in Dev Mode and roughly two-thirds of them people who are not designers at all. Figma reported $1.1 billion of revenue for 2025, and $370.1 million in the quarter to 30 June 2026, up 48% year on year. The number that matters for Payload is the developer share, because reaching designers was never Figma’s problem.

The broader market also shows why content infrastructure matters. W3Techs puts WordPress at 40.2% of all websites, and 58.8% of the sites whose content management system it can identify, measured on 16 September 2026. That doesn’t mean every organization should replace WordPress, but it does show the size of the publishing market Figma is now adjacent to, and the demand for content systems that can support many kinds of digital experience.

Figma may see Payload as a way to extend its reach beyond design files and into the systems that publish real websites and applications.

Payload’s side of the reasoning is on the record, in more candid terms than an acquisition post usually allows. Speaking to Syntax on the day of the announcement, in an interview Payload embedded in its own post, founder James Mikrut described the alternative he turned down: "are we going to raise a Series A? Are we going to keep taking investor funding? Are we going to be another CMS face in the crowd? There’s a million of them." He framed the deal as the way to build "things that only we can do."

Read that as a statement of intent rather than of outcome.

What the acquisition could mean for Payload users

If you run Payload today, separate confirmed changes from reasonable possibilities. That separation is easier than it was, because there is now a record to check the statements against. Everything in the left column was said in public on 17 June 2025, most of it in the Syntax interview Payload embedded in its announcement. Everything in the right column is where the public record stood on 16 September 2026.

Six for six is not the same as six delivered. Four of those rows are work in progress, and the one that matters most to a reader, 4.0, has already slipped its own beta target. What the record does show is that nothing was quietly abandoned.

The core developer experience may remain familiar

Payload’s appeal comes from its use of familiar web technologies. You can define schemas in code, customize the admin panel, create custom access rules, and wire the CMS into a wider application.

That foundation is valuable because developers don’t have to replace a working architecture just because ownership has changed. Existing projects can continue operating under their current setup while teams monitor official product announcements.

Figma integration could improve design-to-content workflows

A future integration could connect design components, content structures, and publishing workflows more closely, and the shape of it is not a matter of guesswork. In that same interview Mikrut described it concretely: "imagine a frame in Figma, you click that frame and export an asset to your CMS, and it’s linked so that if the designer goes and updates that frame, then the asset is automatically updated and used on your homepage." He put the same argument structurally, that the data in your CMS "needs to connect to your design system."

A real-world scenario might look like this:

• A product team designs a campaign page in Figma.
• Developers create a reusable campaign block in a Next.js frontend.
• Payload stores the campaign title, copy, images, links, and publish dates.
• Editors update the content without changing the component code.
• Reviewers approve the page before publication.

The acquisition doesn’t guarantee that this exact workflow will ship. It does make the relationship between design assets and structured publishing a clear area to watch.

That is a promise, not a product. What exists today is a package.

@payloadcms/figma is published on the public npm registry, which lists it as public with 87 versions. The first arrived on 14 November 2025 and the most recent on 15 September 2026, so it is under active development rather than parked. It is not in the payloadcms/payload repository. Payload’s own build refers to it by a path that points outside the repository, and a pull request merged on 31 July 2026 records the adapter moving into a separate Figma monorepo.

It is also not MIT licensed. The package ships its own LICENSE.md, identical in the two versions published so far, which reads: "Copyright (c) 2026 Figma. This source code is protected under international copyright law. All rights reserved." It describes its contents as confidential, and it says that use beyond demonstration requires a signed Enterprise Agreement. The license field in its package.json reads SEE LICENSE IN LICENSE.md rather than MIT.

This is an official package rather than someone squatting a name. It publishes inside the @payloadcms npm scope, and its eleven maintainers are the same eleven who publish the MIT core and the database adapters, Payload’s two founders among them. Checked on 16 September 2026, the maintainer lists match exactly, with no additions.

So the honest answer to the open-source question has two halves. The core is MIT and nothing about that has changed. The Figma integration is a commercial product built beside it. That structure has a name, open core, and a long list of practitioners; it is how a company with an open-source project and a revenue target usually resolves the tension. What it tells you is where the line falls, which is what matters when you are deciding what to depend on.

You can verify all of it yourself. This prints the license field, the eleven maintainers and every published version:

npm view @payloadcms/figma license maintainers versions

Two cautions on that. The package is at 0.1.0-alpha.7 on the latest tag, with 0.1.0-alpha.8 published on 15 September 2026 under the alpha tag, so this describes an alpha rather than a shipped product. And a license can be changed by the people who own it. If the integration is ever folded into the MIT repository, the open-core answer stops being true, and that npm command is how you will find out.

It is also closer to how the work already runs than the word "future" suggests. On our own projects the sequence is fixed. After discovery we translate the BRD or PRD into Figma, that Figma file becomes the design documentation the client signs off, and the signed-off designs are what we build from. Figma is not a picture of the product in that flow. It is the specification, and the gap Payload’s founder describes is the distance between that specification and the code that has to reproduce it.

That is why a CMS sitting inside the design tool is a structural change rather than a convenience. Every organization that signs off designs before a build already has this gap.

The open-source model remains a central consideration

Payload’s open-source model is one of its most meaningful advantages. You can inspect the code, host the application yourself, and build custom functionality around the CMS.

That flexibility matters if you have strict data requirements, complex integrations, or a preference for owning your application infrastructure. It also reduces dependence on a single hosted dashboard or fixed set of SaaS features.

It is also the question Payload has been asked most often since the deal, and it has answered in public more than once. On the first community call after the acquisition, in October 2025, the team addressed the fear head on. People were "popping into Reddit" asking "is Payload going to be put on a shelf?", and the answer was "I’m not going to let that happen... we are around for the long run and we’re still building." On Syntax in June 2025 Mikrut had put the commercial version of the same point: Payload "will still be free and open source, but it will power a lot more."

Ten events, two streams. The lime entries are the acquisition showing up in the code; the grey ones are Payload shipping the way it always did.

You do not have to take the licensing question on trust either, because the license is a file in a public repository with a commit history attached to it.

The MIT grant in LICENSE.md has not been rewritten since the acquisition. It has been edited once, on 1 July 2026, in commit a9dbcfa, and the change was the copyright holder: "Copyright (c) 2018-2025 Payload CMS, Inc." became "Copyright (c) 2018-2026 Payload CMS, LLC." The same one-line change landed across 45 files in that commit, 45 insertions and 45 deletions, every one of them a copyright line. The permission grant, the conditions and the warranty disclaimer are untouched.

That is a corporate restructuring showing up in the source tree, and it matches the filings, where Payload CMS, LLC is the name in Figma’s subsidiary list. It is also the check worth repeating yourself in a year. Read the file, then read its history. A license change cannot happen quietly in a public repository.

Monitor official documentation for changes involving:

• License terms
• Supported database adapters
• Node.js and framework requirements
• Cloud hosting options
• Enterprise support
• API compatibility
• Long-term repository governance

Should you still choose Payload for a new project?

For many projects, Payload remains worth evaluating. The acquisition alone doesn’t determine whether a CMS is suitable. The better question is whether the platform matches the project’s technical and editorial needs.

Payload may be a strong candidate when a team needs:

• A code-first content model
• TypeScript and JavaScript compatibility
• Custom access control
• Structured content rather than only page blocks
• Self-hosting or deployment flexibility
• A CMS inside a broader application
• A customizable admin experience
• Integration with existing APIs and databases

It may be less suitable when a company needs a completely managed website builder with little developer involvement. Teams that want to select a template, edit pages visually, and avoid application maintenance may prefer a hosted platform designed for that workflow.

Consider two examples.

Example one: A growing SaaS company

A SaaS company has a marketing site, resource center, changelog, and customer story library. The team wants editors to publish content independently, but its developers need control over authentication, preview environments, redirects, and integrations with the product database.

A Payload setup could model each content type separately and connect the CMS to a Next.js frontend. The team can keep the website in its existing codebase instead of moving content into a separate system with limited customization.

Example two: A multi-region publication

A publication operates across several regions, each with localized articles, authors, images, and publishing permissions. Editors need different roles, while the development team needs control over delivery, caching, search, and third-party integrations.

Payload can support a structured model for articles, authors, categories, media, and locales. The team still needs to design the editorial workflow carefully. A CMS won’t solve unclear ownership or inconsistent content standards by itself.

Payload compared with other CMS options

The right comparison depends on the project, but several patterns appear frequently.

These comparisons aren’t rankings. They describe different priorities. The full WordPress comparison works through the two platforms in detail.

A company that values visual editing above code-level control may prefer a visual builder. A company that needs a custom product application may choose a developer-first CMS. Payload sits in the second category, with a particularly close relationship to the application code.

A gap many acquisition articles miss: operational continuity

Most acquisition coverage focuses on strategy and product direction. Project owners often need a more immediate answer: how do we protect the system we already run?

A practical continuity checklist includes:

1. Record the current version. Document the Payload version, Node.js version, database version, and major dependencies. As of 16 September 2026 the current stable release is 3.89.0, shipped on 10 September 2026 from the 3.x branch, which is still receiving fixes while 4.0 is built on main. Write down what you are on today, because the useful comparison in a year is against your own number rather than against the latest one.
2. Export configuration and content backups. Keep tested backups outside the production environment.
3. Review the repository. Identify custom plugins, hooks, access rules, and frontend dependencies.
4. Test a full deployment. Confirm that the project can be rebuilt in a clean environment.
5. Monitor official release notes. Use Payload and Figma’s own channels as the source of truth.
6. Avoid rushed migrations. Don’t change platforms simply because ownership changed.
7. Review licensing and service terms. Revisit the decision if the published terms change.

This process protects teams from two opposite mistakes. Some organizations react too quickly and abandon a platform that still meets their needs. Others ignore meaningful changes until an upgrade or service change creates an emergency.

Neither response is useful. A documented system and a measured review give teams more control.

What should developers and content teams watch next?

Several signals will reveal how the acquisition develops.

Product roadmap

The roadmap is already published. On 9 June 2026 Payload posted Payload 4.0: admin UI redesign, TanStack, MCP, and more: a rebuilt admin panel, hierarchies as a core primitive replacing the nested-docs plugin, better digital asset management, MCP that works without manual setup, and a framework adapter that ends the Next.js-only arrangement, with TanStack as the first proof. The post targets "a 4.0 beta within the next quarter."

That quarter has now passed. As of 16 September 2026 the latest release on npm is 3.89.0, shipped on 10 September 2026, and no 4.0.0-beta has ever been published. What has been published is 118 prerelease 4.x builds since 7 May 2026, under the internal and canary tags, the most recent being 4.0.0-canary.33 on 8 September 2026. Payload’s main branch already carries a 4.0 version number, and 3.x ships from its own release branch.

Read that as work in progress rather than as drift. The date slipped and the code did not stop, which is the combination you want if you are planning a build. Assume 3.x, and treat the redesigned admin as something to adopt later rather than something to wait for.

Open-source governance

Repository activity, release cadence and licensing are all measurable, and measuring them beats reading announcements about them. Here is what the fifteen months since the announcement look like, as of 16 September 2026.

Payload publishes its own version of these numbers, and they survive being checked. Its May 2026 community call claimed "over 150 new features and merged over a thousand PRs" since October, and around 600 issues closed. GitHub’s own search puts the merged pull requests between 1 October 2025 and the day of that call at 1,169, and the issues closed at 759. The vendor under-claimed on both. Over the whole fifteen months since the announcement, 2,275 pull requests have been merged.

The same call put weekly npm installs at 400,000, up from 100,000 a year earlier. The registry says 96,560 for the equivalent week in May 2025 and 406,860 in May 2026, so that claim holds too, and installs have since reached 598,929 in the week to 11 September 2026.

A vendor whose published numbers are conservative is a vendor whose other claims are worth more.

The 2026 tail is thinner because 4.0 moved to the main branch, not because the project slowed down. No month is empty.

Run the same queries yourself in a year. They take minutes, they need no relationship with anybody, and they answer the governance question better than a statement of intent does.

Hosting and pricing

This one has already moved, and in the opposite direction to the one most acquisition coverage predicted. Payload Cloud, the managed option, stopped taking new deployments. Existing projects keep running, Payload says no pricing changes are planned for them, and it also says they will need to migrate eventually to "something better" that does not exist yet. For a new project there is no managed option to compare against. You self-host, anywhere a Next.js app runs.

Something managed is coming back, and the clearest statement of that sits in a filing rather than a blog post. Figma’s annual report, filed on 18 February 2026, says Payload "is being integrated into Figma’s platform" together with "Payload-specific infrastructure" supporting "the deployment, operation, and governance of content and applications." Infrastructure for deployment and operation is a hosting product being described to investors. Nobody has published what it will cost. Until someone does, the bill is the one you assemble yourself, and what a self-hosted Payload stack actually costs is priced out line by line in our companion article.

Payload said as much a year before that filing. Asked about Payload Cloud on the October 2025 community call, the team’s answer was that it "is in the bucket of you will hear more soon from us. We are working on some very exciting things." Eleven months later nothing further has been announced.

Compatibility

Compatibility details matter more than broad statements about a combined vision, and the numbers are published. Payload 3.x, the line you would build on today, requires Node.js 20.9.0 or later, Next.js in one of four ranges (15.2.9 to 15.2.x, 15.3.9 to 15.3.x, 15.4.11 to 15.4.x, or 16.2.6 and above), and MongoDB, Postgres or SQLite. Not every Next.js release inside those major versions works, which is the kind of constraint that decides an upgrade window.

The requirements for 4.0 are already written down in the repository, on the branch where it is being built: Node.js 24.15.0 or later, Next.js 16.2.6 or later, and TypeScript 6.0.3 or later. If your runtime is pinned below any of those, that is your 4.0 migration cost, and you can start budgeting for it now rather than on release day.

Editorial experience

A successful connection between Figma and Payload will need to serve editors as well as designers and developers. If the workflow creates extra approval steps or forces content into rigid layouts, teams may not adopt it.

Final thoughts

Figma’s acquisition of Payload brings attention to a problem many organizations already face. Design, development, and content operations often live in separate systems. Payload gives developers a flexible content foundation, while Figma has the reach and collaboration experience to explore a closer connection between design and publishing.

For existing users, the sensible response is to monitor official announcements, document the current system, and avoid unsupported assumptions about the future. For new projects, evaluate Payload based on architecture, content workflows, hosting needs, and team skills, not acquisition news alone.

The decision belongs to your project rather than to the news. Document what you run today, read the license file and its history rather than the announcements about it, and re-run those queries in a year. If the numbers still look like this, the acquisition changed who owns Payload and very little else.

References

1. Figma Blog
2. Payload CMS Blog
3. Payload CMS Documentation
4. Payload CMS GitHub Repository
5. Figma, Inc. Form S-1, U.S. Securities and Exchange Commission, 1 July 2025
6. W3Techs, Usage Statistics and Market Share of WordPress, measured 16 September 2026
7. Payload is joining Figma, Payload CMS blog, 17 June 2025
8. Welcoming Payload to the Figma team, Figma blog, 17 June 2025
9. Payload 4.0: admin UI redesign, TanStack, MCP, and more, Payload CMS blog, 9 June 2026
10. Payload has joined Figma, Payload Cloud notice
11. Payload CMS LICENSE.md, GitHub
12. Why did Figma buy a CMS? Syntax, 17 June 2025
13. Payload community call, 1 October 2025
14. Payload community call, 21 May 2026
15. Payload pull request #17594, GitHub
16. @payloadcms/figma on the npm registry
17. Idea Labz, Payload CMS: a practical guide to its features, architecture, and best use cases
18. Idea Labz, Payload CMS vs WordPress: an honest comparison
19. Idea Labz, Payload CMS pricing: what it actually costs to run