Aged to Perfection: Traefik's 10-Year Journey from Zero to Standard

10 years ago on September 22nd, 2015, after months of research and hacking, I posted a link on Hacker News about this small project I'd been working on called Traefik. Honestly, I was just hoping a few fellow developers might find it useful for their own container routing headaches.

Well, things escalated quickly…

Early Days: The Microservices Wild West

Let's be honest—2015 was a bit of a mess for anyone trying to manage microservices. Docker containers were getting some hype, Kubernetes was still this intimidating thing that required a PhD to set up, and everyone was manually editing NGINX configs like it was 2005.

The problem was simple: traditional load balancers didn't understand the dynamic infrastructure of modern platforms. Your services were constantly coming and going, scaling up and down, and your poor reverse proxy was sitting there completely oblivious to what was happening behind it.

My idea was equally simple: what if the reverse proxy could just... figure it out automatically? What if it could watch your containers, understand your services, and configure itself? Or to put it differently, what if we could delegate the routing configuration to the application level. In a world where there are now hundreds or thousands of services, each should come with its own ingress properties attached to it.

The response surprised me, to put it mildly. Within a week of the public announcement, Traefik was in the top trending projects on GitHub, and I found myself frantically responding to issues and pull requests from developers around the world.

Looking back, I have to admit I had no idea this would become what it is today. I set out to solve a real life problem I was experiencing, maybe thinking that a few other microservice nerds might be facing the same issue. The idea that Traefik would eventually become such a critical piece of today’s platforms? That seemed pretty unlikely at the time.

But here we are, 10 years later, with some numbers that still make me do a double-take:

