Announcing Traefik v3: See All New Features | Traefik Labs

Almost five years ago, in September 2019, we released the previous major version of Traefik: v2.0. Since then, Traefik has been more active than ever. It has achieved a unique, long term traction with more than 3 billion downloads and 700+ contributors. Traefik is ranked in the Top 15 on DockerHub, has 46,000 GitHub stars, and continues a five-year streak as the #1 API Gateway according to What a ride!

We have designed this major release around a few key aspects. First of all, we added support for popular, emerging technologies—WebAssembly (Wasm), OpenTelemetry, and Kubernetes Gateway API. And then, of course, because the cornerstone of a proxy is the routing and the security, we revamped some key parts of the routing rules and added support for some leading edge technologies like HTTP/3, SPIFFE, and Tailscale.

Another critical aspect of any major release, which by design contains breaking changes, is to provide the smoothest user experience migrating from the previous version. Not only are we providing a complete migration guide, but we ensured that the transition process from the previous v2 to the new v3 has been streamlined, by ensuring backward compatibility with v2 syntax while offering a progressive path for adopting the v3 syntax.

Finally, Traefik is and has always been a community-driven project. A huge effort has been made on improving the user experience for contributors with the help of strong and clear processes within a welcoming and respectful environment.

I’m extremely proud to see that this project, born 8 years ago, has become such a critical piece of the modern cloud-native infrastructure stack, with the help of such an amazing community.

Alright, let’s jump into the details of v3 🙂

Ease of Migration

A few years back, when we introduced Traefik v2 to the world, the team was so excited to improve the project that we underestimated one thing: migration experience from v1.x to v2.x. Not that our migration plan was empty, far from that: we wrote an extensive migration guide, we even provided a migration tool to help users convert their configuration to the new format. But that wasn’t enough and let’s be honest, the adoption of this new version took longer than what we expected. Clearly, this wasn’t something we wanted to see again with Traefik v3. A major version means breaking changes obviously, but that shouldn’t imply a painful migration experience.

With v3, we are introducing a streamlined transition process from v2, ensuring backward compatibility with v2 syntax while offering a progressive path for adopting the v3 syntax, effectively overcoming the challenges encountered in previous migrations.

Here are the guidelines we followed: 

  • Obvious first thing is to provide a detailed migration guide describing every change that need to be made from v2.x to v3
  • Breaking changes on the static configuration are OK as soon as we provide user friendly logs when v2.x options are still used and link to the new v3 format
  • The dynamic configuration will support both v2.x and v3 configuration formats. Imagine a scenario with 200 ingress resources to migrate. You will be able to use Traefik v3 without any change, and you will be able to progressively upgrade your ingresses to the new format.

All in all, this should be pretty straightforward for Traefik users to adopt this new major version and we will carefully listen to your feedback to further improve upon the migration guide. 

Routing & Security

One of the fundamental purposes of Traefik is to route network traffic in a secure and intelligent manner. This is the core part of any proxy, but Traefik has always been the cutting edge. And this v3 release doesn’t disappoint with a huge number of new features and improvements.

Let’s start with HTTP, the backbone of the Internet. Since HTTP/2 was approved in 2015, a lot of work has been done on defining the next milestone: HTTP/3. And this one is big as it doesn’t rely on the good old TCP anymore, but instead UDP (being based on QUIC, a new transport protocol developed by Google in 2012). And it comes with many benefits like enhanced performance, faster connection establishment, simpler encryption, etc. HTTP/3 is now out of experimental and fully production ready in Traefik!

Another key technology that is being widely used lately in cloud-native environments is gRPC. gRPC is a modern Remote Procedure Call (RPC) framework that can run in any environment. It uses Protocol Buffers as the interface description language, and provides advanced features such as bidirectional streaming and flow control, cancellation, and timeouts. Traefik v3 now supports gRPC-Web, which adds the capability to call a gRPC service from a web app within a browser. Additionally, Jeremy Jacque added gRPC healthchecks support to Traefik.

Deploying dozens or hundreds of services in production comes with many challenges. One of them is enabling workloads to prove their identity to trust each other. Enter SPIFFE, the Secure Production Identity Framework For Everyone Project defines a framework and set of standards for identifying and securing communications between application services. Thanks to Julien Levesy, Traefik now supports SPIFFE mTLS with its backend servers!

Traefik had a routing syntax that was already very powerful, but we figured out that some parts could be further improved and unified to make the user experience even better.

If you need to protect websites within a Tailscale network, Traefik can now request TLS certificates from the Tailscale API (provisioned with Let’s Encrypt)! The long-awaited Brotli compression algorithm support was added by Greg Linton which in short means quicker website loading. Michael Kuhnt brings SNI routing with Postgres STARTTLS. And finally, you are now able to fully configure your TCP server transports.

As you can see, the work that has been done is just insane and reinforces the pioneering routing & security capabilities of Traefik while sticking to the original virtues of a smooth user experience and top-notch performance.

Augmented Traefik 

