Hey guys, I’m using Next.js v15 App Router and have implemented Ory with UI components, but I can’t get it to work properly. Here’s what’s happening: Production: After redirecting to

/auth/login

, I get a global error:

Root error boundary: Error: An error occurred in the Server Components render.

• Previously, there was also a CORS error, but after adding the production URL somewhere in the config, that one seems to be fixed. After build + `yarn start`: I’m redirected to

https://<PROD_URL>/self-service/login/browser?

Development: I was able to log in successfully for weeks at localhost:3000 • I’m not sure if I was using a tunnel, but it worked fine until I changed something in the Ory console — specifically under Custom UI URLs for Ory Kratos. • I changed it from

/ui/login

to

/auth/login

(now reverted), and since then I’ve been getting an error when trying to access the

/auth/login

page locally as well. The implementation follows this doc exactly: https://www.ory.com/docs/getting-started/integrate-auth/nextjs-app-router-quickstart Could you please help me out with that? 🙏

Hey @important-engineer-54926 The “admin” subdomain is just an example; you can use any subdomain, but

auth.

is a common convention for authentication endpoints. Your frontend (e.g., on Vercel) can remain on a separate domain or subdomain, but for cookies to work seamlessly, both should share the same root domain (e.g.,

<http://www.example.com|www.example.com>

and

<http://auth.example.com|auth.example.com>

) You can use any subdomain you prefer, but the key is that the subdomain you configure as your Ory custom domain is where Ory will serve its APIs and set cookies. After setting up your custom domain, you must explicitly add your frontend’s production URL(s) as allowed CORS origins in the Ory Console. In the Ory Console under Branding → UI URLs, set the base URL and paths for your custom UI (e.g.,

/auth/login

). If you see redirects to the default Ory domain, it usually means the custom domain is not set up correctly, or the SDK is still configured to use the default endpoint.

@magnificent-energy-493 So, we’re trying to understand why a custom domain and explicit CORS configuration are required in production when everything works fine locally without them. In our setup, we’re using the ory next sdk, which (as we understand it) proxies all client requests through our next server to ory meaning that, from the browser’s perspective, requests should only come from a single origin. If that’s the case, why would the browser encounter a CORS issue at all? Is there any scenario where the Ory SDK still makes direct browser-to-Ory calls, bypassing the proxy, which would explain the CORS error? Also, could you clarify whether setting a custom domain is strictly necessary for session cookies to work correctly in this setup, and what exactly changes between localhost and production in that regard? And if possible, could you explain what the SDK expects when the custom domain is misconfigured (e.g., why it would redirect to the default Ory domain instead of using the provided base path like

/auth/login

)?

Hello @important-engineer-54926

we’re trying to understand why a custom domain and explicit CORS configuration are required in production when everything works fine locally without them.

Local development works because Ory Tunnel mirror Ory APIs on your local machine, exposing them under the same domain (e.g.,

localhost

). This ensures cookies and CORS are not an issue, as both your app and Ory appear to be on the same origin to the browser. In production, your app and Ory APIs are on different domains. Browsers enforce strict same-origin policies, so cross-origin requests require explicit CORS headers and correct cookie domains.

clarify whether setting a custom domain is strictly necessary for session cookies to work correctly in this setup, and what exactly changes between localhost and production in that regard?

Ory can only set cookies for its own domain. If you use the default Ory domain (

*.<http://projects.oryapis.com|projects.oryapis.com>

), the browser will not send those cookies to your app's domain, breaking session management. By setting up a custom domain (e.g.,

<http://ory.example.com|ory.example.com>

), Ory can issue cookies for

<http://example.com|example.com>

If the custom domain is not set up or misconfigured, Ory will default to its own domain (

*.<http://projects.oryapis.com|projects.oryapis.com>

) for redirects and API calls. This can cause: • Redirects to the Ory domain instead of your app (breaking the flow). • Session cookies being set for the wrong domain (not accessible to your app). • CORS errors, since the browser sees cross-origin requests without the proper headers. I hope this makes it clearer. CORS is a common headache, but unfortunately we need to deal with it...

Hey @magnificent-energy-493, thanks again for your reply earlier. After further testing we found what seems to be the specific root cause of the production redirect issue. When running locally, the Ory Next.js SDK’s

guessPotentiallyProxiedOrySdkUrl()

resolves to

origin

, which correctly proxies requests through our Next.js middleware and everything works as expected. However, in production (where

NODE_ENV === "production"

), it switches to

orySdkUrl

, causing the browser to directly hit the Ory endpoint (

<http://projects.oryapis.com|projects.oryapis.com>

) instead of our app proxy. This explains the redirect to the hosted Ory UI and the CORS/session problems we’re seeing. This behavior makes sense if the app is hosted on a vercel.app domain (which Ory can detect), but in our case, while hosted on Azure it breaks the flow. We’re wondering: 1. Is this switch between

origin

and

orySdkUrl

intentional, or is it a known issue / limitation in the SDK? 2. Would it be safe to override

guessPotentiallyProxiedOrySdkUrl

or force it to always use

origin

in our setup (since all requests are proxied through Next middleware)? 3. If our proxy works properly and the browser never talks directly to Ory, is a custom domain still strictly required for cookies and session handling? 4. Do you plan to make this logic configurable for non-Vercel deployments in future releases? Here’s a GitHub issue that describes a nearly identical problem: 🔗 https://github.com/ory/elements/issues/572 We’d really appreciate your insight or confirmation on whether this is an SDK bug or just an unsupported deployment pattern. Thanks again 🙏

Hey Marek, I haven't seen

guessPotentiallyProxiedOrySdkUrl

before but you should be able to always use

orySdkUrl

or override it.

If our proxy works properly and the browser never talks directly to Ory, is a custom domain still strictly required for cookies and session handling?

I don't really understand what you mean by proxy, but I think you definitely want to use a custom domain. There might be hacks/workarounds but those are not tested and can break.

Do you plan to make this logic configurable for non-Vercel deployments in future releases?

That would be good probably! I'm not sure how big the portion of non-Vercel users is for Next.js but probably not insubstantial. @bland-eye-99092 sorry for the ping but you worked on this maybe you have a better answer 😅

The guessing really is a little bit of a best effort piece and we assumed there are many more cases, that it does not cover. I don't think we have the experience with your type of setup, so any solution would have to be somewhat collaborative. Appreciate any ideas how to solve your use case and we can look into a better solution. So yes, this is currently an unsupported deployment pattern, but we are very happy to add support for it 🙂

Hey @bland-eye-99092, one of Marek's colleagues here. I added to the issue linked above: https://github.com/ory/elements/issues/572#issuecomment-3444199737

Sorry - we're currently working on a few other things, I'll get back to you in the coming weeks, to address this issue. Thanks for you patience! ❤️