Consul’s API Gateway for Kubernetes feels stale and significantly behind modern Gateway API–based solutions, yet once you adopt Consul as a service mesh you’re effectively forced to use it for first-class north–south traffic. This creates a real architectural dead end: teams want Consul Mesh but also need a modern, fast-evolving API gateway, and today there’s no clear, supported way to combine Consul Mesh with third-party gateways without losing integration, observability, or supportability. Is Consul’s API Gateway actively evolving toward feature parity, or is HashiCorp intentionally coupling the mesh to a single gateway implementation? A clear stance or roadmap here would help teams decide whether Consul remains a viable long-term choice.
Related topics
| Topic | Replies | Views | Activity | |
|---|---|---|---|---|
| Consul API Gateway v0.1.0 Released | 0 | 420 | February 24, 2022 | |
| Consul API Gateway v0.1.0-techpreview Released | 0 | 329 | November 15, 2021 | |
| Consul API gateway compatibility matrix | 0 | 251 | April 4, 2023 | |
| [Consul/K8S] api gateway has no address | 4 | 407 | January 25, 2025 | |
| Consul API gateway with service mesh on EKS. Gateway ready - false | 8 | 1010 | May 2, 2022 |