We’re excited to announce that Watt 3.18.0 now supports Next.js 16.0, bringing a transformative shift in how you build performant Next.js applications.

This is a game-changer because Next.js 16 fundamentally reimagines React caching. For the first time, you can cache individual React components and functions with a simple use cache directive, giving you surgical precision over what gets cached and when. No more guessing about implicit caching behavior or wrestling with complex cache invalidation strategies. You now have explicit, fine-grained control over your application’s performance.

However, here’s where it gets even more exciting: while Next.js 16 provides the caching primitives, it requires custom configuration to enable component caching in production environments. That’s where Watt 3.18.0 comes in. With Watt’s Redis/Valkey cache adapter, you get instant, zero-configuration distributed caching. This means your cached React components are automatically shared across all application instances, eliminating cache inconsistencies and dramatically improving performance at scale.

The combination unlocks what was previously difficult to achieve: component-level caching that works seamlessly in distributed, production-scale Next.js deployments. Add a single line (cacheComponents: true) to your config, sprinkle use cache directives where you need them, and Watt handles all the complexity behind the scenes.

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 face a significant caching challenge that can impact both performance and data consistency. Next.js defaults to file-system-based caching, which works perfectly fine for single-server deployments but creates serious issues when scaling horizontally.

Here’s the problem: in a typical self-hosted production environment, such as a Kubernetes deployment with multiple replicas, you run multiple instances of your Next.js application behind a load balancer for high availability and scalability. When each instance relies on local disk caching, every server maintains its own separate cache. This means:

Cache Inconsistencies: Different users may see different cached data depending on which server handles their request. User A hits Server 1 and sees cached data from an hour ago, while User B hits Server 2 and sees data cached just seconds ago.

Wasted Resources: Each server independently fetches and caches the same data, multiplying your database/API load and memory usage across all instances.

Cache Invalidation Complexity: When data changes, you need to invalidate caches across all servers simultaneously, which becomes a distributed systems problem without proper tooling.

Vercel’s platform solves this through its Data Cache infrastructure, which provides a distributed cache shared across all function invocations. But when self-hosting, you’re on your own to implement this critical piece of infrastructure.

This is precisely why Watt’s Redis/Valkey adapter is essential for production Next.js deployments: it gives self-hosted applications the same distributed caching capabilities that Vercel provides 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 shift in how caching works. Unlike previous versions, where caching was implicit, Next.js 16 makes caching explicit through the use cache directive. This gives you fine-grained control over what gets cached and when.

You can use the directive at different 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 approach provides more flexibility and control compared to the automatic caching behavior in earlier versions. Learn more about Next.js caching strategies in the official documentation.

What is Watt?

Watt is an extensible Node.js application server designed to simplify how you build, deploy, and scale applications. Whether you’re creating simple APIs, microservices, or full-stack applications, Watt acts as a powerful orchestration layer that composes 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 like the Redis/Valkey adapter for distributed cache across all instances

Watt handles the complexity of inter-service communication, caching strategies, and deployment, allowing you to focus on building your application logic. Learn 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: Use 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 handles all the complexity of configuring Next.js 16’s cache handler behind the scenes

Enabling Component Caching in Watt

To take advantage of Next.js 16’s component caching with Watt, you need to configure the Redis/Valkey adapter and enable component caching in your watt.json:

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

With these settings in place, Watt automatically configures Next.js 16’s cache handler to use Redis or Valkey for storing cached components, making them available across all instances of your application.

Important: ISR Cache Behavior

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

As a result, 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 of Next.js 16’s architecture, not Watt. The new use cache directive provides more explicit and flexible caching capabilities that supersede the older ISR approach.

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

Why Redis/Valkey for Next.js Caching?

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

By using Watt’s Redis/Valkey adapter, you get:

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 to manually configure cache handlers or manage cache lifecycle

Learn more about Redis and Valkey in their official documentation.

Getting Started

To try Next.js 16 component caching with Watt 3.18.0:

Update to Watt 3.18.0 or later 1.

Upgrade your Next.js dependency to version 16.0 or higher 1.

Configure the Redis/Valkey adapter in your watt.json 1.

Enable cacheComponents: true in your Next.js service configuration 1.

Add use cache directives to the components and functions you want to cache

That’s it! Watt takes care of all the underlying complexity, allowing you to focus on building great applications.

Learn More

Platformatic Watt Documentation

Next.js 16 Announcement

Next.js Cache Components Guide

use cache Directive Reference

Valkey-Based Caching for Next.js

Valkey Project

PR #4397: Next.js 16.0 Support

We’re committed to making Platformatic the best platform for building and deploying modern web applications. This update represents another step forward in providing seamless, production-ready tooling for the latest web technologies.

Try it out and let us know what you think!