AI
Emissary 4.0.1: Why the Upgrade From 3.x Is Urgent
Emissary 4.0.1 is the current release. A CI glitch in 4.0.0 caused Helm installs to pull images that label themselves 4.0.0.rc.2, but the binaries are identical to 4.0.1 GA. The bigger story is Emissary 3. The last 3.x release, 3.10, ships an Envoy version with known bugs and known security flaws. There will be no further 3.x releases. Users still on 3.x have no path to security fixes except upgrading to 4.
The Release Process: From Days of Work to One Git Tag
The core goal of Emissary 4 was making releases cheap. Previously, cutting a release consumed most of a working day. Now, upgrading Envoy requires changing one line of source code and letting CI build the release. Flynn shipped 4.0.1 by pushing a git tag, going to dinner, and returning to find a green CI run. The next step, upgrading to the latest Envoy and shipping 4.1, is planned for the week after the conference.
Version 5: API Cleanup and Killing the Conversion Webhook
Emissary 5 targets three structural changes. First, dropping Python in favor of Go-only. Second, moving all CRDs from the getambassador.io domain to emissary.ingress.dev. Third, removing the conversion webhook. The webhook removal is blocked by the Kubernetes storage version migrator, which was folded into Kubernetes core four or five years ago and has never reached stable. The plan is to ship a simple standalone job that users can deploy themselves to migrate stored versions and confirm they are safe to delete the old ones.
The Conversion Webhook: A Concrete Workaround in Progress
V4 already defaults to not installing the conversion webhook, which matters for anyone upgrading from 3.x. The docs cover it. Flynn’s working plan is to release a standalone migration tool, deployable as a Kubernetes Job, that checks whether old stored CRD versions are still present and signals when it is safe to remove them. The storage version migrator in Kubernetes upstream remains non-stable across all current Kubernetes versions, so this standalone tool is the realistic path forward.
Project Health: Contributors Needed
The project runs on a small number of maintainers. Mark S, Phil Pevler, and Jeremy Dental did the bulk of the V4 work, with Jeremy handling production testing before the rollout. Flynn’s ask is direct: if you use Emissary and want it to continue, contribute. If you have decided to move off it, say so. Every conversation Flynn has had with users produces the same feedback: they value the input language simplicity and the developer-oriented CRD model. That validation is useful, but contributors matter more than compliments.
Q&A
Is security update cadence a concern for production users? Security updates are precisely what V4 was built to fix; the old multi-day release process made frequent Envoy upgrades impractical, and the new one-line, one-tag process removes that barrier. ▶ 9:11
Notable Quotes
Emissary 4 is out. Flynn · ▶ 0:44
there will not be another Emissary 3 release full stop ever again. So, go to 4, Flynn · ▶ 1:43
that will involve changing one line of source code and letting CI build me a release. Flynn · ▶ 4:18
4.0.1 was literally me pushing a get tag and then I think I went to dinner. Flynn · ▶ 10:41
Key Takeaways
- Emissary 3.x ships a known-vulnerable Envoy and receives no further patches.
- Cutting a release now takes one git tag push instead of a full workday.
- The conversion webhook defaults to off in V4; a standalone migration Job is planned.
About the Speaker(s)
Flynn is a technical evangelist at Buoyant, where he focuses on Linkerd, Kubernetes, and cloud-native development. He has worked in software for 40+ years with a consistent focus on communications and security, and is a coauthor of “Linkerd: Up and Running.”