A Sitefinity Cloud Next.js renderer is deployed with the App Router, and a NEXT_PUBLIC_ environment variable is added under the Custom NextJsRenderer <Environment> AppSettings or Custom NextJsRenderer Release AppSettings variable group. After the NextJsRenderer.CI.CD pipeline completes and the deployment finishes, the value is not available in client-side code through process.env.NEXT_PUBLIC_*.

• Sitefinity Cloud applies renderer AppSettings during deployment, not during the client bundle build step.
• Because one build artifact is promoted across environments, deployment-time NEXT_PUBLIC_* values cannot be different per environment on Sitefinity Cloud.
• If client code uses a fallback such as ?? or ||, that fallback can be compiled into the client bundle when no build-time value exists.
• This can hide the issue in Staging when the fallback happens to match the current origin, then surface later in Production when the promoted artifact still points to the Staging address.
• Non-prefixed variables from the same Sitefinity Cloud AppSettings group can still work correctly in server-side code at runtime. That contrast is a strong diagnostic signal.
• This behavior applies to Sitefinity Cloud Next.js renderer projects. It does not apply to self-hosted deployments that perform a separate build for each environment.

This is expected behavior on Sitefinity Cloud.

1. Next.js exposes NEXT_PUBLIC_* variables to browser code by inlining their values into the client JavaScript bundle during next build.
2. Sitefinity Cloud applies the Custom NextJsRenderer Release AppSettings and Custom NextJsRenderer <Environment> AppSettings variable groups during deployment, not during the build step that creates the client bundle.

Because the public value is not available when next build runs, it cannot be embedded into the browser bundle. The value becomes available only after deployment, which means it can still be read by server-side runtime code but not by already-built client-side code.

A secondary effect is that Sitefinity Cloud promotes a single build artifact across environments. As a result, a NEXT_PUBLIC_* value cannot vary per environment on Sitefinity Cloud when it is expected to come from deployment-time AppSettings.

Use one of the following supported approaches. Option 1 is the recommended approach.

1. Recommended: avoid the need for a browser-visible environment value.

   Use relative, same-origin requests in client-side code so the renderer proxy forwards the request to the CMS, and read a non-prefixed variable such as SF_CMS_API only on the server.

   This approach keeps one build artifact working across all environments and avoids browser cross-origin calls.

   Complete both steps:

   • Define the non-prefixed variable in every environment AppSettings group where the renderer is deployed.
   • Remove or update any helper that still reads the NEXT_PUBLIC_ name or that still applies a hardcoded fallback value.

   export function buildSitefinityUrl(pathname: string, searchParams?: URLSearchParams): URL {
       const base = typeof window === 'undefined'
           ? new URL(process.env.SF_CMS_API as string)
           : new URL(window.location.origin);
       const url = new URL(pathname.replace(/^\/+/, ''), base);
       searchParams?.forEach((value, key) => url.searchParams.set(key, value));
       return url;
   }

2. Read the non-prefixed variable in a Server Component and pass it to client code as a prop.

   For example, read the value in the root layout and pass it into a provider or client component. Because the value is read on the server at request time, an AppSettings change is picked up after redeployment without requiring a rebuild.

   export default async function RootLayout({ children }: { children: React.ReactNode }) {
       const cmsApi = process.env.SF_CMS_API ?? '';
       return (<html><body><MyProvider cmsApi={cmsApi}>{children}</MyProvider></body></html>);
   }

3. Expose non-sensitive runtime configuration through a Route Handler.

   Create a server endpoint that returns only values that are safe to expose publicly, then fetch that endpoint from client-side code at runtime.

   // src/app/api/client-config/route.ts
   export const dynamic = 'force-dynamic';
   export async function GET() {
       return Response.json({ cmsApi: process.env.SF_CMS_API ?? '' });
   }

4. Commit the value to .env.production so it is present during next build.

   Use this only when the same public value is valid in every environment, because Sitefinity Cloud promotes one build artifact across environments. This also requires an intentional source-control exception because .env* files are usually ignored by default.

Do not use publicRuntimeConfig or serverRuntimeConfig for this scenario. These patterns are deprecated in Next.js and are not supported with React Server Components.

• Progress Community, [Sitefinity Cloud] Configurations: Override pipeline-managed appSettings https://community.progress.com/s/article/override-pipeline-managed-appsettings
• Progress Documentation, Manage the configurations https://www.progress.com/documentation/sitefinity-cms/cloud/develop-and-deploy/manage-the-configurations
• Progress Documentation, Deploy code changes https://www.progress.com/documentation/sitefinity-cms/cloud/develop-and-deploy/deploy-code-changes
• Progress Documentation, Set up Next.js renderer https://www.progress.com/documentation/sitefinity-cms/setup-next.js-renderer
• Next.js Documentation, Environment Variables https://nextjs.org/docs/app/guides/environment-variables