Envoy Proxy Release History: Lyft to CNCF, xDS v3 and Support Windows

Envoy ships a new major release every quarter, on a fixed date near the middle of the first month of each quarter, and each release gets security and stability fixes for 12 months. As of 26 October 2026 the supported lines are 1.37, 1.38, 1.39 and 1.40; 1.36 reached end of life on 14 October 2026.

Envoy was built at Lyft, released as open source in September 2016, accepted by the CNCF on 13 September 2017 and graduated on 28 November 2018. The rest of this post walks through how a proxy written for one ride sharing company became the data plane under many service meshes, why its configuration API (xDS) matters more than any single feature, what the move from the v2 API to v3 broke, how the release and security processes work, and how to find the Envoy version hiding inside your sidecars and gateways. Every date comes from the project's own RELEASES.md, its version history, its GitHub releases or the CNCF.

Key takeaways

• Envoy major releases (1.x.0) are cut from main on a fixed quarterly schedule; RELEASES.md lists the expected and actual date and the end of life for every release since 1.12.
• Each major release is maintained for 12 months. Only security fixes, stability fixes and bug fixes the stable maintainers judge worthwhile are backported.
• Security point releases follow their own roughly three monthly cycle, around the midpoint between major releases, and may be followed by emergency releases with little warning.
• xDS, the family of discovery APIs (LDS, RDS, CDS, EDS, SDS, ADS and more), is the real contract between Envoy and every control plane. The v3 API arrived in 1.13 (January 2020); the v2 API became fatal by default in 1.17 and was removed from the binary in 1.18 (April 2021).
• The versioning guidelines call v3 the final major version of the API, supported forever; deprecated fields will not be removed.
• Most people never run upstream Envoy directly. They run it through a mesh or gateway, and that project picks the Envoy version, so you have to check two support calendars, not one.
• Vulnerabilities go to the Envoy security team through a GitHub Security Advisory or a private mailing list. Qualified distributors get patches under embargo three weeks before the public release.
• Contrib extensions are explicitly outside security team coverage.

How did Envoy start at Lyft, and when did it join the CNCF?

Envoy began inside Lyft. The CNCF's 2017 announcement says it was originally built there to move Lyft's architecture away from a monolith, and that its out of process design lets it be used with any application, in any language or runtime, abstracting most networking complexity away from the application developer. The CNCF's graduation announcement describes the result as a "high-performance open source edge, middle, and service proxy" originally created at Lyft.

The project went public in September 2016. The v1.0.0 release on GitHub carries a publish timestamp of 12 September 2016, and the CNCF project page records the first commit in the public repository as 8 August 2016. Note that 1.0 was already the version number on day one.

The CNCF step came a year later. On 13 September 2017 the CNCF blog announced that its Technical Oversight Committee had voted Envoy in as the foundation's 11th hosted project, with the news delivered on stage at Open Source Summit North America by Lyft's chief technology officer. Envoy entered at the incubating level. On 28 November 2018 the CNCF announced that Envoy had graduated, the maturity level the CNCF describes as "stable, widely adopted, and production ready". The CNCF project page states both dates in one sentence: accepted on 13 September 2017 at the Incubating maturity level, moved to Graduated on 28 November 2018.

Envoy was only the third CNCF project to graduate, after Kubernetes and Prometheus, and the announcement notes that it adopted the CNCF Code of Conduct to do so. Foundation hosting also means the project is not owned by a single company, which is one plausible reason many different control planes build on the same data plane.

Timeline: the milestones that shaped Envoy

Two details in that table are worth slowing down for. First, the schedule only became truly predictable from 1.21 onward: before that, releases were planned for the last day of a quarter and shipped between five and 31 days late (1.12 slipped 31 days, 1.18 slipped 15). Since 2022 most releases land on the planned day or within a few days of it, and RELEASES.md sets a two week acceptable delay with a hard deadline of three weeks. Second, the API migration was staged over roughly 15 months, with a deprecation notice, a warning, a fatal default with an escape hatch, and finally removal. That pattern is how Envoy handles most breaking changes, and it is why reading the "Incompatible behavior changes" and "Deprecated" sections of each release's notes is the single most useful upgrade habit.

What is xDS, and why did it outgrow Envoy?

The discovery services

xDS is the collective name for the APIs a management server (the "control plane") uses to send configuration to Envoy. The "x" stands in for the resource type. The xDS protocol documentation lists the resource types and their services:

