Watt 3.18.0: Revolutionizing Next.js 16 Component Caching with Redis/Valkey

Web Development

Watt 3.18.0 introduces robust support for Next.js 16's `use cache` directive, enabling seamless, distributed component-level caching with Redis/Valkey for self-hosted applications.

Watt v3.18 Unlocks Next.js 16's Revolutionary 'use cache' Directive with Redis/Valkey

Paolo Insogna · Nov 18, 2025 · 7 min read

We are thrilled to announce that Watt 3.18.0 now fully supports Next.js 16.0, ushering in a transformative era for building high-performance Next.js applications.

This update is a game-changer as Next.js 16 fundamentally redefines React caching. For the first time, developers can cache individual React components and functions using a straightforward use cache directive, offering unparalleled precision over what is cached and when. This eliminates the guesswork of implicit caching behavior and the complexities of cache invalidation strategies, granting explicit, fine-grained control over your application's performance.

However, the excitement doesn't stop there. While Next.js 16 provides the foundational caching primitives, it requires custom configuration to enable component caching in production environments. This is where Watt 3.18.0 shines. With Watt's Redis/Valkey cache adapter, you gain instant, zero-configuration distributed caching. This ensures your cached React components are automatically shared across all application instances, effectively resolving cache inconsistencies and dramatically enhancing performance at scale.

This powerful combination unlocks a previously challenging feat: component-level caching that operates seamlessly in distributed, production-scale Next.js deployments. Simply add a single line (cacheComponents: true) to your configuration, judiciously place use cache directives where needed, and Watt expertly manages all the underlying complexities.

The Self-Hosting Challenge: Why Distributed Caching Matters

When deploying Next.js applications outside of Vercel's platform – whether on your own infrastructure, Kubernetes clusters, or other cloud providers – you encounter significant caching challenges that can impact both performance and data consistency. Next.js defaults to file-system-based caching, which is suitable for single-server deployments but leads to serious issues when scaling horizontally.

Consider a typical self-hosted production environment, such as a Kubernetes deployment with multiple replicas, where numerous instances of your Next.js application run behind a load balancer for high availability and scalability. When each instance relies on local disk caching, every server maintains its own distinct cache. This results in:

  • Cache Inconsistencies: Different users may encounter varying cached data depending on which server processes their request. For example, User A might see data cached an hour ago from Server 1, while User B sees data cached moments ago from Server 2.
  • Wasted Resources: Each server independently fetches and caches the same data, leading to a multiplication of database/API load and memory usage across all instances.
  • Cache Invalidation Complexity: When data changes, invalidating caches across all servers simultaneously becomes a distributed systems challenge without appropriate tooling.

Vercel's platform addresses this with its Data Cache infrastructure, which provides a distributed cache shared across all function invocations. However, in a self-hosting scenario, implementing this critical infrastructure component falls to you.

This is precisely why Watt's Redis/Valkey adapter is indispensable for production Next.js deployments. It equips self-hosted applications with the same distributed caching capabilities that Vercel offers as a platform feature. With a centralized cache store, all your application instances share the same cached data, ensuring consistency while dramatically improving performance and resource efficiency.

Understanding Next.js 16's use cache Directive

Next.js 16 introduces a fundamental paradigm shift in caching. Unlike previous versions where caching was often implicit, Next.js 16 makes caching explicit through the use cache directive. This provides fine-grained control over what gets cached and when.

You can employ the directive at various levels:

// Cache an entire component
export async function ProductList() {
  "use cache";
  const products = await fetchProducts();
  return (
    <div>
      {/* render products */}
    </div>
  );
}

// Cache a specific function
export async function getProductData(id) {
  "use cache";
  const data = await fetch(`/api/products/${id}`);
  return data.json();
}

// Cache at the file level
("use cache");
export default async function Page() {
  return (
    <div>
      {/* page content */}
    </div>
  );
}

This explicit methodology offers greater flexibility and control compared to the automatic caching behavior in earlier versions. For further details, consult the official documentation on Next.js caching strategies.

What is Watt?

