The SolidStart frontend (Vinxi 0.5.7) does not mount src/routes/api/* as
Nitro handlers in the production build. With only a single path rule
pointing to the frontend pod, every /api/* call fell through to
SolidStart's Not Found handler and returned the HTML shell page — making
the Sign Up button appear to do nothing.
Added an /api prefix rule before / so Traefik matches the longer
prefix and forwards signup/login/KB requests directly to the
nxtgauge-rust-gateway service on port 9100 (same backend that
api.nxtgauge.com already uses).
Verified:
- POST /api/auth/check-email -> 200 application/json
- POST /api/auth/register -> 201 application/json
- GET / -> 200 text/html (frontend shell)
- GET /api/kb/categories -> 200 application/json
NXTGAUGE_USERS_URL used the short service name "nxtgauge-rust-users",
which only resolves within the same namespace. The prod overlay places
ai-assistant in nxtgauge-ai while the users service is in nxtgauge, so
every help-center search and ticket-creation call failed with a DNS
resolution error (surfaced as a 502 to the client). Use the full
in-cluster FQDN instead.
This file had drifted badly from the actual running DaemonSet - the
live cluster already moved off the standalone registry.nxtgauge.com
mirror (now decommissioned, confirmed dead: internal DNS routes it to
Traefik with no matching ingress) onto ci.nxtgauge.com's built-in
registry. That migration was done directly against the cluster and
never reflected back to git, leaving a stale REGISTRY_PASSWORD literal
("Ashwin@2026") in this file that doesn't exist in the live DaemonSet
at all. Replaces the file with the actual live spec and adds the two
ConfigMaps (docker-daemon-config, registry-cert) it depends on, which
were also missing from the repo. Not applying this to the cluster -
the differences are purely cosmetic (mount ordering, stale
annotations) and would trigger a pointless restart of healthy runners.
Was defaulting to plain Ollama with gemma3:270m for every request -
no LLM_PROVIDER or LITELLM_* env vars were set. LiteLLM is already
deployed with purpose-built model aliases per task
(apps/litellm/base/configmap.yaml); this wires ai-assistant to use it.
Wires the PayU credentials for the classic hosted-checkout hash flow
(PAYU_MERCHANT_KEY, PAYU_SALT), consumed by the payments service's
resolve_payu_config fallback and the admin payment-gateway config API.
Old password was reused across the postgres superuser, Redis, and
Forgejo's separate nxtgauge DB role. Rotated only the postgres role
and Redis (Forgejo's nxtgauge role password is untouched and still
valid, verified against the live DB).
JWT_SECRET can't reference nxtgauge-backend-rust-secrets (namespace
nxtgauge) from the ai-assistant pod, which the prod overlay places in
nxtgauge-ai — Kubernetes secretKeyRef must be same-namespace. Duplicate
the value into nxtgauge-ai-assistant-secrets instead.
- Add .sops.yaml (age) and encrypt every plaintext Secret manifest in apps/
- Commit the Flux GitRepository/Kustomization (previously only applied manually)
with a decryption stanza referencing the sops-age key (created out-of-band,
not committed)
- Rotate JWT_SECRET (previously exposed in plaintext) and set a real
AI_SERVICE_KEY (was an empty placeholder), shared between
nxtgauge-backend-rust and nxtgauge-ai-assistant
- Wire JWT_SECRET into the ai-assistant deployment (was missing entirely,
causing every authenticated request to fail)
- Redact the leaked LiteLLM production master key from README/OPENCODE_CONNECT
docs; move the litellm prod overlay off a plaintext secretGenerator onto an
encrypted patch
