Skip to content

v1.6.0

Latest

Choose a tag to compare

@github-actions github-actions released this 19 May 09:30
33bfb64

func-e 1.6.0 gives you yesterday's envoy main build via the "dev" version

Before, testing pre-release Envoy with func-e meant compiling it yourself or using Docker, which only worked on Linux. Now you can install and run dev builds on all platforms the same way you would any tagged version.

$ ENVOY_VERSION=dev func-e run --version                                                              
downloading https://archive.tetratelabs.io/envoy/download/dev/envoy-dev-darwin-arm64.tar.xz
starting: /Users/codefromthecrypt/.local/share/func-e/envoy-versions/dev/bin/envoy with logs in /Users/codefromthecrypt/.local/state/func-e/envoy-runs/20260518_170024_807

/Users/codefromthecrypt/.local/share/func-e/envoy-versions/dev/bin/envoy  version: abbadd905fa486ff1085cf3bbe4f3b73eb6dd8e0/1.39.0-dev/Clean/RELEASE/BoringSSL

$ func-e versions -a                                                                                  
  dev 2026-05-18 (a8d396eb)
  1.38.0 2026-04-23
  1.37.2 2026-04-10
-- snip--

This works because envoy's version manifest was recently updated with a special "dev" key backed by a daily pipeline job, which archives linux from envoy's docker image, and builds macos from the same SHA.

Updating the "dev" build with the "dev-latest" alias.

dev installs on demand like all other versions and stays put once pulled. The alias dev-latest compares the remote release date against the local install and re-downloads only when the build has changed. func-e use dev-latest persists "dev" in the version file, so it is a one-shot refresh, not a stored preference.

Why Use An Envoy "dev" Build?

Envoy releases are worth the wait, but they land about once a quarter. The dev build is for the gap between “merged” and “released”: you can try current Envoy mainline without building Envoy yourself or relying on a Linux-only Docker workflow.

For example, Envoy 1.39-dev already has new dynamic-module support for request-aware upstream selection. A dynamic module can parse a request, write selected_backend or selected_endpoint into request state, and have the cluster read it while choosing the upstream host. That removes the need to pass routing decisions through synthetic headers or route re-selection.

Use dev when you need to test an unreleased feature, validate upgrade impact early, or give feedback before the next Envoy release is cut. Use tagged versions for normal production runs.