Based on the knowledge sources provided, I can answer your question about Ory Tunnel and custom domains. Ory Tunnel is not necessary when using custom domains with Ory Network. When you set up a custom domain for your Ory Network project, you can directly interact with the Ory APIs using that custom domain without the need for Ory Tunnel. This is evident from several sources: 1. [Integrate authentication into PHP](https://www.ory.sh/docs/getting-started/integrate-auth/php#go-to-production) mentions: "With the custom domain set up, you don't need to use Ory Proxy or Ory Tunnel to interact with Ory APIs. Instead, use the configured custom domain in your SDK calls" 2. Similar statements are found in the documentation for integrating authentication into [Go](https://www.ory.sh/docs/getting-started/integrate-auth/go#go-to-production), [Node.js/Express.js](https://www.ory.sh/docs/getting-started/integrate-auth/expressjs#go-to-production), and [ASP.NET](https://www.ory.sh/docs/getting-started/integrate-auth/dotnet#go-to-production). These sources consistently indicate that once you have set up a custom domain for your Ory Network project, you can directly use that domain in your API calls without the need for Ory Tunnel. It's worth noting that Ory Tunnel is still useful for local development, especially when working with

localhost

or

127.0.0.1

, as mentioned in the [Custom Domains guide](https://www.ory.sh/docs/guides/custom-domains): "For local development with

localhost/127.0.0.1

use [Ory Tunnel](https://www.ory.sh/docs/guides/cli/proxy-and-tunnel)." So, to directly answer your question: Ory Tunnel is not typically used with custom domains in production environments, as custom domains allow direct interaction with Ory APIs without the need for Ory Tunnel.

I understand your issue. It seems you're having trouble checking the session on localhost because you don't have access to the cookie set on your custom domain. This is indeed a common challenge when developing locally with a custom domain set up for Ory. Let me explain why this happens and how you can address it. The problem occurs because of the [Same-Origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) implemented by browsers, which prevents cookies set on one domain from being accessed by another domain. In your case, the cookie is set on your custom domain, but your local development environment is on

localhost

, which is considered a different origin. To solve this issue, you can use Ory Tunnel for local development. Ory Tunnel is specifically designed to help in such scenarios. Here's how you can use it: 1. Use Ory Tunnel for local development: As mentioned in the [Cookie-based security model](https://www.ory.sh/docs/security-model) documentation: "When developing locally, use either

localhost

or

127.0.0.1

, but not both. Although technically these mean the same thing, they're different cookie domains." The documentation further states: "The solution is to tunnel the Ory APIs on a port on your local machine, which allows cookies to be set on the same domain as the application is running." 2. Set up Ory Tunnel: You can set up Ory Tunnel using the Ory CLI. Here's an example command from the [Integrate authentication into Vue.js + API](https://www.ory.sh/docs/getting-started/integrate-auth/vue#install-ory-sdk-and-cli) guide:

ory tunnel --dev --project $PROJECT_SLUG \
     <http://localhost:3000>

This command will expose Ory APIs on

<http://localhost:4000>

. 3. Configure your application to use the tunneled URL: Update your application configuration to use the tunneled URL (typically `http://localhost:4000`) instead of your custom domain URL for API calls during local development. 4. Check the session: Now you should be able to check the session locally. Here's an example using the Ory SDK from the [Session Checks](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#session-checks) documentation:

javascript
   const frontend = new FrontendApi(
     new Configuration({
       basePath: "<http://localhost:4000>", // Use your local Ory Tunnel URL
       baseOptions: {
         withCredentials: true,
       },
     }),
   )

   frontend
     .toSession()
     .then(({ data: session }) => {
       // Session data available here
     })
     .catch((error) => {
       // Handle error
     })

By using Ory Tunnel, you're essentially mirroring your custom domain's Ory endpoints on your localhost, allowing you to work with sessions and cookies as if you were on the custom domain.

I understand your issue. It seems you're having trouble checking the session on localhost because you don't have access to the cookie set on your custom domain. This is indeed a common challenge when developing locally with a custom domain set up for Ory. Let me explain why this happens and how you can address it. The problem occurs because of the [Same-Origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) implemented by browsers, which prevents cookies set on one domain from being accessed by another domain. In your case, the cookie is set on your custom domain, but your local development environment is on

localhost

, which is considered a different origin. To solve this issue, you can use Ory Tunnel for local development. Ory Tunnel is specifically designed to help in such scenarios. Here's how you can use it: 1. Use Ory Tunnel for local development: As mentioned in the [Cookie-based security model](https://www.ory.sh/docs/security-model) documentation: "When developing locally, use either

localhost

or

127.0.0.1

, but not both. Although technically these mean the same thing, they're different cookie domains." The documentation further states: "The solution is to tunnel the Ory APIs on a port on your local machine, which allows cookies to be set on the same domain as the application is running." 2. Set up Ory Tunnel: You can set up Ory Tunnel using the Ory CLI. Here's an example command from the [Integrate authentication into Vue.js + API](https://www.ory.sh/docs/getting-started/integrate-auth/vue#install-ory-sdk-and-cli) guide:

ory tunnel --dev --project $PROJECT_SLUG \      <http://localhost:3000>

This command will expose Ory APIs on

<http://localhost:4000>

. 3. Configure your application to use the tunneled URL: Update your application configuration to use the tunneled URL (typically `http://localhost:4000`) instead of your custom domain URL for API calls during local development. 4. Check the session: Now you should be able to check the session locally. Here's an example using the Ory SDK from the [Session Checks](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#session-checks) documentation:

javascript    const frontend = new FrontendApi(      new Configuration({        basePath: "<http://localhost:4000>", // Use your local Ory Tunnel URL        baseOptions: {          withCredentials: true,        },      }),    )     frontend      .toSession()      .then(({ data: session }) => {        // Session data available here      })      .catch((error) => {        // Handle error      })

By using Ory Tunnel, you're essentially mirroring your custom domain's Ory endpoints on your localhost, allowing you to work with sessions and cookies as if you were on the custom domain. Remember, Ory Tunnel should only be used for local development. As stated in the [Local development](https://www.ory.sh/docs/getting-started/local-development#local-development) guide: "Ory Tunnel should be used for development only. Do not use Ory Tunnel in a production environment!" This approach should allow you to check sessions on your localhost while developing, even when your Ory project is set up with a custom domain.

I understand your frustration with encountering a CORS error when trying to use localhost with your custom domain setup. This is indeed a common issue, and I can explain why it's happening and how to address it. The CORS (Cross-Origin Resource Sharing) error occurs because Ory Network has strict CORS policies for security reasons, especially when using custom domains. As mentioned in the [CORS documentation for Ory Network](https://www.ory.sh/docs/guides/cors): "Ory Network doesn't allow setting the CORS origins to be

*

,

null

or

localhost/127.0.0.1

." This means that even when using Ory Tunnel for local development, you might still encounter CORS issues because

localhost

is not an allowed origin. To solve this problem, you have a few options: 1. Use a local domain instead of localhost: You can use a tool like [nip.io](https://nip.io/) or edit your hosts file to create a local domain that points to your localhost. Then, add this domain to your allowed CORS origins in the Ory Console. For example, you could use

<http://myapp.127.0.0.1.nip.io|myapp.127.0.0.1.nip.io>

instead of

localhost

. Then add

<https://myapp.127.0.0.1.nip.io>

to your allowed CORS origins. 2. Configure CORS for your custom domain: As stated in the [Custom Domains guide](https://www.ory.sh/docs/guides/custom-domains#cors): "It's important that you add CORS origins to your custom domain to ensure Single Page Applications (SPAs) support. Ory Network allows up to 50 origins." You can add your local development domain to the allowed CORS origins for your custom domain in the Ory Console. 3. Use the Ory CLI to update CORS settings: If you prefer using the CLI, you can update the CORS settings as shown in the [CORS documentation](https://www.ory.sh/docs/guides/cors):

ory patch project <your-project-id> \      --replace '/cors_public/enabled=true' \      --replace '/cors_public/origins=["https://*.<http://yourdomain.com|yourdomain.com>", "<https://myapp.127.0.0.1.nip.io>"]'

Replace

<your-project-id>

with your actual project ID and adjust the origins as needed. Remember, these changes are meant for development purposes only. In a production environment, you should use your custom domain directly without Ory Tunnel and ensure your CORS settings are appropriately restrictive. By implementing one of these solutions, you should be able to resolve the CORS error and continue with your local development using Ory Tunnel while maintaining the security benefits of your custom domain setup.