Runtime environment variables not respected in API routes after upgrading to Next.js 16

[acasamassimacrif]

Summary

After upgrading from Next.js 15 to Next.js 16, runtime environment variables injected into the container (e.g., via Docker or Kubernetes pod) are no longer correctly read by API routes.

Previously, in Next.js 15, API routes using export const dynamic = "force-dynamic" returned the runtime values of environment variables. Now, in Next.js 16, the same API routes always return the .env values bundled at build time, ignoring runtime overrides.

Additional information

Example API route:

// app/api/env/route.ts
import { NextResponse } from "next/server";

export const dynamic = "force-dynamic";

export async function GET() {
  return NextResponse.json({
    NEXT_PUBLIC_BASE_URL: process.env.NEXT_PUBLIC_BASE_URL ?? null,
    NEXT_PUBLIC_APP_VERSION: process.env.NEXT_PUBLIC_APP_VERSION ?? null,
  });
}


Client fetch example:

useEffect(() => {
  fetch("/api/env")
    .then((res) => res.json())
    .then(console.log);
}, []);


Observed behavior:
The API route returns build-time .env values instead of runtime values injected in the container.

Expected behavior:
The API route should return the runtime environment variable values at container startup, as it did in Next.js 15.

Environment info:

next info:

Next.js: 16.0.3
React: 19.2.0
React DOM: 19.2.0
Node.js: v22.20.0



Additional notes:
The issue appears to be related to Next.js 16 bundling behavior for API routes.

Cache-Control: no-store does not resolve the issue.

Hosting tested in Docker with output: "standalone".

Example

No response

[icyJoseph]

If you are using cache components, then the route handler is getting prerendered, https://nextjs.org/docs/app/getting-started/route-handlers#with-cache-components (better guide coming soon) - but you can use connection, https://nextjs.org/docs/app/api-reference/functions/connection:

import { NextResponse, connection } from "next/server";

export async function GET() {
  await connection();

// NOPE - These are NEXT_PUBLIC_ prefixed, so they are inlined.
  return NextResponse.json({
    NEXT_PUBLIC_BASE_URL: process.env.NEXT_PUBLIC_BASE_URL ?? null,
    NEXT_PUBLIC_APP_VERSION: process.env.NEXT_PUBLIC_APP_VERSION ?? null,
  });
}

In general, even in v15, we've been trying to push the usage of connection over the force-dynamic flag, but only recently - sorry if this has caused issues.

Edit: I had missed the NEXT_PUBLIC_ prefix... that inlines them at build time with the DefinePlugin

[acasamassimacrif]

Hi, thanks in advance for your help!

I’ve tried using await connection() in the route handler, but the behaviour remains the same: the API still returns the build-time values from .env instead of the runtime environment variables injected in the Docker/Kubernetes container.

It seems that in Next 16, NEXT_PUBLIC_* environment variables are always replaced at build-time, even when using connection(). This makes it impossible to read runtime overrides directly in route handlers.

We’re looking for a solution that allows runtime API routes to respect the actual container environment variables.

[icyJoseph]

Uff yes, I had missed that NEXT_PUBLIC_ detail, I am not reading so well today it seems...

I guess you were using the publicRuntimeConfig thing before? That just got removed in v16? Is it not feasible to update and remove the prefix NEXT_PUBLIC_ in that project?

This is been the case for a while though, the DefinePlugin tradition in frontend apps. At the top of my head I don't recall a way to disable this.

[acasamassimacrif]

Thanks a lot for the clarification — really appreciate your time.

Yes, in our case, the main issue is that the project relies heavily on runtime environment variables (injected at container startup) and the NEXT_PUBLIC_ prefix was being used intentionally, because these values must also be available on the client side.

With the removal of publicRuntimeConfig in v16, we were hoping route handlers could still read the actual runtime values, but since NEXT_PUBLIC_* is statically replaced by DefinePlugin at build time, it means there’s effectively no longer a way for a client-exposed variable to be both:

• client-side available
• runtime-driven (instead of build-time)

Unfortunately, removing the NEXT_PUBLIC_ prefix isn’t feasible for us, because these values need to be used in client components as well.

If I understand correctly, in Next 16, there is currently no supported mechanism to have a variable be both client-exposed and runtime-resolved, correct?

If possible, could you share any recommended patterns or best practices for handling client-side runtime configuration in v16?

Thanks again!

[icyJoseph]

Right, it depends a bit. I can assume you were using on request rendering cuz using the publicRuntime option disabled prerendering, right?

So you can pass the env vars as props to client components, from the server and it should work fine.

[acasamassimacrif]

Thanks again for the clarification!

Regarding the suggestion to pass env vars as props from the server to client components: unfortunately, this isn’t really feasible in our case. These values are used in many parts of the application, including client components that perform fetch calls, and the API base URLs themselves depend on the environment where the container is deployed. Propagating these values manually through props (or even via a React provider) would introduce significant complexity and require major refactoring across the app.

Just to double-check my understanding:

In Next 16, there is currently no mechanism to have a variable that is both resolved at runtime and available globally on the client, as was previously possible through NEXT_PUBLIC_* or publicRuntimeConfig, correct?

Given this limitation, I wanted to ask:
Is the team considering reintroducing this capability or an equivalent mechanism in future releases?
For many production setups — especially those involving containerised deployments with runtime-injected configuration — this behaviour is quite important.

Thanks again for your help!