Watt is an extensible Node.js application server designed to simplify the building, deployment, and scaling of applications. Whether you're developing simple APIs, intricate microservices, or comprehensive full-stack applications, Watt serves as a powerful orchestration layer, composing multiple services into a single, cohesive system.

With Watt, you can seamlessly integrate frontend frameworks like Next.js, Astro, or Remix with backend microservices, all while benefiting from:

  • Zero-configuration deployment: Applications run instantly without complex setup.
  • Service orchestration: Coordinates multiple applications and services seamlessly.
  • Production-ready features: Built-in monitoring, logging, and operational best practices.
  • Multi-threading support: Leverages Node.js worker threads for improved performance.
  • Shared caching: Centralized caching strategies, such as the Redis/Valkey adapter, for distributed cache across all instances.

Watt abstracts the complexity of inter-service communication, caching strategies, and deployment, allowing you to concentrate on your core application logic. Discover more in our Watt 3 introduction post.

The latest version of Watt adds first-class support for Next.js 16.0, including the new Cache Components feature. When you enable Watt's Redis/Valkey adapter and set the new cacheComponents option to true, you unlock the full potential of Next.js 16's use cache directive.

Key Features

  • Component-Level Caching: Utilize the use cache directive to cache individual React components, functions, or entire route handlers.
  • Distributed Caching with Valkey: Share cached components across all your application instances using Redis or Valkey.
  • Simple Configuration: Enable component caching with a single cacheComponents: true setting in your Watt configuration.
  • Seamless Integration: Watt intelligently handles all the complexities of configuring Next.js 16's cache handler behind the scenes.

Enabling Component Caching in Watt

To leverage Next.js 16's component caching with Watt, you need to configure the Redis/Valkey adapter and enable component caching within your watt.json file:

{
  "cache": {
    "adapter": "valkey",
    "url": "valkey://redis.example.com:6379",
    "cacheComponents": true
  }
}

With these settings, Watt automatically configures Next.js 16's cache handler to utilize Redis or Valkey for storing cached components, ensuring their availability across all instances of your application.

Important: ISR Cache Behavior

When enabling the Redis/Valkey adapter and setting cacheComponents: true, an important architectural consideration arises: Next.js 16 does not support running both the new component caching and the legacy Incremental Static Regeneration (ISR) cache simultaneously.

Consequently, when component caching is enabled in Watt 3.18.0 with Next.js 16, the traditional ISR cache is automatically disabled. This is a limitation inherent to Next.js 16's architecture, not a specific restriction of Watt. The new use cache directive offers more explicit and flexible caching capabilities that supersede the older ISR approach.

If your application heavily relies on ISR, you can continue to use Next.js 16 with cacheComponents disabled (or omitted) and avoid using the use cache directive. This allows you to benefit from other Next.js 16 features while retaining your existing ISR-based caching strategy.

Why Redis/Valkey for Next.js Caching?

Redis and Valkey are high-performance, in-memory data stores specifically optimized for caching workloads. When horizontally scaling Next.js applications, local caching solutions prove inadequate because each instance maintains its own cache, leading to inconsistent user experiences.

By leveraging Watt's Redis/Valkey adapter, you gain:

  • Shared cache across instances: All application replicas access the same cached data.
  • Automatic cache key management: Watt handles cache key generation using Next.js 16's compiler.
  • Production-ready performance: Autopipelining support ensures minimal latency.
  • Simple configuration: No need for manual configuration of cache handlers or complex cache lifecycle management.

Learn more about Redis and Valkey in their official documentation.

Getting Started

To begin experimenting with Next.js 16 component caching using Watt 3.18.0:

  1. Update to Watt 3.18.0 or later.
  2. Upgrade your Next.js dependency to version 16.0 or higher.
  3. Configure the Redis/Valkey adapter in your watt.json.
  4. Enable cacheComponents: true in your Next.js service configuration.
  5. Add use cache directives to the components and functions you wish to cache.

It's that simple! Watt handles all the underlying complexities, allowing you to focus on building exceptional applications.

Learn More

We are committed to making Platformatic the premier platform for building and deploying modern web applications. This update represents another significant stride forward in providing seamless, production-ready tooling for the latest web technologies.

Try it out and share your feedback with us!

Node.js Next.js