State of Ingress Proxy


I am trying to assess the state of Consul ingress proxy and whether it is worthwhile to use it as an edge proxy behind an AWS NLB.

While we have got everything up and running, we are unable to work out some of the details, for instance websocket upgrades.

There’s Github issue #8283 from 2020 along with PRs #13418 and #9639 which have not seen any activity in a while.

I am also not quite sure how I’d enable gzip or even brotli compression on an ingress level, it seems to me that there is no escape hatches to cover the above two problems.

A less important issue I tried to solve was TLS termination but we will do that on the LB instead.

In this post Mike writes that Consul API gateways are preferred for our use case which doesn’t help us given that we do not use k8s.

I guess my question is if the Envoy-based Consul ingress proxy is still a priority or if we should look at other options.



Our focus is on enhancing Consul API Gateway and that includes supporting it on multiple run-times, such as Linux VMs, Nomad and AWS ECS. We expect to release support for deploying API Gateway on Linux VMs and Nomad runtimes early next year.

Let us know if you have additional questions.


1 Like