- Remove complex template with .Changed.Images that was causing errors
- Use simple commit messages for ImageUpdateAutomation
- Keep ImageRepository and ImagePolicy configurations
- Remove filterTags pattern that wasn't matching actual registry tags
- ImagePolicies now resolve correctly to available tags
- Tags found: ghcr-migration, manual-build, high-performance-latest
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.
