Elchi vs Envoy Gateway.
Choose Envoy Gateway when Envoy runs in Kubernetes and you want the Kubernetes Gateway API as your configuration model. Choose Elchi when Envoy runs in production on Linux VMs or appliances (Envoy Gateway’s standalone mode is experimental), or when you need the full Envoy API in typed forms, several Envoy versions at once and a built-in WAF.
Elchi and Envoy Gateway, criterion by criterion
| Criterion | Elchi | Envoy Gateway |
|---|---|---|
| Where Envoy runs | Linux edge hosts (Ubuntu 24.04) where the elchi-client agent runs Envoy, or Elchi OS appliances. The control plane installs on Kubernetes (Helm), Docker Swarm or bare-metal Linux. Kubernetes services can be upstreams through the discovery agent. | Kubernetes first. Standalone mode runs Envoy as a host process on bare metal or VMs, but the project marks it experimental and says not to use it in production. |
| Configuration model | Typed forms generated from each Envoy version’s protobufs for every resource: listeners, routes, clusters, endpoints, secrets, filters and bootstrap. Each change is validated in the editor and again on the server. A REST API and a token-scoped automation API cover scripts and CI. | Kubernetes Gateway API resources plus extension CRDs attached as policies: ClientTrafficPolicy, BackendTrafficPolicy, SecurityPolicy, EnvoyExtensionPolicy, EnvoyPatchPolicy and others. In standalone mode a file provider reads these resources from disk. |
| Several Envoy versions at once | Yes. One control-plane variant per Envoy version; the registry routes each proxy to the one that matches. A listener upgrade copies its dependencies to the newer version and hot-restarts Envoy (0 dropped requests at 20 req/s in Elchi’s end-to-end test). | Each Envoy Gateway release ships with, and is tested against, a single Envoy Proxy minor version (v1.9 with 1.39.x, v1.10 with 1.40.x). Changing the Envoy minor version means changing the Envoy Gateway release. |
| Publish workflow and audit | Draft, save and publish; a publish pushes a new xDS snapshot that Envoy applies without a restart. Every change lands in an immutable audit trail with before/after detail, which can be forwarded to a SIEM over RFC5424 syslog. | Declarative: you apply resources (or change watched files in standalone mode). Review and history come from your Git/CI process. |
| WAF | Shield (API Security add-on): an ext_proc sidecar on each edge host with Coraza and the OWASP Core Rule Set built in, among twelve engines such as authentication, rate limiting and bot defense. Policies roll out from detect to block. | No built-in WAF. EnvoyExtensionPolicy attaches ext_proc services, Wasm extensions or dynamic modules; the docs include a Coraza WAF loaded as a dynamic module. |
| GSLB | GSLB add-on: DNS-based steering. The controller probes every IP behind a record over HTTP, HTTPS or TCP, and a CoreDNS plugin answers with healthy targets only. | Not part of the project. |
| API discovery | API Discovery add-on: a passive inventory built from Envoy access logs, with authentication and PII flags, shadow endpoints and drift against your OpenAPI specs. It is never in the request path. | Not part of the project. |
| Agent and install on hosts | elchi-client on each host dials out to the controller (no inbound listener), downloads Envoy, runs each deployed listener as a systemd service, and handles networking, BGP/FRR and log shipping. | In Kubernetes, Envoy Gateway provisions and configures the managed Envoy proxies from Gateway API resources. In standalone mode, a host infrastructure provider runs one Envoy as a host process next to Envoy Gateway. |
| RBAC and multi-tenancy | Projects isolate teams, environments or customers. Four roles (Owner, Admin, Editor, Viewer), LDAP/Active Directory login and TOTP two-factor authentication. | Kubernetes RBAC and namespaces on the Gateway API and extension resources. In standalone mode, access is access to the watched files. |
| Licensing and cost model | Commercial license, sized by managed clients (edge nodes) and by product: Core plus the API Security, API Discovery and GSLB add-ons. Free tier: Elchi Core with one managed client, no license needed. | Open source (Apache 2.0). |
| Components you operate | Controller, Control-Plane and Registry with MongoDB, ClickHouse, VictoriaMetrics/Grafana and an OTel Collector, behind one :443 front door; elchi-client (and Shield, if used) on each edge host. | The Envoy Gateway controller and the Envoy proxies it manages in the cluster; in standalone mode, Envoy Gateway and Envoy as processes on the host. |
A Gateway API implementation and a fleet control plane
Envoy Gateway is the Envoy project’s gateway for the Kubernetes Gateway API. You describe Gateways and routes, attach Envoy Gateway’s policy resources to them, and it provisions and configures Envoy proxies to match. For north-south traffic into a Kubernetes cluster, that keeps gateway configuration next to the rest of your Kubernetes manifests, in a vendor-neutral API.
Outside Kubernetes, Envoy Gateway has a standalone mode that reads Gateway API resources from files and runs one Envoy as a host process. The project documents it as experimental and not for production use. Elchi starts from the other side: Envoy on Linux hosts and appliances is the main case, managed as a fleet through an agent, with the Envoy API exposed field by field instead of through Gateway API abstractions.
When to choose Envoy Gateway instead
- Your gateways run inside Kubernetes and you want them configured with the standard Gateway API, alongside your other Kubernetes resources and GitOps tooling.
- Gateway API plus Envoy Gateway’s policy resources cover the features you need, and you would rather not work with lower-level Envoy fields.
- Following one tested Envoy minor version per release suits how you upgrade.
- You want an open source (Apache 2.0) project from the Envoy community with no commercial license.
When Elchi fits
- Your production Envoys run on Linux VMs, bare metal or appliances, outside any Kubernetes cluster, and you need a supported way to manage them as a fleet.
- You need Envoy features that Gateway API resources do not express, configured directly from the Envoy API with validation in the editor and on the server.
- Different services must stay on different Envoy versions for a while, and listeners move between versions with a hot restart rather than a fleet-wide upgrade.
- You want a WAF (Shield, with the OWASP Core Rule Set), API discovery and GSLB managed in the same UI, with an audit trail and project-level roles.
Read further
The Elchi documentation behind the claims on this page, and the products it mentions.
Documentation
Other comparisons
See it on your own fleet.
Tell us where your Envoys run and what you need to change on them. We will show the product on a setup like yours, or help you start on the free tier with one managed client.
Sources
Facts about other projects come from their official documentation and repositories, checked on the date below. Elchi facts come from the Elchi documentation.
- github.com/envoyproxy/gateway (README, license)
- Envoy Gateway: Standalone Deployment Mode
- Envoy Gateway: Compatibility Matrix
- Envoy Gateway: Gateway API Extensions
- Envoy Gateway: External Processing
- Envoy Gateway: Extensibility tasks (Wasm, dynamic modules, Coraza WAF example)
Last reviewed: