You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're integrating Ory Network with a Next.js 16 app using @ory/nextjs@1.0.0-rc.1 and @ory/elements-react@1.1.0. Our app runs in Kubernetes behind Traefik Proxy (not Vercel).
The problem: When NODE_ENV=production, all Ory auth flows (login, registration, recovery, verification) break. The browser is redirected to the raw NEXT_PUBLIC_ORY_SDK_URL (our Ory Network custom domain) instead of going through the app's middleware proxy. This results in 404s server-side and CORS errors client-side.
AI root cause findings:guessPotentiallyProxiedOrySdkUrl in @ory/nextjs short-circuits when isProduction() returns true — it returns orySdkUrl() immediately, before ever checking the knownProxiedUrl option. This means the host-header-derived URL (which the flow functions correctly pass as knownProxiedUrl: await getPublicUrl()) is never used in production. The only non-Vercel production path assumes the SDK URL should be used directly, which doesn't work when the app sits behind a reverse proxy that needs to proxy Ory API calls.
Notably, the middleware's proxyRequest function works correctly — it derives selfUrl from request headers. The issue is isolated to the server-side flow functions (getLoginFlow, etc.) and client-side @ory/elements-react components, which both rely on guessPotentiallyProxiedOrySdkUrl.
Current workaround: Setting NEXT_PUBLIC_NODE_ENV=development to trick isProduction() into returning false, which allows the knownProxiedUrl / window.location.origin code paths to execute. This works but is semantically incorrect and fragile.
Our ask: Is there a supported way to run @ory/nextjs in production behind a non-Vercel reverse proxy (e.g. Traefik, Nginx, HAProxy)?
Preflight checklist
Ory Network Project
https://busy-mayer-9wpd865lft.projects.oryapis.com
Describe the bug
Hi,
We're integrating Ory Network with a Next.js 16 app using
@ory/nextjs@1.0.0-rc.1and@ory/elements-react@1.1.0. Our app runs in Kubernetes behind Traefik Proxy (not Vercel).The problem: When
NODE_ENV=production, all Ory auth flows (login, registration, recovery, verification) break. The browser is redirected to the rawNEXT_PUBLIC_ORY_SDK_URL(our Ory Network custom domain) instead of going through the app's middleware proxy. This results in 404s server-side and CORS errors client-side.AI root cause findings:
guessPotentiallyProxiedOrySdkUrlin@ory/nextjsshort-circuits whenisProduction()returns true — it returnsorySdkUrl()immediately, before ever checking theknownProxiedUrloption. This means the host-header-derived URL (which the flow functions correctly pass asknownProxiedUrl: await getPublicUrl()) is never used in production. The only non-Vercel production path assumes the SDK URL should be used directly, which doesn't work when the app sits behind a reverse proxy that needs to proxy Ory API calls.Notably, the middleware's proxyRequest function works correctly — it derives selfUrl from request headers. The issue is isolated to the server-side flow functions (getLoginFlow, etc.) and client-side
@ory/elements-reactcomponents, which both rely onguessPotentiallyProxiedOrySdkUrl.Current workaround: Setting
NEXT_PUBLIC_NODE_ENV=developmentto trickisProduction()into returning false, which allows theknownProxiedUrl/window.location.origincode paths to execute. This works but is semantically incorrect and fragile.Our ask: Is there a supported way to run
@ory/nextjsin production behind a non-Vercel reverse proxy (e.g. Traefik, Nginx, HAProxy)?Environment:
@ory/nextjs@1.0.0-rc.1,@ory/elements-react@1.1.0Next.js 16 (standalone output, App Router)
Docker Compose + Traefik Proxy
NEXT_PUBLIC_ORY_SDK_URLpoints to our Ory Network custom domainScreen.Recording.2026-04-02.at.17.16.29.mov
Thanks for any guidance.
Reproducing the bug
See the video attached above
Relevant log output
Relevant configuration
Version
@ory/nextjs@1.0.0-rc.1 @ory/elements-react@1.1.0
On which operating system are you observing this issue?
None
In which environment are you deploying?
None
Additional Context
No response