Cookies disappear on web app after refresh in production with Turborepo setup using better-auth #1681

Closed
opened 2026-03-13 08:55:32 -05:00 by GiteaMirror · 20 comments
Owner

Originally created by @NicolasCassunde on GitHub (Aug 11, 2025).

I have a Turborepo monorepo with two apps:

apps/server — handles backend and authentication

apps/web — frontend app consuming the auth API from the server

All my better-auth configuration is centralized in a shared package at packages/db.

Issue:

On localhost, everything works perfectly — authentication cookies are set and persist on both server and web apps, even after page refresh.

In production, the cookies are correctly set initially, but after refreshing the page in the web app, the authentication cookies disappear and the user session is lost.

Interestingly, on the server side the cookies persist correctly after refresh.

Auth configuration (auth.ts):

`import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import { db } from "@repo/db/db/index";
import * as schema from "../db/db/schema/auth";
import { emailOTP } from "better-auth/plugins";

export const auth = betterAuth({
database: drizzleAdapter(db, {
provider: "pg",
schema: schema,
}),
trustedOrigins: [
process.env.CORS_ORIGIN!
],
emailAndPassword: {
enabled: true,
},
plugins: [
emailOTP({
async sendVerificationOTP({ email, otp, type }) {
console.log({ email, otp, type });
// Implement sending OTP email here
},
}),
],
advanced: {
cookies: {
session_token: {
attributes: {
sameSite: "none",
secure: true,
httpOnly: true,
},
},
},
},
secret: process.env.BETTER_AUTH_SECRET,
baseURL: process.env.BETTER_AUTH_URL,
});`

DATABASE_URL=database_url
CORS_ORIGIN=https://turborepo-web-eta.vercel.app # localhost:3001 (web) in dev
BETTER_AUTH_SECRET=betterauthsecret
BETTER_AUTH_URL=https://turborepo-server-rbj2.vercel.app # localhost:3000 (server) in dev

Originally created by @NicolasCassunde on GitHub (Aug 11, 2025). I have a Turborepo monorepo with two apps: apps/server — handles backend and authentication apps/web — frontend app consuming the auth API from the server All my better-auth configuration is centralized in a shared package at packages/db. Issue: On localhost, everything works perfectly — authentication cookies are set and persist on both server and web apps, even after page refresh. In production, the cookies are correctly set initially, but after refreshing the page in the web app, the authentication cookies disappear and the user session is lost. Interestingly, on the server side the cookies persist correctly after refresh. Auth configuration (auth.ts): `import { betterAuth } from "better-auth"; import { drizzleAdapter } from "better-auth/adapters/drizzle"; import { db } from "@repo/db/db/index"; import * as schema from "../db/db/schema/auth"; import { emailOTP } from "better-auth/plugins"; export const auth = betterAuth({ database: drizzleAdapter(db, { provider: "pg", schema: schema, }), trustedOrigins: [ process.env.CORS_ORIGIN! ], emailAndPassword: { enabled: true, }, plugins: [ emailOTP({ async sendVerificationOTP({ email, otp, type }) { console.log({ email, otp, type }); // Implement sending OTP email here }, }), ], advanced: { cookies: { session_token: { attributes: { sameSite: "none", secure: true, httpOnly: true, }, }, }, }, secret: process.env.BETTER_AUTH_SECRET, baseURL: process.env.BETTER_AUTH_URL, });` DATABASE_URL=database_url CORS_ORIGIN=https://turborepo-web-eta.vercel.app # localhost:3001 (web) in dev BETTER_AUTH_SECRET=betterauthsecret BETTER_AUTH_URL=https://turborepo-server-rbj2.vercel.app # localhost:3000 (server) in dev
GiteaMirror added the bug label 2026-03-13 08:55:32 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Aug 11, 2025):

Hi @NicolasCassunde! I'm Dosu and I’m helping the better-auth team.

For cross-origin cookies to persist in production with better-auth, you need all of these: cookies set with SameSite=None and Secure=true, CORS configured to allow credentials, credentials: 'include' in frontend requests, and your frontend domain listed in trustedOrigins in your auth config (docs).

