Versions & Upgrades
Elchi manages multiple Envoy versions from a single interface. The registry routes each proxy to a control-plane that speaks its version, so mixed fleets are first-class.
The exact supported set is not hardcoded — it is fetched dynamically from the release archive. Any version numbers shown in these docs are illustrative; see Envoy versions for the authoritative, current list and how it is resolved.
Version-based routing
When a proxy connects, the registry matches it to the right control-plane instance based on the Envoy version it reports. You can run several versions side by side without conflicts.
Upgrading resources
The upgrade subsystem migrates configurations from one Envoy version to another. Trigger it from Settings → Upgrade; the controller:
- Runs a per-listener dependency analysis to find everything that must move together.
- Recreates the dependencies, then the listeners, in topological order.
- Regenerates snapshots and bootstrap configs for the target version.
The migration runs as a tracked background job, so you can watch progress and retry if a step fails — see Background Jobs.
The target Envoy version must be one of your deployed global.versions (Helm) or --backend-version variants (bare-metal) before you upgrade resources into it.
Cleaning up an old version
Once every resource has migrated off an Envoy version, you can remove that version's leftover resources so the control-plane no longer carries them. From Settings → Maintenance, the version cleanup action deletes the resources scoped to a given version (DELETE /setting/maintenance/cleanup/versions/:version, with mode and project scope). It is Owner-gated and destructive — validate that nothing still runs on the version first.
Cleanup permanently deletes the version-scoped resources. Take a backup before a large cleanup, and confirm no live proxy still reports the version.