# API gateway is stale

**URL:** <https://discuss.hashicorp.com/t/api-gateway-is-stale/77032>\
**Category:** Consul\
**Tags:** k8s, consul-api-gateway\
**Created:** [January 8, 2026, 6:35am UTC](https://discuss.hashicorp.com/t/api-gateway-is-stale/77032 "2026-01-08T06:35:31Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sharofiddin](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/sharofiddin/32/40457_2.png) [@Sharofiddin](https://discuss.hashicorp.com/u/Sharofiddin)\
**Post date:** [January 8, 2026, 6:35am UTC](https://discuss.hashicorp.com/t/api-gateway-is-stale/77032/1 "2026-01-08T06:35:31Z")

</div>

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.