• 3.4 billion downloads on Docker Hub
• 56,000+ GitHub stars
• 5,000+ merged pull requests
• 6,000+ issues (we've accidentally created the world's most persistent TODO list)
• Nearly 900 contributors from around the world
• 500+ releases (we've been... productive)
• 26 cheeses for codenames (in fact the most important metric)
• 16 maintainers
• 1 company founded

The Maturing Process

Over the past decade, Traefik has evolved through fundamental milestones that each marked a critical innovation in the cloud-native revolution. Every major release wasn't just an upgrade—it was a response to where the industry was heading, often arriving just as developers realized they needed exactly those capabilities.

Traefik v1 started with the fundamentals that felt revolutionary at the time:

• Automatic service discovery (no more manual config updates)
• Let's Encrypt integration (because HTTPS should be easy)
• Support for Docker, Kubernetes, Marathon, and other orchestrators
• Live configuration reloading (remember when you had to restart everything?)

Traefik v2 was a major effort at future proofing the architecture:

• Complete redesign with routers, middlewares, and services
• TCP and UDP support (not just HTTP)
• Proper Kubernetes CRDs
• Middleware chaining for complex traffic handling

We'll be honest—the v1 to v2 migration wasn't our smoothest moment. We learned a lot about backward compatibility the hard way.

Traefik v3 focused on modern standards and smoother upgrades:

• Gateway API support (the future of Kubernetes ingress)
• OpenTelemetry integration (the future of observability)
• Much gentler migration experience (we learned our lesson)

Looking back, it's clear that the cloud-native industry itself underwent a fundamental shift during these 10 years. What started as a pure innovation and creativity stage—where everyone was experimenting with containers, orchestrators, and new architectural patterns—has matured into a productivity era. The wild experimentation phase is largely over; now it's about making these technologies reliable, secure, and easy to operate at scale. 

Traefik's evolution mirrors this industry transformation, moving from solving bleeding-edge problems to providing stable, production-ready infrastructure that teams can actually depend on. Traefik has consistently helped define what cloud-native infrastructure should look like. We didn't just adapt to the productivity era; we helped create the tools and patterns that made it possible.

What's Next

After a decade of helping shape the cloud-native revolution, we're not slowing down. The industry has moved into its productivity era, but that doesn't mean the innovation stops—it just becomes more focused on solving the real operational challenges that platform teams face every day.

The community has been pretty clear about where they want us to go next, and honestly, the next steps feel like natural evolutions of what we've been building all along.

v3.5: The NGINX Compatibility Layer

Let's talk about the elephant in the Kubernetes room: ingress-nginx is in maintenance mode. No new features, only critical fixes, and a growing list of security concerns that keep platform teams up at night.

This isn't just another deprecation announcement—it's a fundamental shift that will impact every team running Kubernetes in production. The controller that powers many clusters is entering its endgame, and platform teams everywhere are asking the same question: "What now?"

We saw this coming and decided to do something practical about it. Traefik 3.5 includes a brand new NGINX provider that understands NGINX Ingress annotations. That means you can migrate from ingress-nginx to Traefik without rewriting a single manifest.

No massive refactoring projects. No weekend migrations that keep everyone on edge.

You keep your existing annotations, your existing workflows, and your existing sleep schedule. You just get a more actively maintained ingress controller that's designed for the cloud-native world we're actually living in. Bonus: you can also plan a later Gateway API migration using the same controller thanks to Traefik’s flexibility.

We'd love contributions from the community to make it even better. If you're migrating from NGINX Ingress and hit edge cases we haven't covered, or if you have ideas for improving the compatibility layer, we're all ears.

The migration path is straightforward, the security posture is solid, and the future roadmap is clear. Sometimes the best innovation is just making the obvious choice easier to make.

v3.6: More Power, More Features

Version 3.6 is shaping up to address some complex routing scenarios that our community has been requesting.

Multi-layer routing is probably the most significant architectural addition. Right now, Traefik follows a simple path: entrypoint → router → service → server. Version 3.6 will let routers forward requests to other routers instead of just services, creating routing trees for complex use cases.

Think about it this way: you could have a first layer of routers dedicated entirely to authentication and authorization, then forward authenticated requests to a second layer that routes based on the user's permissions or role. No more cramming everything into a single routing decision, or weird loopback hacks—you can build sophisticated traffic management that actually matches how your applications work.

KNative integration (thanks to our community contributors) will enable Traefik to be a first-class citizen in serverless Kubernetes environments, making it easier to route traffic to both traditional microservices and serverless functions from a single ingress controller.

v4: Perfectly Aged

We're taking a different approach with Traefik v4. Instead of the traditional "big bang" major release with tons of new features and breaking changes, we're trying something smarter.

All the new features destined for v4 will actually land in v3.x minor releases first. NGINX support, multi-layer routing, KNative, enhanced Gateway API support—you'll get to use them while they're fresh, not after waiting years for a major release.

At the same time, we'll be deprecating legacy features well in advance, giving everyone plenty of time to migrate gradually. By the time v4 arrives, it will essentially be a cleaned-up version of the latest v3.x—all the modern features you're already using, minus the deprecated baggage you've hopefully already migrated away from.

You'll be able to adopt new features as they become available, migrate away from deprecated ones at your own pace, and when v4 finally ships, the upgrade should feel more like a routine update than a major undertaking.

This approach should make the v4 migration much smoother than previous major releases. Sometimes the best way to move fast is to move incrementally.

Open Source at its Best

Here's what really amazes me: more than half of all pull requests merged into Traefik come from contributors who aren't on the core team. The community doesn't just use Traefik—they improve it, extend it, and take it in directions we never imagined.

We've seen contributions from developers in dozens of countries, solving problems we didn't even know existed. Someone in Japan fixes a bug that someone in Brazil discovers. A developer in Germany adds support for a protocol that a team in California needs. A technical writer in France improves documentation that helps a team in Australia get started faster. A security researcher in India reports a vulnerability that protects users worldwide. Even feature requests and bug reports from users who never write a line of code help us understand what's needed. Every type of contribution—code, documentation, testing, reporting issues, suggesting improvements—makes the whole user experience better. It's open source at its best.

The community has written crazy providers (hello KNative 🫡), created awesome plugins for use cases we never considered (👋 Sablier), made the forum such a welcoming space (❤️ bluepuma77), and generally made Traefik far more useful than it would have been with just the core team.

Anniversary Contest

To celebrate this incredible milestone, we're doing something special. The next 50 contributors who get a pull request merged into the Traefik repository will receive a limited-edition 10th Anniversary Traefik t-shirt. These aren't just any t-shirts—we're talking exclusive anniversary design and enough geek cred to make your coworkers jealous.

The design itself is pretty special (see below). Since every Traefik release comes with a cheese codename, we've created a shirt featuring all the cheeses that have graced our releases over the past decade.

From Reblochon to Mimolette, from Roquefort to Saint-Nectaire – it's a delicious timeline of Traefik's journey. We have to give huge thanks to Pierre Keersbulik, who has been creating these awesome designs for us throughout the past 10 years. His creativity has given Traefik its distinctive visual identity, and this anniversary design is no exception.

Whether you're fixing a typo in the documentation, adding a feature to a plugin, or contributing to the core codebase, your contribution counts.

These will probably become collector's items, so don't say we didn't warn you 😉.

A Vintage Worth Celebrating

10 years ago, I had a simple idea about making reverse proxies smarter. Today, Traefik is part of the infrastructure that powers modern applications used by millions of people. Today, an entire team and community of developers continues to improve what has become a major open source project.

The cloud-native ecosystem will keep evolving, the AI revolution is reshaping our infrastructure, new challenges and possibilities will emerge, and developers will keep building amazing things. As long as there's traffic to route and services to connect, we'll be here—probably with some new feature you didn't know you needed.

Thank you for 10 incredible years. Thank you for the contributions, the feedback, the bug reports, and the debugging sessions. Thank you for the thoughtful feature requests, the patient explanations in forum threads, and the conference talks that help spread the word. Thank you to the maintainers who keep the community welcoming, the documentation writers who make complex concepts accessible, and yes, even the trolls who keep us on our toes and remind us that the internet is still the internet. Thank you for making this little project into something we're all proud of.

Here's to the next decade of making infrastructure just a bit more automatic.