Since cookies disappear after refresh only on the web app, check for these common issues: both frontend and backend must use HTTPS (no http/https mismatch), the cookie domain attribute should match your deployment (for subdomains, set domain: ".yourdomain.com" and enable crossSubDomainCookies if needed), and your CDN/proxy (like Vercel or Cloudflare) must not strip or rewrite cookie headers. Use browser dev tools to inspect the actual Set-Cookie and Cookie headers after login and refresh, and look for any browser warnings about cookies or CORS.

If everything looks correct, consider enabling debug logging in better-auth and your deployment platform to capture more details about cookie handling. There was a recent bug in better-auth that caused session cookies to be cleared sporadically, but it’s been fixed as of July 2025 (PR #3283). If you’re on a recent version, this shouldn’t be the cause.

Let me know if you spot anything unusual in the headers or browser console, or if you need help with a specific config!

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 11, 2025): <!-- Greeting --> Hi @NicolasCassunde! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> For cross-origin cookies to persist in production with better-auth, you need all of these: cookies set with `SameSite=None` and `Secure=true`, CORS configured to allow credentials, `credentials: 'include'` in frontend requests, and your frontend domain listed in `trustedOrigins` in your auth config ([docs](https://better-auth.com/docs/concepts/cookies)). Since cookies disappear after refresh only on the web app, check for these common issues: both frontend and backend must use HTTPS (no http/https mismatch), the cookie domain attribute should match your deployment (for subdomains, set `domain: ".yourdomain.com"` and enable `crossSubDomainCookies` if needed), and your CDN/proxy (like Vercel or Cloudflare) must not strip or rewrite cookie headers. Use browser dev tools to inspect the actual `Set-Cookie` and `Cookie` headers after login and refresh, and look for any browser warnings about cookies or CORS. If everything looks correct, consider enabling debug logging in better-auth and your deployment platform to capture more details about cookie handling. There was a recent bug in better-auth that caused session cookies to be cleared sporadically, but it’s been fixed as of July 2025 ([PR #3283](https://github.com/better-auth/better-auth/pull/3283)). If you’re on a recent version, this shouldn’t be the cause. Let me know if you spot anything unusual in the headers or browser console, or if you need help with a specific config! <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/6214b270-9c28-4f9a-a833-26fc961e7ff6?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/6214b270-9c28-4f9a-a833-26fc961e7ff6?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/6214b270-9c28-4f9a-a833-26fc961e7ff6?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/6214b270-9c28-4f9a-a833-26fc961e7ff6?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/6214b270-9c28-4f9a-a833-26fc961e7ff6?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/6214b270-9c28-4f9a-a833-26fc961e7ff6?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/6214b270-9c28-4f9a-a833-26fc961e7ff6?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3938)
Author
Owner

@ping-maxwell commented on GitHub (Aug 12, 2025):

server side the cookies persist correctly after refresh.

What do you mean?

Also, what method were you using to testing? signInEmail? Social sign in?

@ping-maxwell commented on GitHub (Aug 12, 2025): > server side the cookies persist correctly after refresh. What do you mean? Also, what method were you using to testing? signInEmail? Social sign in?
Author
Owner

@numfin commented on GitHub (Oct 9, 2025):

Cookies cleared after refreshing page

Image
@numfin commented on GitHub (Oct 9, 2025): Cookies cleared after refreshing page <img width="2532" height="443" alt="Image" src="https://github.com/user-attachments/assets/74920204-ee9e-4427-b37c-c5ef0f1fe377" />
Author
Owner

@ping-maxwell commented on GitHub (Oct 10, 2025):

Hey @numfin given how situational these types of issues are, can you open a separate issue with details of your setup?

@ping-maxwell commented on GitHub (Oct 10, 2025): Hey @numfin given how situational these types of issues are, can you open a separate issue with details of your setup?
Author
Owner

@krystianwitkowski commented on GitHub (Oct 12, 2025):

@numfin

Did you resolved this issue ? I have the same problem on production railway, during login session is creating on the server and browser getting http response with Set-Cookie, session token and session data are visible but after refresh browser they disappear.

@krystianwitkowski commented on GitHub (Oct 12, 2025): @numfin Did you resolved this issue ? I have the same problem on production railway, during login session is creating on the server and browser getting http response with Set-Cookie, session token and session data are visible but after refresh browser they disappear.
Author
Owner

@numfin commented on GitHub (Oct 14, 2025):

@krystianwitkowski no, im using this lib for demo. Not for production. I just switched for more reliable solution, that at least can log the problem. Unfortunately this lib just doesn't work and not even telling why

@numfin commented on GitHub (Oct 14, 2025): @krystianwitkowski no, im using this lib for demo. Not for production. I just switched for more reliable solution, that at least can log the problem. Unfortunately this lib just doesn't work and not even telling why
Author
Owner

@krystianwitkowski commented on GitHub (Oct 14, 2025):

I solved my problem. In my case it was problem with domains. My frontend and backend service were hosted on different domains default by railway public adress IP. I set my custom domain on frontend like example.com and for backend I have to create subdomain like api.backend.com and add of course DNS records for this domains. The services must be in the same domains to save cookies.

@krystianwitkowski commented on GitHub (Oct 14, 2025): I solved my problem. In my case it was problem with domains. My frontend and backend service were hosted on different domains default by railway public adress IP. I set my custom domain on frontend like example.com and for backend I have to create subdomain like api.backend.com and add of course DNS records for this domains. The services must be in the same domains to save cookies.
Author
Owner

@ping-maxwell commented on GitHub (Oct 14, 2025):

server side the cookies persist correctly after refresh.

What do you mean?

Also, what method were you using to testing? signInEmail? Social sign in?

Hey @NicolasCassunde is this still an issue on your end?

@ping-maxwell commented on GitHub (Oct 14, 2025): > > server side the cookies persist correctly after refresh. > > What do you mean? > > Also, what method were you using to testing? signInEmail? Social sign in? Hey @NicolasCassunde is this still an issue on your end?
Author
Owner

@MarkForLoop commented on GitHub (Oct 15, 2025):

@ping-maxwell

I ran into the same issue (I am using JWT plugin)

Setup:
Frontend using TanStack Router on https://example.com
API using Hono running on https://api.example.com

Everything worked locally, but in production, the cookies were cleared on page refresh even though login initially succeeded

I think its cause my browsers is blocking cookies between subdomains

@MarkForLoop commented on GitHub (Oct 15, 2025): @ping-maxwell I ran into the same issue (I am using JWT plugin) Setup: Frontend using TanStack Router on https://example.com API using Hono running on https://api.example.com Everything worked locally, but in production, the cookies were cleared on page refresh even though login initially succeeded I think its cause my browsers is blocking cookies between subdomains
Author
Owner

@ping-maxwell commented on GitHub (Oct 16, 2025):

@MarkForLoop mind opening a separate issue and then linking it to me?

@ping-maxwell commented on GitHub (Oct 16, 2025): @MarkForLoop mind opening a separate issue and then linking it to me?
Author
Owner

@ping-maxwell commented on GitHub (Oct 21, 2025):

I'm closing this issue as no response from OP was given. Happy to reopen if needed!

@ping-maxwell commented on GitHub (Oct 21, 2025): I'm closing this issue as no response from OP was given. Happy to reopen if needed!
Author
Owner

@Akash1000x commented on GitHub (Nov 1, 2025):

anyone find the solution for this ?

@Akash1000x commented on GitHub (Nov 1, 2025): anyone find the solution for this ?
Author
Owner

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025):

It sounds like the issue is that the cookies set by your auth server aren’t aligning with the frontend’s domain in production. A few steps to troubleshoot and fix this:

  1. Verify that the cookie attributes (SameSite set to “none” and secure flag enabled) correctly match your production environment (i.e. using HTTPS consistently). Browsers require SameSite “none” cookies to be secure [1].

  2. Check the cookie domain and path settings. Since your backend (auth server) and web app are on different subdomains, you may need to set the cookie’s domain explicitly or enable cross‐subdomain cookies. For example, adding a crossSubDomainCookies option in your advanced settings (with the proper domain) can help the browser share the cookie between the server’s domain and the web app domain [2].

  3. Confirm that the trustedOrigins includes the exact production origin of your web app and that no CORS misconfigurations are causing the cookie to be dropped after refresh [1].

  4. Use your browser’s developer tools to inspect the cookies on page load versus after refresh. Check if any cookie attributes are altered or missing.

Following these steps should help pinpoint whether the cookie’s domain/path or a cross-site setting is causing the disappearance. Adjust your Better Auth configuration accordingly.

DiagramDiscordGitHub

Diagram Join Star

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025): It sounds like the issue is that the cookies set by your auth server aren’t aligning with the frontend’s domain in production. A few steps to troubleshoot and fix this: 1. Verify that the cookie attributes (SameSite set to “none” and secure flag enabled) correctly match your production environment (i.e. using HTTPS consistently). Browsers require SameSite “none” cookies to be secure [[1]](https://github.com/better-auth/better-auth/issues/3938). 2. Check the cookie domain and path settings. Since your backend (auth server) and web app are on different subdomains, you may need to set the cookie’s domain explicitly or enable cross‐subdomain cookies. For example, adding a crossSubDomainCookies option in your advanced settings (with the proper domain) can help the browser share the cookie between the server’s domain and the web app domain [[2]](https://github.com/better-auth/better-auth/issues/4570). 3. Confirm that the trustedOrigins includes the exact production origin of your web app and that no CORS misconfigurations are causing the cookie to be dropped after refresh [[1]](https://github.com/better-auth/better-auth/issues/3938). 4. Use your browser’s developer tools to inspect the cookies on page load versus after refresh. Check if any cookie attributes are altered or missing. Following these steps should help pinpoint whether the cookie’s domain/path or a cross-site setting is causing the disappearance. Adjust your Better Auth configuration accordingly. <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
Author
Owner

@MarkForLoop commented on GitHub (Nov 1, 2025):

@Akash1000x in my case, I had to add this into the auth.ts file:

    advanced: {
      crossSubDomainCookies: {
        enabled: true,
        domain: "example.com",  // root domain of ur domain
      },
      defaultCookieAttributes: {
        sameSite: "none",
        secure: true,
        httpOnly: true,
        partitioned: true,
      },
    },

which was referenced here: https://www.better-auth.com/docs/integrations/hono#cross-domain-cookies

@MarkForLoop commented on GitHub (Nov 1, 2025): @Akash1000x in my case, I had to add this into the auth.ts file: ```ts advanced: { crossSubDomainCookies: { enabled: true, domain: "example.com", // root domain of ur domain }, defaultCookieAttributes: { sameSite: "none", secure: true, httpOnly: true, partitioned: true, }, }, ``` which was referenced here: https://www.better-auth.com/docs/integrations/hono#cross-domain-cookies
Author
Owner

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025):

