Payload CMS after the Figma acquisition: a stronger enterprise bet

Figma’s acquisition of Payload strengthened its enterprise case. The MIT license and self-hosting are unchanged, and the original team joined Figma and continues to build the product, now inside a much larger company. If you are evaluating Payload for an enterprise deployment and wondering whether the acquisition changes the calculus, it changes it in Payload’s favor.

The risk of Payload disappearing

The concern is understandable. When a large technology company acquires a product, that product can be wound down, pivoted, or absorbed, and for a proprietary SaaS product whose codebase the acquirer owns, users have little recourse.

Payload is a different kind of product, because its code is open source and lives in a public repository. Every organization running Payload in production already holds a complete copy of the platform. If Figma dissolved tomorrow and deleted the repository, every Payload deployment would keep running, and the community would fork the codebase within hours. The disappearance worry that makes sense for a hosted SaaS CMS does not carry over to a project anyone can fork.

Figma also has a strategic reason to keep investing in Payload rather than let it drift. It sells to engineering-led companies and invests in developer tooling, and Payload sits in that same world as a code-first content platform for React and Next.js teams. That overlap is the kind of thing you want behind a platform you are about to standardize on.

What changed after the acquisition

The most consequential change is who stands behind the project. Payload went from an independent startup to a product owned by a large, well-funded company, which is the kind of backing enterprise buyers look for before standardizing on a platform. Payload 3.0, which installs directly into a Next.js application, had already shipped before the acquisition. The platform an enterprise evaluates today is mature, and the acquisition adds a durable owner rather than changing the product underneath it. Payload 4.0 is now in early preview, with an admin UI redesign and further tooling on the way, so the roadmap is active rather than frozen.

What did not change

The things that did not change are the ones that matter for enterprise due diligence, and the list is short.

• The license is still MIT, with no restriction on commercial use, modification, or redistribution, and no contributor agreement that reassigns rights to Figma. The terms your legal team approved still hold.
• Self-hosting is unchanged. Payload runs anywhere Node.js runs, from AWS, GCP, or Azure to a bare VPS or an on-premise server in a regulated data center, and Figma has no access to a self-hosted deployment. Your content, database, and infrastructure stay yours.
• The open-source core still has no per-seat pricing, so an editorial team of 200 pays the same platform fee as a team of five, which is nothing. The content model, access control, editorial workflow, and admin customizations remain code your team writes and owns, with no proprietary layer inserted between your engineers and the platform.

Payload’s enterprise readiness in 2026

Here is where Payload’s enterprise readiness actually stands, feature by feature.

Role-based access control (RBAC)

The access control we build on Payload reaches down to individual fields. On the Ingersoll Rand platform, our RBAC plugin could limit an editor to image alt text alone, with no access to the rest of the media item or the page. It rests on Payload’s access-control primitives: TypeScript functions that decide who can create, read, update, or delete, evaluated before every operation and scoped to the collection, the individual document, or the field. Because those rules live in the codebase, they are reviewed and version-controlled like any other logic, which is easier to defend in a compliance audit than permissions clicked together in a dashboard. The core does not include a prebuilt roles system, so the role model is ours to build, and building it in code is what makes this precision possible.

Single sign-on (SSO)

SSO is available through Payload’s official enterprise plugin, covering SAML and OIDC against providers like Okta, Azure AD, and Google Workspace, with community plugins as a free alternative. It is a plugin rather than a core feature, so an organization that requires SSO should scope it into the build.

Version history

Document version history ships in the open-source core. Each version records what changed and who saved it, and a document can be compared against or rolled back to an earlier state, which covers the common who-changed-what question without any add-on.

Production at scale

Payload runs in production under real enterprise load. WAYF built Ingersoll Rand’s China platform on it: more than 20 brand tenants on a single Payload instance, with thousands of pages and tens of thousands of media assets migrated onto AWS China under 24/7 monitoring, delivered in five months with zero downtime at cutover. The question of whether Payload is production-ready has a reference list behind it.

TypeScript end to end

Content-model types generate automatically and are shared between the CMS and the front-end app, so a field added to a collection is immediately type-safe in the Next.js application consuming it, with no manual schema step. For teams running TypeScript across the stack, that removes a whole class of runtime error.

Where Payload is the strongest choice

Payload earns a place on an enterprise shortlist under a few conditions.

The strongest fit is a Next.js-native team. Payload 3.0 runs the admin panel inside the Next.js application, so the CMS and the site are one codebase and one deploy, and a team already on Next.js adds Payload with less operational overhead than any other enterprise CMS.