The protocol has two independent dimensions. The first is "state of the world" versus incremental. In state of the world mode, every response carries the full set of resources of that type the client asked for (for LDS and CDS, the full set the server has). In incremental (delta) mode, the server sends only what changed and the client tells the server which resources it added or removed. The second dimension is whether each type uses its own gRPC stream or all types share a single aggregated stream (ADS). That gives the four variants the documentation names: basic xDS, incremental xDS, ADS and incremental ADS.

ADS exists because ordering matters. If Envoy receives a route that points at a cluster it has not yet heard about, traffic fails. With one stream, the control plane can send clusters before routes and endpoints before the clusters that use them, and avoid those gaps during updates. Every request and response also carries a version and nonce so Envoy can acknowledge (ACK) or reject (NACK) a configuration, and the control plane can see which version each proxy is actually running.

Why xDS became a de facto data plane API

Three things moved xDS from "how Envoy is configured" to "how proxies in general are configured".

First, Envoy's own adoption. Control planes written for Envoy speak xDS, so any other data plane that accepts the same API can reuse them.

Second, gRPC adopted it. gRPC's documentation for xDS features lists the xDS resources and the gRFC proposals that let a gRPC client receive listeners, routes, clusters, endpoints and security configuration from an xDS server directly. In principle that means one xDS control plane can configure both Envoy and gRPC clients. The gRPC page is also a good illustration of how strict the protocol is: a gRPC client that does not support a configured cluster load balancing policy NACKs the whole response, because xDS currently requires rejecting every resource in a response rather than just the bad one. gRPC also dropped the v2 API on its own timeline; its feature table lists v2 support only for C++ (and the languages built on it) before 1.51.0, Java before 1.53.0, Go before 1.54.0 and Node before 1.8.0.

Third, the API has a home outside Envoy. Envoy's API versioning guidelines say that "The Envoy project and xDS working group take API stability and versioning seriously", and link the working group to the cncf/xds repository. The guidelines also explain the exceptions: changes within 14 days of a new field being introduced (if it has not shipped in a release), packages tagged vNalpha, and protos marked work in progress may change freely. Everything else follows the no breaking change rule within a major version.

What changed between v2 and v3, and what it broke

The Envoy API is a family of protobuf packages, each versioned separately (for example envoy.config.bootstrap.v3). When people say "the v3 xDS API" they mean the major version of the root resources, the bootstrap and the top level xDS resources such as Listener and Cluster. The versioning guidelines are strict: within a major version, fields are never renumbered, retyped or renamed, because Envoy treats YAML and JSON as first class inputs and a rename breaks them even when the binary wire format survives. Some changes that are safe for protobuf in general, such as turning a singular field into a repeated one or wrapping a field in a oneof, are also treated as breaking.

That strictness is exactly why a new major version was needed. A package rename cannot happen inside a major version, so the move from v2 to v3 was the only point at which names and layouts could change. The project also separated the transport version (the wire protocol between Envoy and the management server) from the resource version (the shape of the configuration objects); the configuration overview documents both as independently versioned.

What broke in practice:

• Type URLs. Resources inside a DiscoveryResponse are wrapped in Any, whose type URL includes the package name. A v3 Envoy expects type.googleapis.com/envoy.config.cluster.v3.Cluster, not the v2 name. Control planes had to serve v3 types or Envoy would reject them.
• gRPC service paths. gRPC endpoint paths are derived from the package namespace, so v2 and v3 discovery services are literally different RPC methods.
• Bootstrap files. Static bootstraps written with v2 field names stopped loading once v2 became fatal by default in 1.17. The 1.17 release notes describe --bootstrap-version 2, together with a runtime feature flag, as the way to keep loading a v2 bootstrap file.
• Deprecated fields. Check the release notes and the v3 API reference for any v2 field your configuration relies on; the versioning guidelines say deprecated fields are not removed from v3, but a v2 field that never made it into v3 has no v3 equivalent to move to.
• Filters and extensions. Typed extension configuration moved to v3 packages too, so custom filters and their configuration generators needed updates alongside the control plane.

Why there will be no v4

The most important line in the versioning guidelines for anyone planning ahead is about the future, not the past. The project says it once planned regular major version bumps to clear technical debt, but that Envoy and the wider xDS ecosystem, gRPC included, are now so widely used that "version bumps are no longer realistic." For practical purposes v3 is the final major version and "will be supported forever." Fields can still be deprecated as a signal that a better way exists, but no field will be removed and Envoy commits never to remove the implementation of a deprecated field. Other xDS clients may choose to stop supporting fields; Envoy itself will not. On the project's current guidance, the v2 to v3 migration is the last of its kind.

