What this usually means
Browsers enforce strict rules about cookies: domain, path, Secure flag, SameSite attribute, and HttpOnly. If your deployment changes any of these — intentionally or not — the browser may stop sending the cookie. Even if the attribute values look the same, a change in how the cookie is set (different `Set-Cookie` header order, different domain format) can cause the browser to treat it as a new, unrelated cookie. Additionally, if the session store (Redis, database) was restarted or cleared during deployment, all existing sessions are invalid.
The first ten minutes \u2014 establish facts before touching code.
- 1Open browser DevTools → Application → Cookies. Is the session cookie present? Check its domain, path, Secure, HttpOnly, and SameSite values.
- 2Check the `Set-Cookie` header in the login response. Does the domain match the current page's domain exactly?
- 3Check if the cookie's Secure flag is set but the site is served over HTTP in the new deployment.
- 4Check the session store. If using Redis or a database for sessions, is it still running? Are the old sessions still there?
- 5Check if the deployment changed the cookie name, secret, or signing key. A different session secret invalidates all existing cookies.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchBrowser DevTools — Application → Cookies → check presence, attributes, and value
- searchNetwork tab — `Set-Cookie` response header on login or any authenticated request
- searchServer session configuration — cookie name, secret, maxAge, domain, path, secure, sameSite
- searchSession store — Redis, database, or in-memory — is it up and does it contain sessions?
- searchDeployment diff — did any session or cookie configuration change?
- searchReverse proxy / CDN — is it stripping or modifying `Set-Cookie` or `Cookie` headers?
Practical causes, not theory. These are the things you will actually find.
- warningCookie domain changed: old was `example.com`, new is `.example.com` or `api.example.com`
- warningSecure flag is now `true` but the site is served over HTTP (or vice versa in local dev)
- warningSameSite attribute changed to `Strict` or `None` — `None` requires Secure
- warningCookie path changed — cookies set with `path=/api` are not sent to `/dashboard`
- warningSession secret or signing key changed during deployment — old cookies cannot be decrypted
- warningSession store was cleared or restarted during deployment
- warningDeployment switched from subdomain to apex domain (or vice versa) without updating cookie domain
- warningCDN or reverse proxy strips `Set-Cookie` headers from responses
Concrete fix directions. Pick the one that matches your root cause.
- buildSet the cookie domain explicitly to the apex domain with a leading dot (`.example.com`) to work across subdomains
- buildSet `Secure=true` in production and `Secure=false` in local development — use environment detection
- buildSet `SameSite=Lax` as a reasonable default — it works for most navigation-based sessions
- buildNever rotate the session secret without a transition period — support old and new secrets simultaneously
- buildPersist session data in an external store (Redis) so sessions survive application restarts and deployments
A fix you cannot prove is a guess. Close the loop.
- verifiedDeploy to staging. Log in. Check the cookie is set and sent with subsequent requests.
- verifiedAfter deploy, verify existing sessions still work — users should not be logged out.
- verifiedTest with the cookie Secure flag both on and off to confirm the environment-specific logic.
- verifiedTest from a different subdomain if your app spans subdomains.
- verifiedUse an incognito/private window to rule out stale cookies from previous configurations.
Things that make this bug worse or harder to find.
- warningNot testing cookie behaviour in a staging environment that mirrors production
- warningRotating the session secret without a transition period
- warningSetting `SameSite=None` without the Secure flag — browsers reject this combination
- warningNot setting an explicit cookie domain — behaviour varies between browsers when domain is omitted
- warningStoring sessions in memory — they are lost on every deployment and every server restart