It also suits code-first engineering cultures, where infrastructure decisions are made by engineers and validated in code review rather than procurement forms. The content model is a TypeScript file, access control is a function, and the editorial UI is a React component, so every part of the platform is inspectable and modifiable through normal engineering practice.

On cost, the open-source core carries no license fee and no per-seat charge, so the recurring platform spend is the infrastructure you run. That makes total cost straightforward to model and takes the renewal renegotiation that managed SaaS builds in off the table.

For compliance-sensitive workloads, self-hosting is the deciding factor. Organizations that cannot send content or editorial metadata to a third-party SaaS, in regulated industries, government, or under strict data-residency rules, need the content on their own infrastructure. Contentful, Sanity, and Hygraph are managed SaaS, so their content lives on their systems; Payload’s lives on yours.

For organizations already using Figma to design and Payload to manage content, the two now share a vendor with explicit interest in closing the gap between design artifacts and production content structures, which has practical value for anyone maintaining a design system across both.

Questions to ask during evaluation

Evaluating Payload is a due-diligence exercise, and a few questions sharpen the decision.

Start with self-hosting capability. Payload expects an engineering team that can own the hosting environment, and an organization without that capability is better served by a managed SaaS CMS.

Then ask whether your content model benefits from code-first definition. If it changes often, carries complex access rules, or should pass through a development workflow, the TypeScript schema is an advantage; if it is stable and managed mostly by non-engineers, a GUI-driven CMS may cause less friction.

Editorial scale is the next thing to weigh. Payload’s admin is configurable but takes engineering effort to tailor to specific workflows, so a team of fifty or more editors with complex approval chains should scope editorial UI work into the implementation rather than assume it is included.

Integrations come last. Payload’s connector library is growing but narrower than Contentful’s, so marketing automation, analytics, personalization, or commerce integrations may need custom development. Scope those explicitly instead of assuming an off-the-shelf connector exists.

How WAYF can help

WAYF is an official Payload partner and top contributor, and we build Payload platforms for enterprise clients across industrial, technology, and professional-services sectors. If you are evaluating Payload for an enterprise deployment, we can scope the decision with you, including the cases where a managed SaaS would fit you better. Book a call or see our work.

FAQ

What happens if Figma discontinues Payload? The MIT license makes the code and the community independent of Figma’s corporate decisions. Every Payload deployment already holds a complete copy of the codebase, so if Figma stopped investing, the open-source community would continue development. Figma also has a clear strategic interest in Payload’s continued development, so this is a low-probability scenario and not where evaluation time is best spent.

Is Payload still open source after the Figma acquisition? Yes. Same MIT license, same public repository, same terms. The acquisition did not introduce a commercial license, a contributor agreement that reassigns rights, or any restriction on self-hosting. Payload’s open-source status is structural rather than a policy a new owner can quietly reverse, since the community could fork the project if that were attempted.

Who maintains Payload now? The original Payload team continues to lead development, now with Figma’s engineering resources available to the project. Co-founder and CEO James Mikrut and the core team joined Figma in the acquisition rather than departing, and the commit history and release cadence since show an active, growing team.

What happens to my data if I self-host Payload? Your data stays where you put it. A self-hosted Payload deployment sends nothing to Figma or any external system unless you configure it to. The database is yours, the hosting environment is yours, and Figma has no access path to your content or editorial metadata.

Is Payload enterprise-ready today? Yes, with the right framing. The open-source core includes document version history, unlimited user seats, function-based access control at the collection and field level, and full self-hosting. Enterprise SSO (SAML and OIDC) comes through Payload’s official enterprise plugin, or community plugins as a free alternative, rather than the MIT core. WAYF runs Payload in production for Fortune 500-scale clients with real editorial teams, compliance requirements, and heavy content-API traffic.

Sources

• Payload CMS, GitHub repository (MIT license): https://github.com/payloadcms/payload
• Figma, Welcoming Payload to the Figma team: https://www.figma.com/blog/payload-joins-figma/
• Payload CMS, Payload is joining Figma: https://payloadcms.com/posts/blog/payload-is-joining-figma
• Payload CMS, enterprise (SSO and audit logs): https://payloadcms.com/enterprise
• Payload CMS, release notes and 3.0: https://payloadcms.com/blog
• Payload CMS, access control documentation: https://payloadcms.com/docs/access-control/overview
• Payload CMS, get started and deployment: https://payloadcms.com/get-started
• Open Source Initiative, MIT license: https://opensource.org/licenses/MIT