For anyone running their own control plane or generating bootstrap files with scripts, the sequence in the table above is the practical lesson: the warning, the fatal default and the removal each arrived in a separate release.

How does Envoy's release policy work today?

RELEASES.md is the authoritative document and it is short enough to read in full. The essentials:

• Active development happens on main, which the project aims to keep at release candidate quality at all times.
• Major releases are cut from main on "the 15th day of each quarter" (in practice the middle of January, April, July and October), with an acceptable delay of up to two weeks and a hard deadline of three weeks. They involve no backports and are handled by the maintainer on call.
• The extended maintenance window covers any version released in the last 12 months. Those versions receive minor (patch) releases containing security fixes backported from main (including some not judged worthy of a CVE), stability fixes (anything that can crash Envoy, including crashes a trusted control plane could trigger) and bug fixes the stable maintainers think worthwhile.
• Security releases are published on a three monthly cycle, around the midpoint between major releases, and are run by a named Release Manager and Fix Lead each quarter. RELEASES.md notes that zero days and upstream vulnerabilities disclosed under embargo can force an emergency release "with little or no warning".
• Backports must be proposed against every affected supported branch (for example release/v1.37), and only security and reliability fixes qualify.

The practical result is that four major lines are supported at any moment, each for about a year, and you should expect a coordinated batch of patch releases across all of them several times a quarter. The GitHub release list for October 2026 shows that rhythm: on 1, 6 and 12 October 2026 patch releases landed on four lines at once (for example 1.36.11, 1.37.7, 1.38.5 and 1.39.2 on 1 October), 1.40.0 shipped on 13 October, and on 22 and 23 October 1.37.10, 1.38.8, 1.39.5 and 1.40.1 followed. 1.36 had its last patch (1.36.13) on 12 October, two days before its end of life date.

Release table: dates, end of life and what stood out

The table below comes straight from the RELEASES.md schedule, with status computed for 26 October 2026 and notes taken from the version history where a release carried a change that matters for this history. "Patch" releases are not listed; check the GitHub releases page for the newest patch on your line.

Releases before 1.12 (1.0 in September 2016 through 1.11) predate the schedule table; their dates are on the GitHub releases page and in the version history, and every one of them is long out of support.

How do Istio, Envoy Gateway, Contour and Emissary map to Envoy versions?

Most Envoy in production arrives inside something else. The control plane project decides which Envoy it builds against, and it often builds its own binary from a fork or a branch with extra patches. That means your real support window is the intersection of two calendars.

Istio. Istio's supported releases page has a "Supported Envoy Versions" table that maps each Istio minor release to the Envoy release branch it uses, and states that Istio's data plane is based on Envoy. The same page sets the skew rule that matters for upgrades: the control plane can be one version ahead of the data plane, but the data plane cannot be ahead of the control plane. For the exact Envoy commit, the page points to the ENVOY_SHA variable in the istio/proxy repository.

Notice that Istio lags upstream by one or two Envoy minors: on 26 October 2026 the newest Istio uses Envoy 1.39 while upstream has shipped 1.40. That is normal and deliberate, but it means "we run the latest Istio" does not mean "we run the latest Envoy".

Envoy Gateway. Envoy Gateway is the Envoy project's own implementation of the Kubernetes Gateway API, which it describes as a way to deploy Envoy "as a Standalone or Kubernetes-based API Gateway, implementing and extending the Kubernetes Gateway API." Its compatibility matrix lists, for each Envoy Gateway release, the Envoy Proxy version, the Rate Limit version, the Gateway API version, the tested Kubernetes versions and an end of life date. The matrix states that each Envoy Gateway release "ships with, and is tested against, a single Envoy Proxy minor version."

The interesting row is v1.7: it reached end of life in August 2026 even though Envoy 1.37 underneath it is supported upstream until January 2027. The reverse also happens. Support ends on whichever calendar runs out first.

The matrix page carries one more warning that every operator should read. If you override the proxy image on the EnvoyProxy resource with a different Envoy minor, the combination is untested and Envoy Gateway "may generate configuration that the proxy rejects." A rejected configuration is silent while proxies keep serving their last good configuration; the failure only shows up when a proxy restarts with nothing to fall back on. The page recommends watching the xDS rejection metrics, and preferring imageRepository over image when all you need is a private registry, so the tag still tracks the control plane.