Back in 2019, with the release of Traefik v2, we had introduced an extension engine, Yaegi, that enabled many to develop middleware (or providers) for their context. To this day, we can count more than a hundred middlewares made available through the catalog, plus many more that are kept private. 

Yaegi is an extremely powerful engine whose boundaries go beyond Traefik itself. Given its nature though, Yaegi still requires much work to support the full Go specification and to keep up with every release of the language. This can sometimes result in difficulties in adding very challenging features.

Another extension technology we have been looking at for quite some time is WebAssembly (Wasm). Until today, we were not satisfied with current ABIs (Application Binary Interface) like proxy Wasm because they were closely designed with other technologies in mind (Envoy), making it hard to leverage in our context. With the release of http-wasm providing a standard ABI designed to match the HTTP handler mechanism built-in with Go, the game changed. Thanks to this technology, in less than 3 months, a contributor jumped in and tackled the necessary work to introduce a contributor jumped in and tackled the necessary work. 

You read it correctly: you can now leverage Wasm to develop plugins in traefik, removing any existing hurdle and expanding the field of possibilities. 

Many thanks go to Jesse Haka for the bigger chunk of the work involved, and José Carlos Chávez for the review effort.

Everything, Everywhere, All-at-Once Observability

With its central place in your architecture, making decisions on your behalf about where to route requests, Traefik made observability one of its core features since v1, supporting many vendors for metrics and tracing analysis.

With the advent of OpenTelemetry, it sounded natural that Traefik would pave the way for adoption and encourage our users to migrate to state-of-the-art toolings. Once again, we can thank Jesse Haka for this contribution.

For Metrics, where Traefik already supports a large panel of vendors with wide adoption (Datadog, Prometheus, and others), we added OpenTelemetry as a cherry on the cake: you can start migrating to a newer stack without compromising your well-established monitoring toolchain. 

Tracing was a different story: Traefik had been an early supporter of two standards (OpenSensus and OpenTracing) that have now merged into one. The adoption is already there, and the migration path is well known. As a result, we dropped support for the previous standards in favor of OpenTelemetry.

But OpenTelemetry is not the only trick Traefik 3 has in its hat around observability. For gRPC enthusiasts, we added support for proper health checks. A one-liner that will change the lives of many, at least at work or in the lab. Thank you Jeremy Jacque.

And my own personal favorite, speaking to the geek side of us, we changed the logger system for a zero-allocation (read “better performing”), structure-friendly, rotation-aware logger. This apparent small tweak will make the whole experience of understanding and debugging your system much easier.

Team Player Traefik: Kubernetes & Friends

For those of you Kubernetes heads, chances are you’ve always seen Traefik as your ingress controller of choice, and that you have adopted IngressRoutes as a clean way to get rid of the limitations of the good old (especially old) Ingress specification. This opened the door to many benefits: declarative and more routing options to name two.

Still, Kubernetes is evolving, and Traefik was part of the Gateway API vanguard, supporting the first alphas. It’s no surprise that we’re bringing full support of the Gateway API specification that is now officially out.

The power of Kubernetes also lies in its vendor ecosystem, allowing DevOps to pick the best tools available. In that regard, Traefik has always been a team player, supporting many vendors, third-party orchestrators, observability components, and key-value stores to name a few. Based on popular demand amongst users and customers alike, we are thrilled to share that Traefik v3 comes with better support for Hashicorp’s Consul (for meshing that requires special TLS management) and Nomad (for namespace support). On the latter, we can thank Thomas Harris.

Maybe the best way to end the list is a non-feature that maintainers adopted wholeheartedly: our commitment to make the Traefik v3 experience the best it can be, from using Traefik to actively contributing to the project.

Yes, Traefik has always been open-source and contributions have been at the forefront of each version. Still, despite a strong commitment to sorting each incoming issue and PR, we concurred that maintainers could better document their thoughts around these contributions. Not only for us as a group of maintainers working async but as a testimony to enable contributors for action. 

As a consequence, we reinforced our stance to ensure several key points: 

  • Always spend the extra time so each interaction is welcoming, open, and clear
  • Always prioritize contributions over our own agenda 
  • Always document the ongoing work for easy collaboration
  • Always create proposals for upcoming features

These small tweaks almost instantly empowered some key contributors who brought two of the biggest features of Traefik v3, namely Wasm support and OpenTelemetry.

We just can’t wait to welcome even more contributors and additional features in the near future.

Next Steps

Like in the previous major release v2, Traefik v3 shows the importance of the community. Every feature that has been discussed today was born from a user asking for it, reporting a bug, or just asking for something “better”. Critical new features have been completed by external contributors, and, to me, this demonstrates a healthy and vibrant open source project.

A release candidate is the beginning of a release process. To make it to GA, we will need your feedback, comments, and ideas to make this landing as smooth as possible. To get involved, you can download Traefik v3 from DockerHub and help us shape it via our OSS Project on GitHub.

Additionally, if you’d like to receive regular updates via email as v3 heads towards GA, sign up here.

Finally, I want to send a huge thank you to all contributors. Your help is invaluable.

See you on GitHub!

Useful Links

This is a companion discussion topic for the original entry at