You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
oh, interesting 👍 Let's confirm we have configured the rate limiting properly and once we promote and have a stabler/fresher version in prod, I can give a go at migrating off of the Nginx ingress in staging
@rdimitrov Adding details as per our discussion here
For registry these 2 options will be suitable
Traefik
Envoy Gateway
Recommendation: Traefik (So far)
Easy to migrate, maintain, full Helm support. Good fit for a registry workload.
If we want high performance and advanced traffic management then Envoy Gateway is the better long-term bet. Tradeoff is migration complexity — Ingress objects become Gateway + HTTPRoute CRDs, more rewrite work upfront.
We currently rely on a few nginx-specific configs that don't carry over automatically:
Rate limiting — limit-req-status-code: 429 is a nginx global config.
In Traefik this needs to be rewritten as Middleware per route.
In Envoy this is handled natively via BackendTrafficPolicy, more powerful, supports per-IP, per-route, and global limits
Client IP handling — we use externalTrafficPolicy: Local + use-forwarded-headers: false tied to GCP L4 Passthrough LB.
Traefik needs explicit ProxyProtocol or TrustedIPs config.
Envoy handles this better via ClientTrafficPolicy, ProxyProtocol is first-class config, less chance of silently getting the wrong IP. This is critical — if client IP is wrong, rate limiting silently breaks
cert-manager ACME — strict-validate-path-type: false is a nginx bug workaround for HTTP01 challenges.
Traefik doesn't have this strict path validation behavior, so the issue likely doesn't exist. But it needs to be explicitly tested
Envoy Gateway implements Gateway API natively. cert-manager's Gateway API integration creates HTTPRoute objects instead of Ingress objects for the challenge, completely bypassing the path type issue.
Important point
Client IP handling is the highest risk item regardless of which option we pick — if client IP is wrong, rate limiting silently breaks with no obvious error. We have to test it thorughly before cutting over DNS.
Migration
Deploy Traefik or Envoy Gateway alongside nginx so that traffic starts going to both, check connectivity and then switch DNS. After 24-48 hours retire nginx.
One thing is to check cert-manager is configured correctly before hard cutover because if there is a misconfiguration it will not be noticeable till the time cert renews.
Activity
rdimitrov commentedon Dec 14, 2025
oh, interesting 👍 Let's confirm we have configured the rate limiting properly and once we promote and have a stabler/fresher version in prod, I can give a go at migrating off of the Nginx ingress in staging
pree-dew commentedon Feb 27, 2026
@rdimitrov Adding details as per our discussion here
For registry these 2 options will be suitable
Recommendation: Traefik (So far)
Easy to migrate, maintain, full Helm support. Good fit for a registry workload.
If we want high performance and advanced traffic management then Envoy Gateway is the better long-term bet. Tradeoff is migration complexity — Ingress objects become Gateway + HTTPRoute CRDs, more rewrite work upfront.
We currently rely on a few nginx-specific configs that don't carry over automatically:
Rate limiting — limit-req-status-code: 429 is a nginx global config.
Client IP handling — we use externalTrafficPolicy: Local + use-forwarded-headers: false tied to GCP L4 Passthrough LB.
cert-manager ACME — strict-validate-path-type: false is a nginx bug workaround for HTTP01 challenges.
Important point
Client IP handling is the highest risk item regardless of which option we pick — if client IP is wrong, rate limiting silently breaks with no obvious error. We have to test it thorughly before cutting over DNS.
Migration
Deploy Traefik or Envoy Gateway alongside nginx so that traffic starts going to both, check connectivity and then switch DNS. After 24-48 hours retire nginx.
One thing is to check cert-manager is configured correctly before hard cutover because if there is a misconfiguration it will not be noticeable till the time cert renews.
pree-dew commentedon Mar 6, 2026
@rdimitrov @domdomegg Can I help with anything here? I can try a POC of the solution before taking it to production.
rdimitrov commentedon Apr 9, 2026
Of course, assigned you to it! 🚀