Contour and Emissary. Both run Envoy as their data plane and publish their own compatibility information. Contour's compatibility matrix lists the tested Envoy version per Contour patch release: on 26 October 2026 its newest release, 1.33.7, is listed against Envoy 1.38.4, while upstream's newest 1.38 patch is 1.38.8. That gap is not a criticism; it is simply what the matrix shows, and it is why you check your product's own advisories rather than assuming upstream patch dates apply. For Emissary, check its release notes for the bundled Envoy version in the same way.

A short note on Envoy AI Gateway, since it can show up in the same clusters: it is a separate project built on Envoy (its site now presents it as Agent Router) that routes OpenAI compatible requests to model providers and MCP tools. We covered one of its advisories in our post on the Envoy AI Gateway MCP session hijacking issue; check that project's own releases and advisories as a third calendar.

How does Envoy handle security vulnerabilities?

This section stays at the level of process. Individual advisories are covered by our incident desk.

Reporting

SECURITY.md asks reporters to open a private GitHub Security Advisory on the envoyproxy/envoy repository, which it calls the preferred channel, or to email the private envoy-security list. Anyone who learns of a publicly disclosed issue is asked to email that list immediately. Reports to the list get an initial response within one business day.

The product security team and the Fix Lead

Envoy's Product Security Team (PST) is made up of maintainers on the private envoy-security list. For each vulnerability one member volunteers as "Fix Lead", pulls in the engineers who know the affected code (the "Fix Team"), gives them access to a private security repository, agrees a CVSS score and drives the release. The Fix Lead role rotates, and RELEASES.md names a Fix Lead and Release Manager per quarter; for 2026 Q4 the Release Manager is listed as Jonh Wendell and the Fix Lead as Kateryna Nezdolii.

What counts as a vulnerability

Reports are judged against Envoy's published threat model. Its highest priority is the threat from untrusted downstream clients and untrusted upstream servers on the data plane. The control plane management server is generally treated as trusted. Each extension carries a security posture label, such as robust_to_untrusted_downstream_and_upstream, robust_to_untrusted_downstream or requires_trusted_downstream_and_upstream, and features marked alpha are only supported in trusted deployments. A configuration change that reliably crashes the data plane may be classed as something the trusted control plane should disallow and be fixed in the clear, and RELEASES.md still backports crashes triggered by a trusted control plane as stability fixes. SECURITY.md also states plainly that contrib extensions are not eligible for security team coverage, which is a useful thing to know before you enable one.

Timelines and the distributor list

SECURITY.md sets out a sequence with suggested timelines:

Distributors on the private list get a three week window from candidate patch to public release, extended to four weeks in exceptional cases and shortened if the issue goes public. The embargo covers source and binaries: SECURITY.md says it is a violation to share binary distributions, including Docker images, before the public release. Membership is limited to actively maintained distributions, publicly identified Envoy as a service offerings and a capped number of well known end users (10 slots), each of which must be able to ship a security release within three weeks.

Two more service levels matter for operators. Privately disclosed issues are fixed or disclosed within 90 days, and fuzz bugs found by the project's continuous fuzzing follow the same 90 day deadline. For teams that build from main, SECURITY.md recommends at least five days of soak time after cutting a binary before rollout, and seven for a stronger guarantee, so that fuzzers on ClusterFuzz have time to find recent regressions.

If a bug only affects versions older than the supported set, the team shares it with the distributors list under embargo but does not create a security release. If it only affects main and is found within seven days of being introduced, the fix lands publicly.

Step by step: find your Envoy version and plan the upgrade

The goal is to answer three questions for every Envoy in your estate: which version is running, is that line still supported, and who has to ship the upgrade.

1. Ask Envoy directly

Every Envoy exposes an admin interface. The /server_info endpoint returns a JSON document that includes the version string, the build's commit SHA and whether it is a release or debug build. From a host where the admin port is reachable (it should only be reachable locally):

curl -s http://127.0.0.1:9901/server_info | jq -r '.version'

The admin documentation's sample shows the format: a commit SHA, the version, whether the tree was modified, and the build type, separated by slashes (its example is .../1.9.0-dev/Modified/DEBUG). Anything that says DEBUG or Modified in production deserves a question; the security policy notes that bugs affecting only debug binaries do not trigger point releases at all.

On the binary itself:

envoy --version

2. In a Kubernetes mesh, go through the sidecar

