Next.js 16 Cache Components and Payload CMS: What Is Actually Supported?

When Next.js 16 introduced Cache Components and directives like 'use cache' and 'use cache: remote', it opened the door to a much cleaner caching model for modern apps. For teams using Payload CMS, especially inside the same Next.js application, that immediately raised an important question:

Can Payload actually work with Cache Components?

For a while, the answer was frustrating. Early attempts often ran into admin panel errors, static optimization conflicts, and general uncertainty around whether Payload could coexist with Next.js 16’s more aggressive rendering model. That led many developers to believe the feature simply was not supported.

That is no longer the full story.

The short answer

Payload now has initial support for Next.js Cache Components. The major blocker that caused the embedded admin panel to fail when cacheComponents was enabled has been addressed. That means developers can enable Cache Components for their frontend without immediately breaking Payload admin.

However, this does not mean full compatibility is guaranteed across every part of the Payload experience.

That distinction matters.

What changed

The key improvement came through Payload PR #16020, which fixed the most obvious breakage when cacheComponents is enabled.

The issue was caused by the Payload admin layout reading cookies, headers, and authentication data at the top level. Under Next.js Cache Components, that triggered errors like data blocking navigation outside a Suspense boundary. In practice, it meant developers could not enable Cache Components at all if Payload admin lived inside the same app.

The fix introduced two important changes:

• withPayload detects whether cacheComponents is enabled in the Next.js config
• Payload sets an internal environment flag and conditionally wraps the admin root in Suspense

That suppresses the immediate runtime errors and allows the admin panel to load even when Cache Components are turned on.

In other words, the old hard stop is gone.

What this means for real projects

If you are using Payload as a backend or CMS and fetching content in your frontend, you are in a much better position now than you would have been a few months ago.

Using Cache Components in your frontend data layer is now a reasonable approach. That includes patterns like:

• fetching shared CMS content in Server Components
• using 'use cache' for stable content
• using 'use cache: remote' for request-time reads that benefit from a shared durable cache

This is especially helpful when your site needs better cache hit rates across server instances or when you want to reduce load on Payload or another upstream service.

For many storefront and marketing-site use cases, that is the main win.

What is still not fully solved

Although the core compatibility issue was fixed, Payload itself does not present this as complete, caveat-free support. The current state is better described as usable with known limitations.

Those limitations are mostly centered on the embedded admin experience.

1. A flash on hard refresh

When Cache Components are enabled, a hard refresh of the admin can briefly show a gray flash before the UI appears.

This is not ideal, but it is largely cosmetic.

2. Some 404 responses can return HTTP 200

The not-found UI may render correctly, but because of how streaming and Suspense interact in this setup, the HTTP status can still be 200 instead of 404.

That is a real technical caveat and may matter depending on tooling, monitoring, or expectations around route behavior.

3. Playwright tests can break

Next.js may keep previously visited route segments in the DOM as hidden elements instead of fully unmounting them. That can cause selector collisions in Playwright, especially when tests rely on IDs or strict locator behavior.

This does not necessarily affect end users directly, but it can make automated test suites unreliable unless selectors are updated.

So is it safe to ship?

For most frontend use cases, yes, it is reasonable.

If you already shipped a client project using Cache Components with Payload and everything is working, there is no reason to assume you made a bad decision. The most serious blocker was fixed, and current Payload guidance reflects that enabling Cache Components should no longer break admin outright.

The bigger caution is this:

• frontend usage is the safer path
• embedded admin behavior still has edge cases
• full support is still evolving

That means the feature is no longer in the category of "do not use under any circumstances." It is more accurate to say: use it deliberately, understand the limits, and test the admin experience carefully.

Where 'use cache: remote' fits in

For teams looking at 'use cache: remote', the feature makes the most sense when your cached work happens at request time and you need cache sharing across instances.

That can be valuable when:

• your CMS or API is rate-limited
• your app runs in serverless or multi-instance environments
• request-time data is expensive to compute or fetch
• in-memory caching alone is not durable enough

In a Payload setup, this is usually most compelling for frontend content fetches, not for trying to force the entire admin experience into a perfect Cache Components model.

Final takeaway

The old statement that “Payload does not support Cache Components” is outdated.

A more accurate statement today is this:

Payload supports Cache Components well enough to avoid the previous admin-breaking errors, and frontend usage is now viable. But full compatibility is still not guaranteed, especially inside the embedded admin experience.

That is an important difference.

If you shipped it to a client without realizing the history behind the feature, that is understandably stressful. But based on the current state of support, you likely did not ship something fundamentally broken. You shipped on top of a feature that is now usable, with a few clearly defined limitations that are mostly relevant to admin edge cases and testing.

If you want, I can also turn this into a more opinionated blog post, a LinkedIn-style version, or a shorter release-note style article.