That momentum is coming from both the Payload team and the community. A huge number of recent contributions have come from outside the core team, and that has made Payload more stable, more capable, and more widely used than ever.

In our latest community call we walked through several of the major areas we’re investing in for Payload 4.0: a redesigned admin UI, first-class hierarchies, better digital asset management, improved MCP support, Payload skills, and early TanStack support.

A redesigned admin UI

One of the biggest pieces of Payload 4.0 is a full redesign of the admin panel.

The goal is not to change how Payload works. The goal is to make the experience cleaner, more consistent, easier to extend, and better aligned with the quality bar people expect from modern tools.

We’re rebuilding the admin UI around a stronger design system, with more semantic styling tokens, fewer one-off styles, better interaction patterns, and improved support for theming. We’re also removing Sass, improving Tailwind compatibility, and making it easier to customize the admin panel without fighting the underlying styles.

This work also matters because Payload and Figma are becoming more connected. As we build deeper integrations between the two products, the experience of moving between Figma and Payload should feel cohesive.

Some of the areas we previewed include:

updated list and edit views
better table cells and bulk actions
richer upload views
improved modals and drawers
a redesigned user menu
cleaner Lexical / rich text controls
better focus states
enhanced contrast mode
continued support for custom components

We’re also working toward a cleaner component library that the community can eventually inspect and build from.

Hierarchies are becoming a core primitive

Payload has had the nested docs plugin for a long time, but the use case has grown beyond page trees and nested URLs.

In 4.0, we’re bringing hierarchies into Payload core and took input from our community to ensure we did this in the right way.

That means folders, tags, taxonomies, nested content structures, and tree-based organization can all be built on the same underlying primitive. This will eventually replace the nested docs plugin and unlock better UI patterns for navigating and organizing content.

For example, teams managing large content or asset libraries will be able to drill into a hierarchy, filter by folders or tags, and see related documents across collections. The sidebar is being updated to support tabs for folders, tags, and custom React components, giving developers more control over how editors navigate content.

Better digital asset management

A major reason we’re investing in hierarchies is digital asset management.

Many teams already use Payload to manage large libraries of images, PDFs, videos, and other files. In 4.0, we want that experience to feel much closer to a dedicated DAM.

We discussed improvements like:

larger, more useful file previews
PDF previews
video and audio support
localized files
file versioning
clearer documentation around upload features
possible support for on-demand resizing
expiring share links
usage references for files and images

A lot of this is still being shaped, and we’re actively looking for feedback from teams with real asset management workflows.

Payload skills and better agent workflows

Payload’s TypeScript config already makes it a strong fit for LLM-assisted development, but there is more we can do to help agents produce correct Payload code consistently.

We now have Payload skills that can be installed into agentic workflows to give models Payload-specific instructions and implementation guidance.

The next step is improving those skills with real failure cases from the community: places where an agent invented an API, missed a required config property, misunderstood a feature, or failed to use a Payload capability correctly.

We’re using those examples to improve the skills repo and benchmark changes with an eval suite.

MCP should work out of the box

We also discussed where Payload’s MCP plugin is going.

Today, setup requires too much manual configuration: enabling tools, creating API keys, checking permissions, updating MCP JSON, and often scripting the setup for a team.

In 4.0, the goal is much simpler: add the MCP plugin, configure MCP JSON, and go.

We’re planning to make tools opt-out by default, improve local development setup, improve API key UX, support project-specific instructions, handle complex schemas more reliably, and reduce dependency weight.

The end state we’re aiming for is that a fresh Payload project can work with MCP out of the box. If you've got insight or feedback feel free to join the conversation.

TanStack support is coming

Payload 3.0 brought Payload and Next.js together, but the long-term plan was never to support only Next.js.

For 4.0, we’re building a framework adapter pattern that separates Payload’s framework-specific pieces from the core. That includes admin rendering, React Server Components, loaders, and API mounting.

The first major proof point is TanStack support.

The demo is still early, and there are CSS issues to work through, but the architecture is in place and the direction is promising. The goal is that Payload users will be able to choose the framework that best fits their project while keeping the same Payload config.

If you're interested in checking out where we're at take a look at the TanStack demo.

What’s next

We'll be moving quickly through everything discussed on our last community call with a goal to ship 4.0 as soon as possible. The admin redesign and several of these features are already visible on the main branch, though they are still in active development.

We’re targeting a 4.0 beta within the next quarter, with the goal of a shorter path from beta to stable than we had with 3.0.

As always, the best way to shape what ships is to try the work in progress, comment on the RFCs, and tell us where your workflows break down.

Payload 4.0 is about making Payload more polished, more flexible, and more powerful — without losing the developer experience that made people choose Payload in the first place.