You rarely have a shell in the sidecar, and you should not expose the admin port to fetch this. Use the mesh's own tooling or port forward to localhost:

# Forward the pod-internal admin port to your own machine only
kubectl port-forward -n shop pod/checkout-7d9c8 15000:15000 &
curl -s http://127.0.0.1:15000/server_info | jq -r '.version'

Port numbers differ by product. Istio's application requirements page lists 15000 as the sidecar's Envoy admin port and marks it pod internal only; plain Envoy examples use 9901. Use the one your product documents, and keep the forward bound to localhost.

3. Inventory images across the cluster

Images tell you which build each workload was started with, which matters when a rollout is half finished.

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -E 'envoy|proxyv2|gateway'

Map each image tag back to an Envoy version using the product's compatibility page, then confirm a sample with step 1, because a tag tells you what was requested, not what is running.

4. Record it in an SBOM

An SBOM of the proxy image lists Envoy and everything else in the image: the base OS packages, BoringSSL, any Wasm runtime, and the pilot agent or controller binary. Generate one per image and keep it with the release:

safeguard scan --image envoyproxy/envoy:v1.40.1

Results are written as JSON under ./output, and the platform can then show which projects contain a given component and version.

5. Compare with the supported list

Check the Envoy line against the RELEASES.md end of life column, then check the product release against its own support page. Flag anything where either is out of support, and anything more than one patch behind the newest on its line.

6. Plan the upgrade with the control plane

