Elchi vs building on go-control-plane.
Build on go-control-plane when Envoy configuration must be generated from your own platform model and a Go team can own that control plane for years. Choose Elchi when you want the control plane itself ready: typed configuration, validation, draft and publish, audit, RBAC, several Envoy versions and an edge agent, so your engineers work on traffic, not tooling.
Elchi and a self-built control plane, criterion by criterion
| Criterion | Elchi | Your control plane on go-control-plane |
|---|---|---|
| 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. | Wherever you build it to run. The library serves xDS to any Envoy that can reach your server; getting Envoy onto hosts is up to you. |
| 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. | Go code. You translate your own resource model into Envoy protobufs; the README says the project does not translate platform-specific representations into Envoy configuration. |
| 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). | The Go protos are synced from upstream Envoy on every commit. Serving several Envoy versions at the same time is a design you build and maintain. |
| 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. | The snapshot cache keeps a consistent view of configuration per group of proxies. Drafts, review, validation before a push and an audit log are yours to build. |
| 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. | Yours to build or integrate. |
| 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. | Yours to build or integrate. |
| 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. | Yours to build or integrate. |
| 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. | None. Installing, bootstrapping, upgrading and supervising Envoy on hosts is yours. |
| 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. | None. Authentication, authorization and tenancy are yours to build. |
| 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). The cost is the engineering time to build and run the control plane. |
| 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. | A gRPC xDS server and caches (snapshot, linear and mux) inside your Go service. Storage, API, UI and agents are additions you choose and operate. |
What the library gives you, and what it leaves out
go-control-plane is the Go library many custom Envoy control planes are built on. It provides a gRPC server for the xDS APIs, caches that hold configuration for groups of proxies (a snapshot cache, a linear cache and a mux combinator), and Go types synced from Envoy’s protos. Its README is direct about scope: it does not try to be a full control plane for a fleet of Envoy proxies, and it does not translate your platform’s resources into Envoy configuration.
That translation layer, and everything around it, is the build. A production control plane usually needs a store for desired state, validation before a push, a way to stage, review and roll out changes, an audit trail, access control, a way to install and upgrade Envoy on hosts, and a plan for each new Envoy release. Elchi’s own control plane is built on a per-Envoy-version build of go-control-plane; what you get with Elchi is the rest of that list, already integrated and tested together.
When to build on go-control-plane instead
- Envoy configuration has to be derived from your own internal model (a service catalog, a deployment system, a custom CRD), and no UI-driven workflow should sit in between.
- You have Go engineers who can own a control plane long term: Envoy releases, API changes, testing and on-call.
- You need only a small part of the Envoy API, such as endpoints for a few clusters, and a focused service is simpler than a platform.
- The control plane must be open source (Apache 2.0) code you fully own and can change.
When Elchi fits
- You want the whole Envoy API available from day one, in forms generated from each version’s protos, rather than growing coverage feature by feature.
- Changes need guard rails that are costly to build: validation in the editor and on the server, draft/save/publish, an immutable audit trail and roles per project.
- Envoy has to be installed and upgraded on Linux hosts, with listeners moved between Envoy versions without dropping requests.
- You want to automate the parts that matter (endpoint drain, blue/green EDS switch) through a token-scoped API instead of owning the whole server.
- A WAF, API discovery and GSLB belong in the same control plane, available as licensed add-ons.
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.
Last reviewed: