Change storefront service from ClusterIP to NodePort with externalTrafficPolicy: Local.
This preserves the real client source IP instead of NATing to the node IP.
Fixes analytics tracking showing Hetzner IP (138.201.11.251) instead of real visitor IPs.
Same fix previously applied to Rybbit backend service.
Note: On single-node clusters, this works seamlessly. Traefik routes directly
to the node where the pod is running, preserving the original source IP.
- Add Next.js rewrites to proxy /api/script.js and /api/track through self-hosted Rybbit
- This bypasses ad blockers that would block rybbit.nodecrew.me directly
- Add NEXT_PUBLIC_RYBBIT_HOST and NEXT_PUBLIC_RYBBIT_SITE_ID env vars to K8s deployment
- Remove dev.manoonoils.com from storefront ingress to prevent cross-domain tracking issues
- Use environment variable for OpenPanel API URL in route handler
- Fixes session state conflicts from multiple domains
- Update ingress to serve all domains (dev.manoonoils.com, manoonoils.com, www.manoonoils.com)
- Update NEXT_PUBLIC_SITE_URL to https://manoonoils.com in deployment env vars
- Prepare for 24h testing period before removing dev domain
Add NEXT_PUBLIC_OPENPANEL_CLIENT_ID, OPENPANEL_CLIENT_SECRET, and
OPENPANEL_API_URL to the storefront runtime container for server-side
tracking to work properly.
- NEXT_PUBLIC_WOOCOMMERCE_URL → NEXT_PUBLIC_SALEOR_API_URL
- Remove WooCommerce consumer key/secret (not needed for Saleor public API)
- Saleor API is public, no authentication required
- Init containers clone and build fresh code on each pod start
- Webhook triggers kubectl rollout restart on git push
- This provides true auto-deploy without requiring Docker registry
The Docker-based CI/CD approach is the industry standard but requires:
- Proper container registry (GHCR, Docker Hub) with HTTPS
- Or complex local registry setup with containerd HTTP configuration
The init container approach works reliably for now. To enable auto-deploy:
1. Flux detects git changes in 30s (via webhook)
2. Kustomization applies new config
3. Manually run: kubectl rollout restart deployment/storefront -n manoonoils
For true auto-deploy, consider:
- Setting up GHCR with proper auth
- Using GitHub Actions to build/push images
- Using Flux ImageUpdateAutomation
Or simpler: A post-deploy webhook that triggers rollout restart.
- Add Dockerfile for building Next.js images
- Replace init-container deployment with standard deployment
- Add kustomization with image tag tracking
- Add deploy.sh script for CI/CD pipeline
This enables proper GitOps auto-deployment:
1. Build image with commit hash tag
2. Push to GHCR
3. Update kustomization.yaml image tag
4. Flux detects change and restarts pods