• Read the "Incompatible behavior changes", "Removed config or runtime" and "Deprecated" sections of every Envoy release between your version and the target.
• Upgrade the control plane first if your product requires it (Istio's skew rule says the data plane must not be ahead of the control plane).
• Restart or roll workloads so sidecars pick up the new proxy image; a control plane upgrade alone does not replace running sidecars.
• Run the new version on a canary namespace or a revision label first, watch /stats for rejected configuration (NACKs) and error rates, then widen.
• Re-run steps 1 to 3 to confirm nothing is left on the old build.

Hardening defaults worth knowing

Hardening has its own detailed post, so this is only the short list that release history makes relevant.

• The admin interface. It can change state (drain listeners, change log levels, quit the server). Bind it to localhost or a Unix socket and never route it through a listener.
• The overload manager. Envoy's edge proxy best practices configure the overload manager with heap based actions (envoy.overload_actions.shrink_heap and envoy.overload_actions.stop_accepting_requests in its example) so that Envoy sheds load instead of running out of memory.
• Header and connection limits. The same page sets headers_with_underscores_action to REJECT_REQUEST, caps HTTP/2 max_concurrent_streams at 100 in its example, and sets connection idle, stream idle and request timeouts (the stream and request timeouts at 300 seconds, with a note to disable them for long lived streaming requests).
• TLS through SDS. Delivering certificates by SDS lets you rotate them without a restart; see our SDS rotation guide.
• Extensions. Know which of your filters are contrib extensions and which are marked hardened for untrusted traffic in the threat model.

Common mistakes

1. Exposing the admin port. Binding the admin interface to 0.0.0.0, or publishing it through a Kubernetes Service, hands anyone who can reach it control over draining and shutdown and a view of your full configuration.
2. Upgrading the control plane but not the sidecars. The control plane rolls forward and the dashboards look green, while pods that have not restarted keep the old Envoy for weeks.
3. Assuming the mesh build matches upstream fix dates. Upstream publishes a patch on its release day; your product ships its own build when its own release process allows. Read the product's bulletin, not only Envoy's.
4. Tracking the image tag instead of the running version. A tag such as latest or a floating minor tag says nothing about the binary inside a running pod.
5. Ignoring end of life because nothing broke. An end of life line gets no security backports at all. In October 2026 1.36 dropped off the supported list, and the next security batch will skip it.
6. Pinning a gateway's proxy image to a different Envoy minor. Envoy Gateway's matrix warns that the combination is untested and that rejected configuration stays silent until a proxy restarts.
7. Leaving Wasm filters unpinned. A Wasm module fetched from a remote URL without a pinned digest can change under you; pin by SHA256 and keep the module in your own registry.
8. Enabling contrib extensions without knowing they are outside security coverage.
9. Skipping the deprecation sections in release notes. Envoy stages breaking changes over several releases; teams that skip several releases at once meet them all together.
10. Running a main build without the soak time the security policy recommends.

Where Safeguard fits

Safeguard does not replace Envoy's release process, scan Envoy's configuration for misconfigurations, or run in your data path. What it does help with is the inventory and dependency side of this problem. You can scan the proxy and gateway images you deploy (safeguard scan --image ...) and the repositories that build your control plane extensions or Wasm filters (safeguard scan --dir .), keep SBOMs for each, match their components against vulnerability databases and see which projects carry a given component and version. Policies and gates evaluated in the platform can block a build that ships an out of date component. Where a fixed version of a dependency exists, autonomous remediation can open the upgrade pull request; it ships switched off. The honest limit: if your Envoy comes from a managed mesh or a cloud load balancer, the fix still has to come from that provider.

Most Envoy deployments are really a bundle of open source: the proxy, its TLS library, its Wasm runtime, a control plane written in Go, and the filters and tooling your own team builds. Keeping that bundle current and knowing where each piece came from is where supply chain hygiene still matters, even for a project with a security process as mature as Envoy's.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a vulnerable dependency, shows it reading the finding, asking before any command that changes something, editing the manifest and running the tests. The same flow applies to the Go control plane or the build tooling around your Envoy filters.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and runs scans from the terminal. That is the route for scanning proxy images and SBOMs that never leave your network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is a quick way to ask which projects still carry an old proxy image without opening a dashboard.

Click through it at your own pace, or open it full screen.

FAQ

Who created Envoy proxy?

Envoy was created at Lyft and released as open source in September 2016. The CNCF's graduation announcement describes it as originally created at Lyft. It is now maintained by a multi company group of maintainers under the CNCF.

When did Envoy graduate from the CNCF?

On 28 November 2018. Envoy had been accepted as an incubating project on 13 September 2017.

How often does Envoy release?

A major release every quarter, on the 15th day of the first month of each quarter with up to two weeks of acceptable delay. Security patch releases follow their own roughly quarterly cycle and emergency releases can happen at any time.

How long is an Envoy release supported?

Twelve months from its release date. RELEASES.md lists the end of life date for each release; for example 1.40.0 shipped on 13 October 2026 and is supported until 13 October 2027.

What is the latest Envoy version?

On 26 October 2026 the newest release is 1.40.1 (23 October 2026). The other supported lines are 1.39, 1.38 and 1.37.

Is the Envoy v2 API still supported?

No. The v2 xDS API was deprecated in 1.13 (January 2020), made fatal by default in 1.17 and removed from the binary in 1.18 (April 2021). Current control planes serve v3.

What is the difference between xDS and ADS?

xDS is the family of discovery services (listeners, routes, clusters, endpoints, secrets and more). ADS is a way of carrying several of those resource types on a single gRPC stream, so the control plane can order updates and avoid traffic going to clusters Envoy has not received yet.

How do I report a security vulnerability in Envoy?

Open a private GitHub Security Advisory on the envoyproxy/envoy repository or email the envoy-security list, as SECURITY.md describes. Do not file a public issue.

Does my Istio sidecar get Envoy security fixes on the same day as upstream?

Not necessarily. Istio builds its own proxy and ships it in its own patch releases. Distributors on the private list get patches three weeks early so they can release on the same day, but your exposure ends only when your mesh version with the fix is rolled out to every sidecar.

Are Envoy contrib extensions covered by the security team?

No. SECURITY.md states that contrib extensions are not eligible for Envoy security team coverage.

Quick check

Sources

• Envoy RELEASES.md
• Envoy SECURITY.md
• Envoy GitHub releases
• Envoy v1.0.0 release
• Envoy version history
• Envoy 1.5.0 release notes
• Envoy 1.13.0 release notes
• Envoy 1.15.0 release notes
• Envoy 1.17.0 release notes
• Envoy 1.18.0 release notes
• Envoy 1.19.0 release notes
• Envoy 1.20.0 release notes
• xDS REST and gRPC protocol
• Envoy API versioning guidelines
• Envoy configuration versioning
• cncf/xds repository
• Envoy threat model
• Envoy administration interface
• Envoy edge proxy best practices
• CNCF Envoy project page
• CNCF hosts Envoy (13 September 2017)
• CNCF announces Envoy graduation (28 November 2018)
• gRPC xDS features
• Istio supported releases
• Envoy Gateway
• Envoy Gateway compatibility matrix
• Contour compatibility matrix
• Istio application requirements (ports)

Last reviewed: 26 October 2026. Envoy patches several lines at once; check RELEASES.md and the GitHub releases page for the newest versions and end of life dates.