Elchi vs Istio for Envoy on VMs.

Choose Istio when you want a service mesh for Kubernetes workloads, with sidecar or ambient data planes, and VMs joining that mesh. Choose Elchi when Envoy runs as an edge, gateway or load-balancing tier on Linux VMs or appliances, and you want the full Envoy API in typed forms, several Envoy versions at once and an audited publish workflow.

Book a demo Try the free tier

Elchi and Istio, criterion by criterion

How Elchi and Istio compare for teams running Envoy outside Kubernetes. Istio facts are from istio.io; see Sources.
Criterion	Elchi	Istio
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.	Built around Kubernetes. VMs join the mesh as workloads: the VM guide installs istiod in a Kubernetes cluster and exposes it to the VMs through an east-west gateway. VM integration is marked Beta; the guide ships packages for Debian and CentOS 8.
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 resources: VirtualService, DestinationRule, Gateway, ServiceEntry and Sidecar, plus the Kubernetes Gateway API, which Istio intends to make its default. Istio generates the Envoy configuration; EnvoyFilter customizes what it generates.
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).	Upgrades run as revisions: each revision is a full istiod control plane, workloads move to it through the istio.io/rev label, and existing pods are restarted to pick up the new proxy.
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.	Changes are applied as Kubernetes resources, so review and history live in your Git/CI process and the Kubernetes API. There is no built-in draft-and-publish step.
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.	Not built in. The proxy can be extended with WasmPlugin (WebAssembly filters) or EnvoyFilter, so a WAF is a filter you choose, add and operate.
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.	No DNS-based GSLB. Locality failover is configured inside the mesh.
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.	No API inventory feature; a separate tool is needed.
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.	On a VM: the istio-sidecar .deb or .rpm package, plus certificates, a token and mesh config copied from the cluster, started with systemctl. In Kubernetes: sidecars or ambient mode.
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 govern who can change the mesh resources.
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.	istiod and gateways in a Kubernetes cluster; for VMs, an east-west gateway that exposes istiod, and the sidecar package on every VM.

Two different jobs for the same proxy

Istio and Elchi both run Envoy, but they put it in different places. Istio is a service mesh: it puts a proxy next to each workload (or, in ambient mode, uses ztunnel and waypoint proxies) and is configured through Kubernetes resources. Virtual machines join that mesh as workloads, represented by WorkloadGroup and WorkloadEntry resources, and their control-plane traffic goes through a gateway in the cluster.

Elchi is not a service mesh. It manages Envoy as the edge, gateway or load-balancing tier on hosts you choose. Each host runs the elchi-client agent, which runs Envoy as systemd services and connects back to the control plane over one outbound stream. The data plane needs no Kubernetes cluster, and you edit the Envoy API itself rather than a higher-level abstraction that generates it.

When to choose Istio instead

Most of your services run in Kubernetes and you want mesh features between them: per-workload proxies, service-to-service traffic policy and a uniform model across the cluster.
You already run Istio, and the VMs you need to cover are workloads that should become part of that mesh, addressed through Kubernetes services that select both pods and VMs.
You prefer configuration as Kubernetes resources and the Gateway API, reviewed in Git, over a UI-driven workflow.
You want an open source (Apache 2.0) project with no commercial license for the core.

When Elchi fits

Envoy is your edge, ingress or API gateway tier on Linux VMs, bare metal or appliances, and adding a mesh just to manage it would be more than you need.
Teams need to change listeners, routes, clusters and TLS without writing xDS or YAML, with every change validated, reviewed through draft/publish and recorded in an audit trail.
You must run more than one Envoy version and move listeners between them without dropping traffic.
You want a WAF (Shield), DNS-based GSLB and a traffic-derived API inventory in the same control plane instead of separate tools.
Kubernetes services are among your upstreams: the discovery agent syncs their endpoints to the Envoy clusters on your edge hosts.

Read further

The Elchi documentation behind the claims on this page, and the products it mentions.

Documentation

Products

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.

Book a demo Try the free tier

Sources

Facts about other projects come from their official documentation and repositories, checked on the date below. Elchi facts come from the Elchi documentation.

Last reviewed: 13 November 2026