It appears this issue is due to cookie configuration that isn’t fully aligned with the production domain setup. Here are the next steps to troubleshoot and resolve the problem:

• Verify that your production environment uses the correct root domain for cookies. In production, set up cross‐subdomain cookies by enabling the option and specifying your root domain. For example:

  advanced: {
   crossSubDomainCookies: {
    enabled: true,
    domain: "your-root-domain.com" // set this to your actual root domain
   },
   defaultCookieAttributes: {
    sameSite: "none",
    secure: true,
    httpOnly: true,
    partitioned: true // sometimes necessary with modern browser policies
   },
  }

• Make sure your CORS_ORIGIN environment variable exactly matches the frontend URL in production.

• Confirm that your BETTER_AUTH_URL (the server’s URL) and baseURL are set correctly. Mismatches here can lead to cookies not persisting on the client.

• Test the configuration by logging in on production and checking whether the cookies (with the custom domain and attributes) are correctly set and retained on refresh.

These adjustments are in line with recommended settings for cross-domain cookies in production setups where the backend and frontend are on different subdomains [1] [2]. If the issue persists, double-check any reverse proxy or caching settings in your hosting platform that might inadvertently strip or block cookie headers.

Let me know if you need further assistance.

DiagramDiscordGitHub

Diagram Join Star

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025): It appears this issue is due to cookie configuration that isn’t fully aligned with the production domain setup. Here are the next steps to troubleshoot and resolve the problem: • Verify that your production environment uses the correct root domain for cookies. In production, set up cross‐subdomain cookies by enabling the option and specifying your root domain. For example:   advanced: {    crossSubDomainCookies: {     enabled: true,     domain: "your-root-domain.com" // set this to your actual root domain    },    defaultCookieAttributes: {     sameSite: "none",     secure: true,     httpOnly: true,     partitioned: true // sometimes necessary with modern browser policies    },   } • Make sure your CORS_ORIGIN environment variable exactly matches the frontend URL in production. • Confirm that your BETTER_AUTH_URL (the server’s URL) and baseURL are set correctly. Mismatches here can lead to cookies not persisting on the client. • Test the configuration by logging in on production and checking whether the cookies (with the custom domain and attributes) are correctly set and retained on refresh. These adjustments are in line with recommended settings for cross-domain cookies in production setups where the backend and frontend are on different subdomains [[1]](https://github.com/better-auth/better-auth/issues/3938) [[2]](https://github.com/better-auth/better-auth/issues/4570). If the issue persists, double-check any reverse proxy or caching settings in your hosting platform that might inadvertently strip or block cookie headers. Let me know if you need further assistance. <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
Author
Owner

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025):

Based on similar reported cases, the disappearing cookie issue in production is most likely due to how cross-domain cookies are handled. In production your frontend and backend live on different subdomains, so you’ll want to explicitly enable cross-subdomain cookies and ensure the cookie attributes (including SameSite, Secure, httpOnly, and Partitioned) are set appropriately. Here’s what to do:

• Update your auth configuration to include an advanced section that enables cross-subdomain cookies by specifying your root domain. For example, add something like:

 advanced: {
  crossSubDomainCookies: {
   enabled: true,
   domain: "example.com" // Replace with your root domain
  },
  defaultCookieAttributes: {
   sameSite: "none",
   secure: true,
   httpOnly: true,
   partitioned: true
  }
 }

This adjustment ensures that the cookies are recognized across subdomains in production [1].

• Verify your CORS settings on both the backend and the client. The backend (server app) should trust the client’s origin and allow credentials (cookies) to be sent, and your client requests need to include credentials (for instance, by setting fetch’s credentials to "include") [2].

• Double-check that your environment variables (such as BETTER_AUTH_URL and CORS_ORIGIN) correctly reflect your production domains.

• Finally, test in production to see if the cookies persist on page refresh after these changes.

These steps should address the issue of cookies disappearing on your web app after refresh. Let me know if you need further assistance.

DiagramDiscordGitHub

Diagram Join Star

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025): Based on similar reported cases, the disappearing cookie issue in production is most likely due to how cross-domain cookies are handled. In production your frontend and backend live on different subdomains, so you’ll want to explicitly enable cross-subdomain cookies and ensure the cookie attributes (including SameSite, Secure, httpOnly, and Partitioned) are set appropriately. Here’s what to do: • Update your auth configuration to include an advanced section that enables cross-subdomain cookies by specifying your root domain. For example, add something like:    advanced: {   crossSubDomainCookies: {    enabled: true,    domain: "example.com" // Replace with your root domain   },   defaultCookieAttributes: {    sameSite: "none",    secure: true,    httpOnly: true,    partitioned: true   }  }   This adjustment ensures that the cookies are recognized across subdomains in production [[1]](https://github.com/better-auth/better-auth/issues/3938). • Verify your CORS settings on both the backend and the client. The backend (server app) should trust the client’s origin and allow credentials (cookies) to be sent, and your client requests need to include credentials (for instance, by setting fetch’s credentials to "include") [[2]](https://www.better-auth.com/docs/concepts/cookies). • Double-check that your environment variables (such as BETTER_AUTH_URL and CORS_ORIGIN) correctly reflect your production domains. • Finally, test in production to see if the cookies persist on page refresh after these changes. These steps should address the issue of cookies disappearing on your web app after refresh. Let me know if you need further assistance. <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
Author
Owner

@Akash1000x commented on GitHub (Nov 1, 2025):

@Akash1000x in my case, I had to add this into the auth.ts file:

advanced: {
  crossSubDomainCookies: {
    enabled: true,
    domain: "example.com",  // root domain of ur domain
  },
  defaultCookieAttributes: {
    sameSite: "none",
    secure: true,
    httpOnly: true,
    partitioned: true,
  },
},

which was referenced here: https://www.better-auth.com/docs/integrations/hono#cross-domain-cookies

Thanks, btw no need to add crossSubDomainCookies

I added this and it worked for me ->

advanced: {
    cookies: {
      session_token: {
        attributes: {
          sameSite: "none",
          secure: true,
          httpOnly: true,
        },
      },
    },
  }
@Akash1000x commented on GitHub (Nov 1, 2025): > [@Akash1000x](https://github.com/Akash1000x) in my case, I had to add this into the auth.ts file: > > advanced: { > crossSubDomainCookies: { > enabled: true, > domain: "example.com", // root domain of ur domain > }, > defaultCookieAttributes: { > sameSite: "none", > secure: true, > httpOnly: true, > partitioned: true, > }, > }, > which was referenced here: https://www.better-auth.com/docs/integrations/hono#cross-domain-cookies Thanks, btw no need to add `crossSubDomainCookies` I added this and it worked for me -> ``` advanced: { cookies: { session_token: { attributes: { sameSite: "none", secure: true, httpOnly: true, }, }, }, } ```
Author
Owner

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025):

Based on your description and configuration, here are some troubleshooting steps:

  1. Double-check that your production URLs are correctly set. For instance, ensure that the CORS_ORIGIN and BETTER_AUTH_URL point to your production domains and that both apps are served over HTTPS. Secure cookie attributes like sameSite:"none" and secure:true work only under HTTPS [1].

  2. Although you mentioned not needing cross-subdomain cookies, verify that your cookies aren’t being dropped because of domain mismatches. If your server and web app use different subdomains, consider adding a domain attribute (or enabling crossSubDomainCookies) so that the cookie is valid for both, even if you decide not to use it ultimately [2].

  3. Inspect the Set-Cookie headers with your browser dev tools. Confirm that the cookie’s attributes (sameSite, secure, httpOnly) are correctly applied, and that there are no redirections or intermediary caching (by Vercel or a proxy) that might be interfering with the cookie being re-sent on refresh [3].

  4. Check your server’s CORS settings and ensure credentials are enabled on both client and server so cookies are properly sent with each request [1].

By verifying these points, you should be able to pinpoint why the cookie disappears on refresh in production. If the issue persists, consider enabling additional logging on both server and client to watch the lifecycle of the cookie on each request.

DiagramDiscordGitHub

Diagram Join Star

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025): Based on your description and configuration, here are some troubleshooting steps: 1. Double-check that your production URLs are correctly set. For instance, ensure that the CORS_ORIGIN and BETTER_AUTH_URL point to your production domains and that both apps are served over HTTPS. Secure cookie attributes like sameSite:"none" and secure:true work only under HTTPS [[1]](https://github.com/better-auth/better-auth/issues/3938). 2. Although you mentioned not needing cross-subdomain cookies, verify that your cookies aren’t being dropped because of domain mismatches. If your server and web app use different subdomains, consider adding a domain attribute (or enabling crossSubDomainCookies) so that the cookie is valid for both, even if you decide not to use it ultimately [[2]](https://www.better-auth.com/docs/concepts/cookies). 3. Inspect the Set-Cookie headers with your browser dev tools. Confirm that the cookie’s attributes (sameSite, secure, httpOnly) are correctly applied, and that there are no redirections or intermediary caching (by Vercel or a proxy) that might be interfering with the cookie being re-sent on refresh [[3]](https://www.better-auth.com/docs/reference/security). 4. Check your server’s CORS settings and ensure credentials are enabled on both client and server so cookies are properly sent with each request [[1]](https://github.com/better-auth/better-auth/issues/3938). By verifying these points, you should be able to pinpoint why the cookie disappears on refresh in production. If the issue persists, consider enabling additional logging on both server and client to watch the lifecycle of the cookie on each request. <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
Author
Owner

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025):

Based on similar cases, here are some next steps to troubleshoot the disappearing cookies in production:

• Confirm that your production domains align precisely with your configuration. In production the authentication cookies are set on the server’s domain (from BETTER_AUTH_URL) but must also be valid for the web app’s domain (CORS_ORIGIN). If these don’t match, the browser may drop the cookie. Check that your domains (and any required root domains) are configured correctly.

• Verify that your client fetches (or any cookie‑using requests) include credentials (for example, using credentials: "include"). Without that the cookies won’t be sent back on subsequent requests, leading to the appearance of disappearing cookies.

• Double‑check that your cookie settings in the advanced configuration are not accidentally being overwritten by a default. In some cases, you may try setting defaultCookieAttributes along with your cookies configuration (ensuring sameSite is "none", secure is true, and httpOnly true) to ensure that the cookies are always saved when served over HTTPS. Although some have suggested using crossSubDomainCookies, if you don’t need subdomain sharing, sticking with your current configuration may be best.

• Finally, review any intermediary caching or reverse proxy (e.g. Vercel settings) that might modify or drop cookie headers, especially if the cookies persist on your server but vanish on the client.

Following these steps should help you pinpoint if the issue is due to domain mismatch, request credential settings, or intermediary caching. Let me know if you need further assistance. [1][2]

DiagramDiscordGitHub

Diagram Join Star

@better-auth-agent[bot] commented on GitHub (Nov 1, 2025): Based on similar cases, here are some next steps to troubleshoot the disappearing cookies in production: • Confirm that your production domains align precisely with your configuration. In production the authentication cookies are set on the server’s domain (from BETTER_AUTH_URL) but must also be valid for the web app’s domain (CORS_ORIGIN). If these don’t match, the browser may drop the cookie. Check that your domains (and any required root domains) are configured correctly. • Verify that your client fetches (or any cookie‑using requests) include credentials (for example, using credentials: "include"). Without that the cookies won’t be sent back on subsequent requests, leading to the appearance of disappearing cookies. • Double‑check that your cookie settings in the advanced configuration are not accidentally being overwritten by a default. In some cases, you may try setting defaultCookieAttributes along with your cookies configuration (ensuring sameSite is "none", secure is true, and httpOnly true) to ensure that the cookies are always saved when served over HTTPS. Although some have suggested using crossSubDomainCookies, if you don’t need subdomain sharing, sticking with your current configuration may be best. • Finally, review any intermediary caching or reverse proxy (e.g. Vercel settings) that might modify or drop cookie headers, especially if the cookies persist on your server but vanish on the client. Following these steps should help you pinpoint if the issue is due to domain mismatch, request credential settings, or intermediary caching. Let me know if you need further assistance. [[1]](https://github.com/better-auth/better-auth/issues/3938)[[2]](https://www.better-auth.com/docs/concepts/cookies) <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
Author
Owner

@adityarestuhudayana commented on GitHub (Feb 25, 2026):

advanced: {
crossSubDomainCookies: {
enabled: true,
domain: "example.com", // root domain of ur domain
},
defaultCookieAttributes: {
sameSite: "none",
secure: true,
httpOnly: true,
partitioned: true,
},
},

omg iam stuck for 2 days and it help thanks

@adityarestuhudayana commented on GitHub (Feb 25, 2026): > advanced: { > crossSubDomainCookies: { > enabled: true, > domain: "example.com", // root domain of ur domain > }, > defaultCookieAttributes: { > sameSite: "none", > secure: true, > httpOnly: true, > partitioned: true, > }, > }, omg iam stuck for 2 days and it help thanks
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1681