Trouble setting cookies in Next.js 15.5 without using Server Actions or Route Handlers

[jv-gomes]

Summary

I’m new to Next.js and I’m having trouble setting cookies in version 15.5. My app uses a separate backend that returns a JWT token for authentication and has a refresh endpoint that issues a new token when the old one expires. I need to set and update cookies entirely on the server side, but it doesn’t seem to work unless I use Server Actions or Route Handlers.

Additional information

In my setup, there is no login form handled by Next.js - authentication happens through an external backend. After receiving the JWT, I want to store it as a cookie using Next.js server code.
However, when I try to set the cookie server-side, it never actually gets set. I suspect this happens because of the new streaming architecture in Next.js 15.5, where responses start streaming before headers (like cookies) can be modified.

I’ve read the documentation, but I haven’t found a clear way to handle this kind of flow without using a Route Handler or Server Action.

What’s the correct way to set or update cookies on the server side in this scenario?

Example

No response

[Kavindi487]

You can’t set cookies directly from Server Components in Next.js 15.5 because of React’s streaming — the response headers are already sent before cookies().set() runs.
You need to handle cookies in a Route Handler or Middleware, where Next.js still controls the response. For example, put your token logic inside app/api/auth/route.js or use middleware.js to refresh tokens. That’s the only reliable way to set or update cookies server-side in 15.5.

[icyJoseph]

Could you expand on this?

Using Middleware is not a solution either, because it runs only before the page is rendered. The server-side requests to my backend occur throughout the server's execution, not exclusively before the page is accessed

[jv-gomes]

It seems that using Middleware isn’t a viable solution, because it only runs before a page or route is rendered.
In my case, the server-side requests to my backend happen throughout the server’s execution lifecycle, not just when the page is first accessed.

This would mean that Middleware executes too early and it can’t handle situations where the server needs to refresh or update cookies dynamically during later API calls that occur after the initial request.

For context, all my requests to the backend are made through a TypeScript library that uses Axios.
Because of this, I pass get, set, and remove methods as a storage adapter to handle authentication inside that library.
The library manages token refresh automatically ( including when the access token expires ) which is why I need the ability to update cookies dynamically on the server side, without requiring any client-side interaction.

[icyJoseph]

not just when the page is first accessed.

Just for clarity sake, at risk of adding nothing to the conversation, middleware runs on every access, not just the first access.

This would mean that Middleware executes too early and it can’t handle situations where the server needs to refresh or update cookies dynamically during later API calls that occur after the initial request.

Right, so you mean that fetchUsingYourLibrar in this snippet:

export default async function Page(){
     const data = await fetchUsingYourLibrar();

     // rest of operations
}

Has access to the cookie store, in some way, and when the JWT in the cookie is expired, your library can refresh it and put it back in the store, or at least, try to, because the Next.js cookie store can't be written to during rendering.

You'd need to make a new type of container, where the library can update the cookie seen by your library etc, right?

And even then, how do you communicate back to the client that a new cookie has been used.

If the refresh logic was decoupled, it could be moved to middleware. Since it is not, you could maybe pass this in a server action:

export default async function Page(){
     const [data, newToken] = await fetchUsingYourLibrar();

     async function tokenSynch(){
      'use server'
       cookies.set(/* */, newToken)
     }
     // rest of operations

    return <ClientComponent synchAction={tokenSynch}  />
}

And call that in a use-effect or something like that. Of course assuming you get to see the newToken, which you might be able to, if you create your own store etc.

[jv-gomes]

I don’t need to communicate with the client to let it know that a new cookie is being used, since that information isn’t required on the client side. As for moving the refresh logic to middleware, that wouldn’t be possible in my case, this library is shared across multiple projects, so it needs to remain framework-agnostic.

That’s why I pass an adapter to it, allowing the library to handle get, set, and remove operations without needing to know anything specific about the underlying implementation (like the Next.js cookie store).

Essentially, the library should be able to manipulate cookies through the adapter, while the application decides what the adapter actually does internally.

However, maybe the way I’m trying to handle this cookie manipulation through the library just isn’t possible with Next.js, and I might need to move that logic directly inside the Next.js application instead.

[icyJoseph]

I don’t need to communicate with the client to let it know that a new cookie is being used

For the subsequent requests, the client has to submit its request using the refreshed token right?

this library is shared across multiple projects, so it needs to remain framework-agnostic.

having a portable function to revalidate an input token, if needed, is not necessarily framework bound

Essentially, the library should be able to manipulate cookies through the adapter, while the application decides what the adapter actually does internally.

How are you sharing the cookies with the adapter? using the await cookies() store?