TL;DR — A custom session-cookie login flow appeared to succeed on localhost (the OTP verified, the response looked fine) but every subsequent request to a login-gated page treated the visitor as logged out. Identical code worked fine on the live HTTPS site. The cookie's Secure attribute was hardcoded to true — and per the cookie spec, browsers never store or send a Secure cookie over a plain, non-HTTPS connection.

Diagnostic

Check the actual Set-Cookie response header and the browser's own cookie storage panel — on localhost over http://, the cookie is sent by the server but never actually stored by the browser.

Root cause

// before -- assumes the app is always served over HTTPS
setCookie("session", token, { secure: true, httpOnly: true });

A cookie config that quietly assumes "we're always on HTTPS" breaks the instant you test over plain HTTP, which local dev servers commonly are.

Fix

// after -- derive secure from the actual request protocol
const isHttps = request.url.startsWith("https://");
setCookie("session", token, { secure: isHttps, httpOnly: true });

Lessons learned

• Any Secure-flagged cookie needs to key off the real request scheme, not an assumption baked in once at cookie-creation time.
• "Works in production, silently fails in local dev" is a strong signal to check cookie flags before anything else in an auth flow.
• Check other cookies in the same codebase for the same hardcoded assumption — if one cookie has this bug, sibling cookies set the same way are worth auditing too.

TL;DR — Deploying to shared hosting failed during npm install while a native addon (better-sqlite3) tried to compile via node-gyp, tripping over the host's old glibc/Python toolchain — neither of which can be upgraded on shared hosting. The actual fix was realizing the native module wasn't even needed at runtime anymore, and skipping its build step entirely.

Symptom

Install fails specifically inside the native module's own postinstall build step — a node-gyp/compiler error tied to the host's old system Python/glibc versions, not a normal dependency-resolution failure.

Root cause

Shared hosting gives no control over the system Python/compiler toolchain node-gyp needs to compile a native addon. In this project, the database adapter had already moved to a different backend (Turso/libsql, then Postgres) at runtime — so the native SQLite binding wasn't actually load-bearing anymore, just still listed as a dependency whose build script fires on every install.

Fix

.npmrc
ignore-scripts=true

This skips all install-time build scripts, including the native compile step — safe here specifically because nothing at runtime still depends on that native binary.

Lessons learned

• ignore-scripts=true skips every package's install scripts, not just the offending one — audit what's actually installed and confirm nothing else's postinstall step is load-bearing before reaching for this.
• When migrating a database adapter, remember to also drop (or at least stop needing) the old adapter's native dependency — it can keep silently causing deploy failures long after the code stopped using it.