deployment

The inbound deploy port is gone: KotaPortal staging is now served through an outbound-only tunnel, with no per-commit deploy ritual.

TL;DR: After a Cloudflare Tunnel took over backend staging, the per-commit deploy job disappeared, replaced by a persistent staging link that updates as the origin refreshes. The tunnel is outbound-only on port 7844, so the origin needs no public IP and loses its scannable deploy port, a real security win. Frontend keeps preview hosting; most 502s mean a wrong Service URL.

The Docker Hub image lags behind the npm release. Build on a big machine, ship it with save, gzip, and scp, then load it on a small VPS.

TL;DR: The Docker Hub image trailed the npm release, and a 964MB VPS can't build a Next.js app without the OOM killer intervening. The fix: build locally, save and gzip the image, scp it over, and docker load it, keeping the old container renamed for instant rollback. Custom images carry different digests, so digest-checking playbooks must skip this server.

Pushes to our staging branch kept creating throwaway preview deploys. One git.deploymentEnabled block in vercel.json ended it.

TL;DR: Vercel deploys every pushed branch by default, so a repo with main and stag ends up with redundant preview deployments. An eight-line vercel.json using git.deploymentEnabled silences stag while keeping main on production. It beats the Ignored Build Step because declarative JSON can't invert exit codes or rot, just avoid overlapping glob rules.

The diff was docs-only, yet the deploy migration from Cloudflare Workers to Vercel still happened. The wiring lives in the Vercel dashboard and GitHub settings, not in the repo.

TL;DR: A docs-only commit revealed the Workers-to-Vercel migration left almost no trace in Git, since the wiring lives in Vercel and GitHub settings. Vercel elects the production branch only at import, so the GitHub default branch stag and production branch main are two independent switches. Env variables need per-target re-registration, and rollback is repointing a deployment, not git revert.

The knowledge seed failed on every container start although the script was in the image. Bare python resolved to the system interpreter.

TL;DR: The CI seed script failed because bare python resolved to the system interpreter, which had none of the project's packages or venv site-packages on its path. Running a script file by path skips CWD, so cd didn't help either. Fix: call the venv interpreter directly with PYTHONPATH set to the project root.

Hand-typed knowledge entries never reached the VPS. A repo-tracked seed file, upserted on every container start, keeps both databases converged.

TL;DR: Hand-typed knowledge entries lived only in the local database, so the VPS was missing four. The fix is a seed file plus a small seeder running on every container start, using INSERT ... ON DUPLICATE KEY UPDATE keyed on slug.