I use Traefik for local development on daily basis, where I have to run double digit https services. It works, but it was a pain to set up. The documentation sucks ** and the config is confusing AF. I would never recommend this to anyone. If i will have to reinstall my computer one day, Traefik will not be welcomed back.
Documentation quality has been a common complaint. Previously, we only provided reference documentation and relied on the community to create tutorials and guides.
Based on feedback like yours, we've completed documentation rewrite. Have you had a chance to review the new version? Your feedback is taken very seriously, so we'd greatly value your thoughts on these improvements.
I am unable to give you feedback as I have no need to use the documentation at this time and going over it without having a need to find something would be pointless. And I have set up my local Traefik instance quite some time ago, so I do not remember my struggles back then.
We recently just deployed Traefik at $job, and found it pretty easy! I didn't do the work myself, but I directly managed the engineer deploying it. It was predominantly reference material but that was really all we needed to get it set up.
Hi there. I'm a brand new Traefik user. It's bundled with k3s, so I set it up for my homelab on a single node cluster. I'm a technology professional who has worked in infrastructure and software roles for more than 15 years.
I appreciate that you revised the docs, but I still found it quite difficult just to get started. My experience was poor enough that I almost switched to Caddy. The thing that kept me from doing that is that Caddy requires a custom container build for DNS-01 ACME challenges which I didn't particularly want to deal with. I found Caddy's documentation much easier to grapple with, so that could serve as some inspiration.
I have some feedback I'd offer of my own, too:
1. I'd recommend you take a look at the Divio documentation system: https://docs.divio.com/documentation-system/. Your documentation aligns to this vaguely, but I'd recommend reading about the different doc types and applying that feedback throughout the docs.
2. Traefik's tutorial and how-to docs are very dense and feel overwhelming. [1] Related to my first point, I think you're trying to provide too much information in the wrong places. Tutorials and how-to guides should be very focused and limit explanation to only that which is absolutely necessary.
3. Reference and understanding docs are mixed together. I'd recommend using an approach more like Caddy's, where the config reference (https://caddyserver.com/docs/json/) shows prominently what the expected config schema is, and all of the fields are explained briefly. If there is very nuanced behavior for a particular option, consider moving that to a separate reference or explanation page.
4. Having a few How-To guides for the most common patterns which include complete configurations would be helpful.
[1] Here are some concrete examples:
- On https://doc.traefik.io/traefik/setup/kubernetes/, there is a whole introductory session about setting up Kubernetes and I have to scroll before reading anything related to Traefik. It's not only unnecessary -- it's noise. Nobody is going to consult Traefik's docs for setting up Kubernetes, so just omit it.
Oh, the static/dynamic split is brutal (and I believe some options have been moved around)...
Once you referenced routers, middleware and services simply by name, but that changed into per-source scoped versions (e.g. service1@file, middleware@docker).
I kept bumping into those edge cases (custom SSL cert set-up was really confusing), but thanks to chatgpt, I at least ended up with workable solutions.
I really like how it can be easily configured from Docker labels (from Portainer for example), or from your big production Consul cluster alike. But yeah, the docs need a lot of work, it’s difficult to figure out the format many times, it lacks examples, and things that need to be enabled together have their docs at different places.
Your point about having to enable two different things at the same time in two different places is a concise way of expressing my extreme frustration with that project.
I burned the better part of a Saturday trying to figure out why a relatively straightforward configuration wasn't applying and it's because one half of the configuration that I was trying to apply has to be done in the static manner and not the dynamic manner.
Documentation doesn't really spell this out and after quite a bit of frustrated googling I found a few other people complaining about effectively the same problem. It's only a few lines of code to spit out something along the lines of "hey, you're trying to configure ¢thing in an inappropriate way. Did you mean to configure ¢thing over in €thisLocation?" message... But nope, that would make things so much simpler and easier to use and probably cut into their support contract sales...
Now I basically just stick with nginx because it's documentation isn't crap, useful and applicable examples are all over the Internet.
> Sticking to nginx seems not to be an option for many as at least ingress-nginx will not be get any new features anymore (as mentioned in the article).
For k8s, yeah. It should still be a useful tool for other things? Or did i miss a memo about nginx being EOLd?
Yeah, kinda have to agree. I like traefik fine but getting mTLS working with it was a serious pain and the docs for doing so were _terrible_, had to keep searching around and piecing together bits from various third party blogs. Coming from haproxy where the documentation is _so_ _much_ better and things like e.g. mTLS are vastly easier, it was not a fun experience but we did finally get traefik to work as we needed.
I wonder how you are using it. I am mainly using Traefik with docker compose labels and it was not that hard to set up once you understand the concepts of routers, middlewares and services. I would use it for any homelab that has to host more than one service.
I also recently started playing around with web UI layer that generates traefik json config. Currently it is quite basic since it was initially made to provide limited time access to development instances but it could in theory manage most important aspects of proxy config and replace something like nginx-proxy-manager. https://github.com/Janhouse/traefik-proxy-admin
I was once tasked with looking into using Traefik and yeah the documentation at the time was so bad I couldn't figure it out. Ended up using Envoy IIRC.
Yeah same here. Caddy is so well designed. I hated traefik from the start and even though it works now I still hate it. The moment I used caddy everything was clear and just worked. Basically what nginx used to be 15 years earlier. But it didn't really keep up with the times and they care more about the commercial thing now.
I have the opposite opinion. Traefik documentation is good if you take the time to read and comprehend it - and it has gotten significantly better over the last few years, it being bad (e.g. "it sucks") is an old trope at this point. I don't use Caddy or nginx because of the first class routing and middleware capabilities of Traefik. I've got it deployed in dozens of services and it's so easy to use one you've solidified your boilerplate that everything else, to me, appears to be a pain now.
To each their own but it's interesting you find it useful (you use it) yet it won't be welcome back. Maybe, as others have noted, try it in Docker (or k3s/k8s/etc). Once the base configuration you want is configured and deployed all you need to do is place labels in for dynamic service configuration.
Yeah I deal with it because it's part of the ansible matrix playbook. But I hate it, I always have issues with it. Complex configs, things not quite working right.
Nginx which they used before works much better. And these days I use caddy on everything else. That really shines.
I have completely opposite experience. To me Traefik is the easiest thing to work with on the market. It should be even easier now to setup using Agentic AI.
Quite a bold claim there about being "standard" :D
At one point I was using nginx for my local RPi deployment handling of various services with docker-compose but ultimatelly switched to Caddy and it made everything so simple :)
It’s modern day age of aura farming/seo hacking/clout chasing.
Just claim you are standard and then LLM crawlers pick up on it. The next generation is trained to just ask ChatGPT/Claude/Gemini/{w/e dogshit LLM} and they will unfortunately believe it.
Throw in some more keywords and signals like GH stars, docker container downloads to sell it.
Might not work now but it’s a small gamble that may pay off in the future.
> Just claim you are standard and then LLM crawlers pick up on it
That's very interesting. Hadn't thought about this PoV. LLMs definitely /can/ empower the wrong kind of behaviour, just like SEO did... and they amplify it a lot by not really showing sources.
To be fair this predates LLMs, SEO crowd was doing this even before to try to get into Google Answers, and before that to have a favorable-looking summary under their blue link.
The entire industry is full of tricks that may or may not work, seems closer to magic rituals than anything else. It's genuinely pretty difficult to analyze how well SEO tricks perform, so there's a lot of "wow, this site is doing well, let's try to copy the success by emulating its patterns randomly" going around.
There's a lot of mentions to Caddy here. Haven't used it as, back in the day, there was something funny about its license and binary distribution. AFAIK that's not a problem anymore, isn't it?
From people that migrated from Traefik to Caddy... What are the main differences? Anything you really miss?
I use Traefik in a bunch of small deployments, sometimes pointing to Docker stuff, sometimes outside of Docker, Kubernetes, or anything similar.
Caddy is dead simple. Like, send https://example.com to 1.2.3.4:5000. That’s it!
Certificate provisioning, TLS configs, TLS termination, mTLS and client certificates, sticking in middlewares, … are all simple. The config is a straightforward text file. Really good webserver!
Traefik is docker centric, and had various obscure labels. Too much text for a simple proxy. The debugging can be an issue if it doesn’t work. It also takes more resources. But it can probably do more, if you have a complex need.
Does Caddy automatically detect when you deploy a new Docker service and reconfigure itself to route traffic to that service? That's pretty much the main value preposition of Traefik for me. I don't want to be messing with config files when I'm deploying.
Yes, there's [caddy-docker-proxy](https://github.com/lucaslorentz/caddy-docker-proxy) which I personally use in my homelab. It will read and update on docker compose labels to configure the route. Highly recommend.
Traefik is also a web server like Apache or Nginx and it does integrate with Docker. I thought that feature was like the entire reason to use Trafik, so I guess I just find the comparison a bit strange.
Traefik is a reverse proxy and load balancer that automatically discovers services and configures routing rules dynamically through integration with various configuration sources such as container orchestrators (Docker, K8s, Nomad, Consul, ECS, ...)
For the use case of network routing for services running in containers, OpenRun provides a simpler abstraction. It does the container management and the network proxying.
Yeah, don't know exactly why, but when I've had problems, debugging Traefik has been kinda frustrating.
Also, I feel like they've slowly moved focus to Docker during the years, and I find the file based configuration more and more difficult (or worse documentation maybe) every time I go back to the docs.
Maybe you're thinking of the drama involving Caddy putting sponsorships into its Server header. They walked that back relatively quickly and hasn't been a problem since then.
Back when they both were on the rise, they felt equivalent. I haven't deployed Traefik in a long time but as far as I remember, Traefik's configuration is more service-discovery oriented. While they both are capable of working with a static set of hosts, it felt like Traefik made it harder to configure for a static set of upstream servers while Caddy made it much easier. Traefik almost started off with the assumption that you would have some service discovery of some sort.
You are right, Traefik is fundamentally built around the concept of "providers," which are external systems from which Traefik obtains routing configuration and service/server definitions.
These providers can range from dynamic service discovery systems (like Docker, Kubernetes, Consul) to static configuration sources (file-based configs, HTTP APIs, etc.). The provider architecture is what makes Traefik particularly well-suited for containerized and cloud-native environments where services are ephemeral and discovery is crucial.
Ah, I didn't remember that. I've been googling a bit and I think this was it [0]: binaries on their download page or GitHub releases were only usable on a personal basis. If you were to use them in a company, even internally, you needed to get a commercial license or build the binary yourself.
I guess one possible gotcha I can think of is, be prepared to build your own binaries/images if you aren't already. Some bread-and-butter features like L4 proxying depend on plugins and aren't part of the core package. It's good to self-build for other reasons, just sayin', distro versions or the official docker image will only get you so far.
Also iirc not all such functionality is actually available when configuring via Caddyfile so it can be confusing if you expect that and don't realize you need to switch to json/yaml configuration to do what you want. A little remniscient of the Traefik static/dynamic confusion ;)
All good, just things that can be different than what you are used to and expect.
So much hate for Traefik here. I don't get it. I personally use it and find it amazing, but I read elsewhere that their enterprise offering is prohibitively expensive.
I wish them to succeed, Traefik has been one of my favorite choices for Kubernetes for a long time now :)
Wdym TLS is an enterprise feature? I'm using mTLS and TLS in their OSS version. The certificates are generated via cert-manager. If you expect something like Caddy's auto-provision of certs, then (AFAIK) neither HAProxy nor NGINX have it
I can confirm that bring-your-own certificates, ACME, and mTLS are all included in the OSS version. For enterprise users, Traefik Hub also provides seamless integration with HashiCorp Vault.
Regarding the cache middleware: like many of our more advanced middlewares, you have two options. You can use a community-maintained plugin (such as Souin), or your organization can purchase an enterprise license to access TraefikLabs' officially maintained built-in middleware as part of Traefik Hub API Gateway or Traefik Hub API Management.
Congratulations on the 10 year anniversary. Having used Traefik for multiple years in a large Micro-Service Setup (200+ services) I must say I have made mixed experiences. If your requirements match the very opinionated way Traefik does things then it's great. But as soon as they don't you're going to have a hard time getting things to work. That's why shortly after migrating to Traefik I started to maintain an internal fork to add support for unique request ID headers which I maintained for two years until we migrated to HaProxy. The GitHub issue I opened for this in 2019 is still open.
To be fair I used Traefik back when it was still version 1.7 so maybe things have improved by now.
Yea, envoy is the premier open source (not open core+ paid features) proxy right now in my opinion. Modern, well supported, big community, reliable. If I was making a bet long term I would be looking at envoy and not some open core crap where they can rug pull you at any moment.
A whole bunch of the other ingress/k8s gateway offering also just…wrap envoy, so you may as well just use envoy directly these days. Especially given that configuring it, wasn’t any worse than configuring a wrapper with the additional benefit of not having anything between you and envoy to get in the way.
How did they "win" when xds, envoy's config, is becoming the defacto interface to LBs? Sure, Gateway API is kinda xds by not, but it's envoy all the way down.
I don't generally use/need Traefik. But the cheese shirt makes me unreasonably happy, and if it appeared for sale on some easily accessible site for a decent price, I'd very likely order one.
A significant portion of TraefikLabs' engineering team and maintainers are French. Before each new release, the team holds polls and spirited debates to determine which cheese would be the perfect fit for the version name.
Staying true to French culinary tradition, the enterprise versions are given wine codenames, with each wine carefully selected to pair perfectly with its corresponding cheese release.
Well hey, if you can fix the ACME key reuse issue [1], which is just a Traefik mis-use of the underlying library (by the same authors!!!), you can just get one!
I agree “standard” is not the right word here. Traefik is very popular in self hosting community, probably the most popular proxy in my experience, followed by NPM (nginx proxy manager) and Caddy as distant third.
Docker swarm v1 is dead, v2 ("swarmkit") is usable. Although, if you want to use it in production, you're probably better of with K8s. Don't get me started on docker using "the same" (but subtly different) file format for its different offerings (compose v2, swarm v2).
For smaller setups maybe look into podman with K8s config files (did not try myself yet).
Low resource footprint, written in Go, embed-able in any Go project as a library, compiles to mobile with little to no modification, supports config change without restart, has plugin API.
These were the reasons why we used it in my previous job.
Integrates with Docker Compose with the its Docker config provider so I can configure Traefik for my services through Docker labels, not in the central Traefik instance
HAProxy's documentation is pretty bad (almost entirely of the style "here are all the parameters and options available, no concrete complete examples)".
Traefik has easy to parse docs with lots of examples, and mostly, it can autoconfigure itself based on a variety of sources. You can point it to your Kubernetes or Nomad or Consul, (and with small bits of info given when deploying your workloads to those places), and it just works.
Because Traefik is lightweight and if you know Go, it can be even easier to get going as you can browse the source code and figure things out.
HAproxy on the other hand is the big daddy of proxies. The pinnacle of high performance. There are few use cases where this makes sense. Definitely nothing for development environments.
Easy to configure, straightforward and intuitive. Clear and detailed documentation. Recently, I wanted to try HAProxy, but I gave up because I got lost in the config, and I don't trust AI agents to do things I don't understand.
I use and appreciate both Traefik and Caddy. I like that Traefik includes TLS termination, whereas the equivalent functionality with Caddy requires compiling a separate module with xcaddy.
I'm pretty sure that's how I'm already using Caddy, and I didn't compile anything separate. Maybe it's packaged automatically as part of the Caddy Docker image?
My original comment probably wasn't clear enough, I meant to say that caddy doesn't support layer 4 TLS termination without third-party modules. For example, if I wanted a reverse proxy in front of a Gitea instance that would terminate and route TCP packets to/from port 22... this is something Traefik can do out of the box.
We plan to move layer4 into the standard Caddy distribution eventually. We're still stabilizing it, and once we're happy with it (and have the time and energy to) we'll bring it in.
Exciting! Looking forward to it. I end up needing xcaddy for a few other modules so it's not that big of a deal, but I always feel better using first-party functionality over relying on third-party modules.
There's even a great docker with caddy and the cloudflare DNS-01 module built in which was just what I needed. That saved me having to deal with xcaddy (it was ok, but compiling was slow)
Horrible read. That whole post is nothing but gratuitous self-importance. Just don't use llms for something like this... it just gets over the top really easy.
I host a couple of web services like Nextcloud and Overleaf instances (Docker) and I use nginx as a reverse proxy. What would be the benefit of using Traefik instead? Traefik can handle things such as TLS certificates automatically, but that seems a rather weak reason to move away from a robust and modular setup where each component complies with the Unix philosophy or doing one thing well.
I use nginx as Gateway (Reverse Proxy) and have several VMs with services deployed using Docker Stack. Traefik acts as reverse proxy on the VMs. Main benefit IMHO: configuring services/routing using docker labes and because they run in dedicated networks, no need to expose any port (Internet -> Nginx -> Traefik -[> Service ] ; wheras [ ] indicates a docker overlay network.
Yeah, I don't use Traefik I use Caddy with https://github.com/lucaslorentz/caddy-docker-proxy to achieve configurations by labels, but that is really a killer feature. All the config to set up an app can go in a docker-compose file and I just have one point of configuration for it. Editing or deleting it doesn't involve editing configurations in 3-4 places.
Used Traefik a couple times in my homelab, would’ve been circa 2017/2018.
Worked great when it worked, otherwise it tended toward breaking ungracefully and confusingly.
Tried it again for a short time in 2022, rock solid, no complaints.
I’m glad to see the project’s maturity has kept up! Congratulations on ten years!
I use traefik in my home network as the main reverse proxy.
I don't use any of the dynamic features though like labels in docker containers etc, all of it is configured using the static configuration. It's been working well but I don't think about it really.
Congrats on a decade! Time flies. I think I first heard about Traefik from a GopherCon talk, and it quickly became a default for me when working with Kubernetes.
Still not entirely sure how to pronounce the name though...
Looking for a Rust-based alternative to a battle-tested industry-standard tool written in a memory-safe language that can get about 75-90% of the speed of Rust is kind of pointless outside embedded context.
Not really, sometimes it's just a curiosity. And 15% is nothing to scoff at in terms of speed, if it's available why not take the extra speed, is my opinion.
I'm interested in the space, but until they have automatic certificate management and middleware for managing DNS records in Cloudflare (for example), then I'm reluctant to switch over.
Thanks, I'm looking specifically for a Rust based one, as I know there are lots of proxies in other languages but few in Rust, and I'm just curious if anyone has suggestions on that.
When I wanted to move to something besides NGINX proxy manager, it was caddy or traefik. At the time, tutorials for the clueless like myself were way more abundant for Traefik. Thats the way I went. Now I also have Authentik up in front and it works great.
I am actually playing around with something similar to nginx proxy manager but for Traefik. It's quite early version but already now it's nice for quickly sharing some services with people temporarily. https://github.com/Janhouse/traefik-proxy-admin
I personally use it in homelab together with docker label based configuration. Adding headscale in the mix allows easily serving my development services with outside world.
Traefik's F/OSS projects are useless to me. Every single feature that I need to use is locked away in a closed source product.
Close to the same issue with Varnish Enterprise. Why would I pay for Varnish Enterprise if I can't even review or extend the source? Know what I have to do with Varnish's source once a quarter? I have to look at it. Because the documentation is non-existent. The closed source version is going to make my life objectively worse.
Aside from NGINX, Postgres, and memcached, I've had to patch every major piece of software in my stack at one point or another. I refuse to use any product that I can't fix myself.
It's current year, why are JWTs only supported in the closed source/enterprise versions of Varnish, NGINX, and Traefik?
I happily give $1,000/year to Django and lesser amounts to other projects that I depend on. Do you know how much I spend on projects that put features behind a closed source product? Zero. I will never pay for that.
I don’t think this is representative of the majority of traefik’s users. Most of us use it as an HTTP entrypoint for a container stack (docker compose, in my case) or for local development, and the FOSS version works great for that, with better dev tooling than anything else i’ve seen.
> I disagree. If you're a heavy Traefik user you're eventually going to need a feature that has been carefully omitted from the F/OSS projects.
Ok, I use it at home as part of my K8s cluster. I haven't once come close to needing a feature I don't have because it largely does what I need as a proxy and gets out of the way.
What features do you feel a more average of the target audience is likely to need or want to pay for eventually?
Sure, it's a choice but I think it's more that don't pretend you are open source when your carefully hide things behind closed sourced paid licenses. Be like Microsoft, we have eval version but if you want to use our Windows Server, you will be paying up. Cool, I can make a decision about your software with that in mind.
Do they not provide source under commercial license to enterprise users? It makes sense to not use in production if you need source to make sense of features.
By contrast, Kong Enterprise gave us source access to commercial offering plugins we needed. Not to all things but the things we needed yes.
...shouldn't you be paying then? Expecting developers to work for free to provide you with a product you use heavily is acting pretty entitled.
Just to give a contrasting account, I have been using Traefik to manage my public server (a $4 Digital Ocean VPS running a web server and a Bluesky PDS) and my local home server (running dozens of services with all kinds of weird configurations) flawlessly for more than 5 years now.
No. That is emphatically NOT entitled -- if the Traefik people have made heavy use of "open source," either practically or in marketing.
If you tout "open source" ideas in the work you do, then you can reasonably be held to the social contract that the ideas of open source originate in.
Lately (by lately I mean maybe the last 20 years or so) there's the idea of "because the open source ish company needs to pay the bills, they can completely abandon the ideas of open source."
Nah. You took from the commons, the commons has at least SOME right to ask for something back.
> If you're a heavy Traefik user you're eventually going to need a feature that has been carefully omitted from the F/OSS projects
That's literally the point of open core software. It's free and open source at the core, but "enterprise" / "scale" features are behind a license.
Enterprises/Scaled users that can pay, have to, to get the features they need. Everyone else can enjoy and profit off fully free and open source piece of software.
Win-Win-Win.
It's probably the only software business model that allows for a company to actually make money while also giving out most of their products for free as open source. Just selling support/services does not work and does not scale. Cf. literally everyone, the only orgs that somewhat pull it off are foundations/volunteer based projects like Django, Debian, etc but they are not commercial for-profit entities (there is nothing wrong with that, but most people want to be paid well). And your $1k/year, while decent towards a volunteer organisation, would be probably worse than nothing for a commercial company that has costs associated with each contract (legal, administrative, support, etc). For a fun story on the topic, check out HashiCorp's first commercial deal with Apple for a Vagrant plugin, that resulted in HashiCorp losing money on the deal due to the amount of money spent on lawyers reviewing Apple's terms and time spent supporting them afterwards. The only existing somewhat exception is Red Hat, but even they have moved more and more into open core with Ansible Automation Platform and OpenShift, which are their money makers, and have scrapped CentOS as a RHEL compatible free OS.
Same. At this point I've spent more time in devops moving away from shit that does this, and then doing it again, just to keep things as they are in a way that can be trusted. It fuckin sucks
I’ve deployed Traefik in-front of Kubernetes on some moderately large traffic sites with and without enterprise licensing. Recently I switched to using Caddy though. I know the stigma is that Caddy is not “production” ready and battle tested but I haven’t encountered any issues with it in terms of performance. It just works. Let’s Encrypt with CloudFlare DNS verification is super easy to setup and the configuration is very intuitive.
> It's current year, why are JWTs only supported in the closed source/enterprise versions of Varnish, NGINX, and Traefik?
I've found auth at the proxy to be a major antipattern. It adds a semblance of your backend being secure without adding the real user authentication and authorization it should have directly.
VPN is the better tool if you want to keep certain projects hidden from the general public and your application should be handling the JWT (hopefully in current year we're talking OIDC or some additional open standard on top of JWT) itself in order to properly enforce access controls.
With JWTs I don't do anything at the proxy beyond "This is a protected route. Is there a JWT? Is it valid? No to either? 403." This is one of the primary use cases for JWTs and it takes a majority of the load off of my application servers.
The route is open to the public for authenticated and authorized users. You wouldn't use a VPN here.
That's really just added work, IMO, and likely room for security misconfiguration between backend and proxy. You should still be validating and everything on the application server to inspect identity and possibly attributes like roles, so in the cases where you have invalid tokens you do the work once, just in the proxy instead of the backend, and with valid tokens you will do the signature validation work twice.
Have you used JWTs in production? Better to bounce a bad JWT with a server written in C/C++/Rust/Go at the edge than to pass it back and have it tie up a Python or Node process.
Even in Python the time to validate a small JWT is negligible. At the edge it's nearly imperceptible.
The problem is that you would be one of the 1% doing that, the rest of the companies would just not bother with that and it will end like many open source problems that constantly have to come up with ways to get funding.
The first this I ever do when setting up k3s is pass --disable-traefik I don't know what it is, I never used it, never had the motivation to look into what I am losing out because everything else I am familiar with already works and I don't have many complains. I do not remember why I have this opinion, but I usually only treat software like this when they're trying to sell themselves too hard.
I use Traefik for local development on daily basis, where I have to run double digit https services. It works, but it was a pain to set up. The documentation sucks ** and the config is confusing AF. I would never recommend this to anyone. If i will have to reinstall my computer one day, Traefik will not be welcomed back.
Traefik maintainer here.
Documentation quality has been a common complaint. Previously, we only provided reference documentation and relied on the community to create tutorials and guides.
Based on feedback like yours, we've completed documentation rewrite. Have you had a chance to review the new version? Your feedback is taken very seriously, so we'd greatly value your thoughts on these improvements.
I am unable to give you feedback as I have no need to use the documentation at this time and going over it without having a need to find something would be pointless. And I have set up my local Traefik instance quite some time ago, so I do not remember my struggles back then.
We recently just deployed Traefik at $job, and found it pretty easy! I didn't do the work myself, but I directly managed the engineer deploying it. It was predominantly reference material but that was really all we needed to get it set up.
Hi there. I'm a brand new Traefik user. It's bundled with k3s, so I set it up for my homelab on a single node cluster. I'm a technology professional who has worked in infrastructure and software roles for more than 15 years.
I appreciate that you revised the docs, but I still found it quite difficult just to get started. My experience was poor enough that I almost switched to Caddy. The thing that kept me from doing that is that Caddy requires a custom container build for DNS-01 ACME challenges which I didn't particularly want to deal with. I found Caddy's documentation much easier to grapple with, so that could serve as some inspiration.
I have some feedback I'd offer of my own, too:
1. I'd recommend you take a look at the Divio documentation system: https://docs.divio.com/documentation-system/. Your documentation aligns to this vaguely, but I'd recommend reading about the different doc types and applying that feedback throughout the docs.
2. Traefik's tutorial and how-to docs are very dense and feel overwhelming. [1] Related to my first point, I think you're trying to provide too much information in the wrong places. Tutorials and how-to guides should be very focused and limit explanation to only that which is absolutely necessary.
3. Reference and understanding docs are mixed together. I'd recommend using an approach more like Caddy's, where the config reference (https://caddyserver.com/docs/json/) shows prominently what the expected config schema is, and all of the fields are explained briefly. If there is very nuanced behavior for a particular option, consider moving that to a separate reference or explanation page.
4. Having a few How-To guides for the most common patterns which include complete configurations would be helpful.
[1] Here are some concrete examples:
- On https://doc.traefik.io/traefik/setup/kubernetes/, there is a whole introductory session about setting up Kubernetes and I have to scroll before reading anything related to Traefik. It's not only unnecessary -- it's noise. Nobody is going to consult Traefik's docs for setting up Kubernetes, so just omit it.
- https://doc.traefik.io/traefik/setup/kubernetes/ and https://doc.traefik.io/traefik/getting-started/kubernetes/ are different pages which seem to explain mostly the same things. They both include too much irrelevant information, like overly explaining what Helm commands do. Similar to the previous point, it is not the job of Traefik's documentation to explain Helm to me.
Thanks for the detailed feedback. This is exactly the kind of input we need.
We're going to work through these points with the team. Appreciate you sticking with Traefik despite the documentation friction.
Thanks for building a cool piece of software!
Traefik really is awesome once you can get your head wrapped around the configuration.
Oh, the static/dynamic split is brutal (and I believe some options have been moved around)...
Once you referenced routers, middleware and services simply by name, but that changed into per-source scoped versions (e.g. service1@file, middleware@docker).
I kept bumping into those edge cases (custom SSL cert set-up was really confusing), but thanks to chatgpt, I at least ended up with workable solutions.
OMG yes. I want to like Traefik, but the thought having to set it up again is not something i look forward to. Why cant it just work out of the box?
Caddy is probably my new favorite. It works out of the box, its super low resource, handles a ton of traffic, and the docs are decent.
I really like how it can be easily configured from Docker labels (from Portainer for example), or from your big production Consul cluster alike. But yeah, the docs need a lot of work, it’s difficult to figure out the format many times, it lacks examples, and things that need to be enabled together have their docs at different places.
Your point about having to enable two different things at the same time in two different places is a concise way of expressing my extreme frustration with that project.
I burned the better part of a Saturday trying to figure out why a relatively straightforward configuration wasn't applying and it's because one half of the configuration that I was trying to apply has to be done in the static manner and not the dynamic manner.
Documentation doesn't really spell this out and after quite a bit of frustrated googling I found a few other people complaining about effectively the same problem. It's only a few lines of code to spit out something along the lines of "hey, you're trying to configure ¢thing in an inappropriate way. Did you mean to configure ¢thing over in €thisLocation?" message... But nope, that would make things so much simpler and easier to use and probably cut into their support contract sales...
Now I basically just stick with nginx because it's documentation isn't crap, useful and applicable examples are all over the Internet.
Sticking to nginx seems not to be an option for many as at least ingress-nginx will not be get any new features anymore (as mentioned in the article).
> Sticking to nginx seems not to be an option for many as at least ingress-nginx will not be get any new features anymore (as mentioned in the article).
For k8s, yeah. It should still be a useful tool for other things? Or did i miss a memo about nginx being EOLd?
Yeah, kinda have to agree. I like traefik fine but getting mTLS working with it was a serious pain and the docs for doing so were _terrible_, had to keep searching around and piecing together bits from various third party blogs. Coming from haproxy where the documentation is _so_ _much_ better and things like e.g. mTLS are vastly easier, it was not a fun experience but we did finally get traefik to work as we needed.
I wonder how you are using it. I am mainly using Traefik with docker compose labels and it was not that hard to set up once you understand the concepts of routers, middlewares and services. I would use it for any homelab that has to host more than one service.
I also recently started playing around with web UI layer that generates traefik json config. Currently it is quite basic since it was initially made to provide limited time access to development instances but it could in theory manage most important aspects of proxy config and replace something like nginx-proxy-manager. https://github.com/Janhouse/traefik-proxy-admin
I was once tasked with looking into using Traefik and yeah the documentation at the time was so bad I couldn't figure it out. Ended up using Envoy IIRC.
I use caddy similarly, but it's a pretty straight forward setup.
As a self-hosting noob, I never got traefik to work properly, then caddy just worked and has been working since.
Yeah same here. Caddy is so well designed. I hated traefik from the start and even though it works now I still hate it. The moment I used caddy everything was clear and just worked. Basically what nginx used to be 15 years earlier. But it didn't really keep up with the times and they care more about the commercial thing now.
I have the opposite opinion. Traefik documentation is good if you take the time to read and comprehend it - and it has gotten significantly better over the last few years, it being bad (e.g. "it sucks") is an old trope at this point. I don't use Caddy or nginx because of the first class routing and middleware capabilities of Traefik. I've got it deployed in dozens of services and it's so easy to use one you've solidified your boilerplate that everything else, to me, appears to be a pain now.
To each their own but it's interesting you find it useful (you use it) yet it won't be welcome back. Maybe, as others have noted, try it in Docker (or k3s/k8s/etc). Once the base configuration you want is configured and deployed all you need to do is place labels in for dynamic service configuration.
Yeah I deal with it because it's part of the ansible matrix playbook. But I hate it, I always have issues with it. Complex configs, things not quite working right.
Nginx which they used before works much better. And these days I use caddy on everything else. That really shines.
I have completely opposite experience. To me Traefik is the easiest thing to work with on the market. It should be even easier now to setup using Agentic AI.
Quite a bold claim there about being "standard" :D
At one point I was using nginx for my local RPi deployment handling of various services with docker-compose but ultimatelly switched to Caddy and it made everything so simple :)
It’s modern day age of aura farming/seo hacking/clout chasing.
Just claim you are standard and then LLM crawlers pick up on it. The next generation is trained to just ask ChatGPT/Claude/Gemini/{w/e dogshit LLM} and they will unfortunately believe it.
Throw in some more keywords and signals like GH stars, docker container downloads to sell it.
Might not work now but it’s a small gamble that may pay off in the future.
> Just claim you are standard and then LLM crawlers pick up on it
That's very interesting. Hadn't thought about this PoV. LLMs definitely /can/ empower the wrong kind of behaviour, just like SEO did... and they amplify it a lot by not really showing sources.
Thanks for sharing the thought
To be fair this predates LLMs, SEO crowd was doing this even before to try to get into Google Answers, and before that to have a favorable-looking summary under their blue link.
The entire industry is full of tricks that may or may not work, seems closer to magic rituals than anything else. It's genuinely pretty difficult to analyze how well SEO tricks perform, so there's a lot of "wow, this site is doing well, let's try to copy the success by emulating its patterns randomly" going around.
LLM rizzmaxxing is crazy
Ok, we've made the title non-standard by switching to the HTML doc title above.
There's a lot of mentions to Caddy here. Haven't used it as, back in the day, there was something funny about its license and binary distribution. AFAIK that's not a problem anymore, isn't it?
From people that migrated from Traefik to Caddy... What are the main differences? Anything you really miss?
I use Traefik in a bunch of small deployments, sometimes pointing to Docker stuff, sometimes outside of Docker, Kubernetes, or anything similar.
Caddy is dead simple. Like, send https://example.com to 1.2.3.4:5000. That’s it!
Certificate provisioning, TLS configs, TLS termination, mTLS and client certificates, sticking in middlewares, … are all simple. The config is a straightforward text file. Really good webserver!
Traefik is docker centric, and had various obscure labels. Too much text for a simple proxy. The debugging can be an issue if it doesn’t work. It also takes more resources. But it can probably do more, if you have a complex need.
My main issue with Traefik was the debugging.
Does Caddy automatically detect when you deploy a new Docker service and reconfigure itself to route traffic to that service? That's pretty much the main value preposition of Traefik for me. I don't want to be messing with config files when I'm deploying.
Yes, there's [caddy-docker-proxy](https://github.com/lucaslorentz/caddy-docker-proxy) which I personally use in my homelab. It will read and update on docker compose labels to configure the route. Highly recommend.
Caddy is a webserver like Apache or nginx. Integration with Docker is a higher-level layer. There’s caddy-docker-proxy but I haven’t tried it.
Traefik is also a web server like Apache or Nginx and it does integrate with Docker. I thought that feature was like the entire reason to use Trafik, so I guess I just find the comparison a bit strange.
Traefik maintainer here.
Traefik is a reverse proxy and load balancer that automatically discovers services and configures routing rules dynamically through integration with various configuration sources such as container orchestrators (Docker, K8s, Nomad, Consul, ECS, ...)
As of today, Traefik is not a web server.
Traefik is a proxy first
I have been building an app deployment service https://github.com/openrundev/openrun.
For the use case of network routing for services running in containers, OpenRun provides a simpler abstraction. It does the container management and the network proxying.
Yeah, don't know exactly why, but when I've had problems, debugging Traefik has been kinda frustrating.
Also, I feel like they've slowly moved focus to Docker during the years, and I find the file based configuration more and more difficult (or worse documentation maybe) every time I go back to the docs.
Thanks for sharing!
Maybe you're thinking of the drama involving Caddy putting sponsorships into its Server header. They walked that back relatively quickly and hasn't been a problem since then.
Back when they both were on the rise, they felt equivalent. I haven't deployed Traefik in a long time but as far as I remember, Traefik's configuration is more service-discovery oriented. While they both are capable of working with a static set of hosts, it felt like Traefik made it harder to configure for a static set of upstream servers while Caddy made it much easier. Traefik almost started off with the assumption that you would have some service discovery of some sort.
Traefik maintainer here.
You are right, Traefik is fundamentally built around the concept of "providers," which are external systems from which Traefik obtains routing configuration and service/server definitions.
These providers can range from dynamic service discovery systems (like Docker, Kubernetes, Consul) to static configuration sources (file-based configs, HTTP APIs, etc.). The provider architecture is what makes Traefik particularly well-suited for containerized and cloud-native environments where services are ephemeral and discovery is crucial.
Ah, I didn't remember that. I've been googling a bit and I think this was it [0]: binaries on their download page or GitHub releases were only usable on a personal basis. If you were to use them in a company, even internally, you needed to get a commercial license or build the binary yourself.
That's not the case anymore.
--
I found autoconfig in Docker (using labels) working better in Caddy+lucaslorentz.
It is still PITA (it's a nested JSON expressed as YAML) but it was easier for me than Traefik, somehow.
I guess one possible gotcha I can think of is, be prepared to build your own binaries/images if you aren't already. Some bread-and-butter features like L4 proxying depend on plugins and aren't part of the core package. It's good to self-build for other reasons, just sayin', distro versions or the official docker image will only get you so far.
Also iirc not all such functionality is actually available when configuring via Caddyfile so it can be confusing if you expect that and don't realize you need to switch to json/yaml configuration to do what you want. A little remniscient of the Traefik static/dynamic confusion ;)
All good, just things that can be different than what you are used to and expect.
So much hate for Traefik here. I don't get it. I personally use it and find it amazing, but I read elsewhere that their enterprise offering is prohibitively expensive.
I wish them to succeed, Traefik has been one of my favorite choices for Kubernetes for a long time now :)
They consider caching and TLS to be enterprise features.
If you can't get the basics right, you stay at the kids table forever.
Wdym TLS is an enterprise feature? I'm using mTLS and TLS in their OSS version. The certificates are generated via cert-manager. If you expect something like Caddy's auto-provision of certs, then (AFAIK) neither HAProxy nor NGINX have it
Traefik maintainer here.
I can confirm that bring-your-own certificates, ACME, and mTLS are all included in the OSS version. For enterprise users, Traefik Hub also provides seamless integration with HashiCorp Vault.
Regarding the cache middleware: like many of our more advanced middlewares, you have two options. You can use a community-maintained plugin (such as Souin), or your organization can purchase an enterprise license to access TraefikLabs' officially maintained built-in middleware as part of Traefik Hub API Gateway or Traefik Hub API Management.
> I can confirm that bring-your-own certificates, ACME, and mTLS are all included in the OSS version
If I open a pull request for distributed Lets Encrypt, you'd accept it?
> Regarding the cache middleware ... purchase an enterprise license
Literally what I said. Also the oddest thing to strip out to get people to pay for enterprise.
I suppose yes. That's actually what happened with distributed rate-limit.
https://doc.traefik.io/traefik-hub/api-gateway/secure/tls/le...
They actively block the use of any sort of certificate store that would allow you to run a sane setup with HA.
Congratulations on the 10 year anniversary. Having used Traefik for multiple years in a large Micro-Service Setup (200+ services) I must say I have made mixed experiences. If your requirements match the very opinionated way Traefik does things then it's great. But as soon as they don't you're going to have a hard time getting things to work. That's why shortly after migrating to Traefik I started to maintain an internal fork to add support for unique request ID headers which I maintained for two years until we migrated to HaProxy. The GitHub issue I opened for this in 2019 is still open.
To be fair I used Traefik back when it was still version 1.7 so maybe things have improved by now.
With Envoy (https://www.envoyproxy.io/) and Contour (https://projectcontour.io/) being official CNCF sanctioned projects in the Service Proxy space, Istio (https://istio.io/) and Linkerd (https://linkerd.io/) being official CNCF sanctioned projects in the Service Mesh space and Emissary Ingress (https://emissary-ingress.dev/) the same in the API Gateway space, just to name a few, naming yourself a standard are some pretty big words...
... Traefik is pretty good yes, but a standard? Hell no.
Yea, envoy is the premier open source (not open core+ paid features) proxy right now in my opinion. Modern, well supported, big community, reliable. If I was making a bet long term I would be looking at envoy and not some open core crap where they can rug pull you at any moment.
A whole bunch of the other ingress/k8s gateway offering also just…wrap envoy, so you may as well just use envoy directly these days. Especially given that configuring it, wasn’t any worse than configuring a wrapper with the additional benefit of not having anything between you and envoy to get in the way.
Is envoy usable outside containers? For example, with VMs.
I primarily use it outside containers on EC2, works exactly the same as it does in a container
Thanks! Some similar proxy projects (can't remember which ones by memory) have migrated or pivoted to be Kubernetes or containers only.
Traefik is proper OSS tho, not Open Core
Is it? Features are blocked behind a subscription: https://traefik.io/solutions/kubernetes-ingress
Honorable mention in the API Gateway space: https://gateway.envoyproxy.io/
Architecture is also different. Thread-per-core (no garbage collector) vs work-stealing with garbage collection cycles.
Amusing that they don't mention xds at all.
How did they "win" when xds, envoy's config, is becoming the defacto interface to LBs? Sure, Gateway API is kinda xds by not, but it's envoy all the way down.
I don't generally use/need Traefik. But the cheese shirt makes me unreasonably happy, and if it appeared for sale on some easily accessible site for a decent price, I'd very likely order one.
I'm not familiar with Traefik's history, but I'm French, and seeing v1.1 labelled "Camenbert" on the tshirt design is triggering me.
Apparently they wrote it correctly at the time, with an m: https://traefik.io/blog/introducing-distributed-cheese-traef...
Traefik maintainer here.
A significant portion of TraefikLabs' engineering team and maintainers are French. Before each new release, the team holds polls and spirited debates to determine which cheese would be the perfect fit for the version name.
Staying true to French culinary tradition, the enterprise versions are given wine codenames, with each wine carefully selected to pair perfectly with its corresponding cheese release.
Well hey, if you can fix the ACME key reuse issue [1], which is just a Traefik mis-use of the underlying library (by the same authors!!!), you can just get one!
[1] https://github.com/traefik/traefik/issues/10103
Standard where?
We use Kong on our projects, when not using the preferred gateway from the respective cloud vendor.
I agree “standard” is not the right word here. Traefik is very popular in self hosting community, probably the most popular proxy in my experience, followed by NPM (nginx proxy manager) and Caddy as distant third.
Is there a way to use Envoy with common self-hosting software stacks like Docker Swarm?
isn't that just a way of running containers? yeah you can run envoy
Isn’t Docker Swarm dead?
Docker swarm v1 is dead, v2 ("swarmkit") is usable. Although, if you want to use it in production, you're probably better of with K8s. Don't get me started on docker using "the same" (but subtly different) file format for its different offerings (compose v2, swarm v2). For smaller setups maybe look into podman with K8s config files (did not try myself yet).
I never understood why folks use Traefik. HAProxy feels more configurable and resilient.
Low resource footprint, written in Go, embed-able in any Go project as a library, compiles to mobile with little to no modification, supports config change without restart, has plugin API.
These were the reasons why we used it in my previous job.
Integrates with Docker Compose with the its Docker config provider so I can configure Traefik for my services through Docker labels, not in the central Traefik instance
HAProxy's documentation is pretty bad (almost entirely of the style "here are all the parameters and options available, no concrete complete examples)".
Traefik has easy to parse docs with lots of examples, and mostly, it can autoconfigure itself based on a variety of sources. You can point it to your Kubernetes or Nomad or Consul, (and with small bits of info given when deploying your workloads to those places), and it just works.
Yeah, this is absolutely true. It can be configured to do anything, which means you really need to make sure you've configured everything correctly.
Because Traefik is lightweight and if you know Go, it can be even easier to get going as you can browse the source code and figure things out.
HAproxy on the other hand is the big daddy of proxies. The pinnacle of high performance. There are few use cases where this makes sense. Definitely nothing for development environments.
I use it because it's built in to k3s.
Easy to configure, straightforward and intuitive. Clear and detailed documentation. Recently, I wanted to try HAProxy, but I gave up because I got lost in the config, and I don't trust AI agents to do things I don't understand.
Easy to configure.
We use Kong, and while it is quite powerful, oh boy better get some coffee when doing those rules.
[dead]
Congrats, awesome product! Traefik saved me a lot of time when working with Docker Compose and certificates.
I use and appreciate both Traefik and Caddy. I like that Traefik includes TLS termination, whereas the equivalent functionality with Caddy requires compiling a separate module with xcaddy.
I'm pretty sure that's how I'm already using Caddy, and I didn't compile anything separate. Maybe it's packaged automatically as part of the Caddy Docker image?
My original comment probably wasn't clear enough, I meant to say that caddy doesn't support layer 4 TLS termination without third-party modules. For example, if I wanted a reverse proxy in front of a Gitea instance that would terminate and route TCP packets to/from port 22... this is something Traefik can do out of the box.
We plan to move layer4 into the standard Caddy distribution eventually. We're still stabilizing it, and once we're happy with it (and have the time and energy to) we'll bring it in.
Exciting! Looking forward to it. I end up needing xcaddy for a few other modules so it's not that big of a deal, but I always feel better using first-party functionality over relying on third-party modules.
There's even a great docker with caddy and the cloudflare DNS-01 module built in which was just what I needed. That saved me having to deal with xcaddy (it was ok, but compiling was slow)
That would be amazing, just yesterday I did build caddy with L4 plugin
Horrible read. That whole post is nothing but gratuitous self-importance. Just don't use llms for something like this... it just gets over the top really easy.
I host a couple of web services like Nextcloud and Overleaf instances (Docker) and I use nginx as a reverse proxy. What would be the benefit of using Traefik instead? Traefik can handle things such as TLS certificates automatically, but that seems a rather weak reason to move away from a robust and modular setup where each component complies with the Unix philosophy or doing one thing well.
I use nginx as Gateway (Reverse Proxy) and have several VMs with services deployed using Docker Stack. Traefik acts as reverse proxy on the VMs. Main benefit IMHO: configuring services/routing using docker labes and because they run in dedicated networks, no need to expose any port (Internet -> Nginx -> Traefik -[> Service ] ; wheras [ ] indicates a docker overlay network.
Yeah, I don't use Traefik I use Caddy with https://github.com/lucaslorentz/caddy-docker-proxy to achieve configurations by labels, but that is really a killer feature. All the config to set up an app can go in a docker-compose file and I just have one point of configuration for it. Editing or deleting it doesn't involve editing configurations in 3-4 places.
Used Traefik a couple times in my homelab, would’ve been circa 2017/2018. Worked great when it worked, otherwise it tended toward breaking ungracefully and confusingly. Tried it again for a short time in 2022, rock solid, no complaints. I’m glad to see the project’s maturity has kept up! Congratulations on ten years!
I use traefik in my home network as the main reverse proxy.
I don't use any of the dynamic features though like labels in docker containers etc, all of it is configured using the static configuration. It's been working well but I don't think about it really.
I just wanted to sincerely say: congratulations for this project.
When a person is determined it can go very far. These things do not happen just by pure chance.
Congrats on a decade! Time flies. I think I first heard about Traefik from a GopherCon talk, and it quickly became a default for me when working with Kubernetes.
Still not entirely sure how to pronounce the name though...
Anyone know of a Traefik alternative but in Rust? I'm looking to oxidize a lot of my stack so just curious.
Looking for a Rust-based alternative to a battle-tested industry-standard tool written in a memory-safe language that can get about 75-90% of the speed of Rust is kind of pointless outside embedded context.
Not really, sometimes it's just a curiosity. And 15% is nothing to scoff at in terms of speed, if it's available why not take the extra speed, is my opinion.
While there is pingora https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t..., I would recommend checking out envoy. Although not rust based, envoy has gained quite the repute for being extremely versatile and robust.
There's a handful but not mature IMO: https://github.com/sadoyan/aralez https://github.com/junkurihara/rust-rpxy
I'm interested in the space, but until they have automatic certificate management and middleware for managing DNS records in Cloudflare (for example), then I'm reluctant to switch over.
Thanks, I'm looking specifically for a Rust based one, as I know there are lots of proxies in other languages but few in Rust, and I'm just curious if anyone has suggestions on that.
No, use Traefik. I like Rust a lot and many new tools written on it, but nothing beats Traefik currently, and there’s no need, tbh.
the closest thing is pingora which is a proxy framework, so you build your own proxy basically
When I wanted to move to something besides NGINX proxy manager, it was caddy or traefik. At the time, tutorials for the clueless like myself were way more abundant for Traefik. Thats the way I went. Now I also have Authentik up in front and it works great.
I am actually playing around with something similar to nginx proxy manager but for Traefik. It's quite early version but already now it's nice for quickly sharing some services with people temporarily. https://github.com/Janhouse/traefik-proxy-admin I personally use it in homelab together with docker label based configuration. Adding headscale in the mix allows easily serving my development services with outside world.
Sigh. Congrats and all that, but this just makes me feel old.
Letsencrypt Https should be a default like caddy.
Mounting certs, opening right ports and mapping them right is really not what I want to mess around with just to get SSL.
I use traefik quite a bit. Easy to use, easy to understand. Optional dashboard for understanding the current state of the configuration.
funny and sad how ingress-nginx loses all users by going into maintenance mode, and once we switched we dont care about their new project
Managed Nginx is standard for AKS. I wouldn’t say it’s gone.
Has ingress-nginx lost all users? We are still rocking here at work because I see Gateway API in Kubernetes and go "Ingress works, don't care"
It hasn't, Gateway is still in development with most features being experimental.
Traefik's F/OSS projects are useless to me. Every single feature that I need to use is locked away in a closed source product.
Close to the same issue with Varnish Enterprise. Why would I pay for Varnish Enterprise if I can't even review or extend the source? Know what I have to do with Varnish's source once a quarter? I have to look at it. Because the documentation is non-existent. The closed source version is going to make my life objectively worse.
Aside from NGINX, Postgres, and memcached, I've had to patch every major piece of software in my stack at one point or another. I refuse to use any product that I can't fix myself.
It's current year, why are JWTs only supported in the closed source/enterprise versions of Varnish, NGINX, and Traefik?
I happily give $1,000/year to Django and lesser amounts to other projects that I depend on. Do you know how much I spend on projects that put features behind a closed source product? Zero. I will never pay for that.
I don’t think this is representative of the majority of traefik’s users. Most of us use it as an HTTP entrypoint for a container stack (docker compose, in my case) or for local development, and the FOSS version works great for that, with better dev tooling than anything else i’ve seen.
I disagree. If you're a heavy Traefik user you're eventually going to need a feature that has been carefully omitted from the F/OSS projects.
> I disagree. If you're a heavy Traefik user you're eventually going to need a feature that has been carefully omitted from the F/OSS projects.
Ok, I use it at home as part of my K8s cluster. I haven't once come close to needing a feature I don't have because it largely does what I need as a proxy and gets out of the way.
What features do you feel a more average of the target audience is likely to need or want to pay for eventually?
> What features do you feel a more average of the target audience
Auth and middleware packages that are essential for a production site.
> I use it at home as part of my K8s cluster.
That's not heavy use.
Running it in production for free and complaining about the offering is a choice.
They are not complaining about the price, but about the closed source nature of the product.
I'm not running Traefik in production. The features that I need are all closed source so I moved on.
Sure, it's a choice but I think it's more that don't pretend you are open source when your carefully hide things behind closed sourced paid licenses. Be like Microsoft, we have eval version but if you want to use our Windows Server, you will be paying up. Cool, I can make a decision about your software with that in mind.
A choice is a far cry from the "standard" the title purports.
Do they not provide source under commercial license to enterprise users? It makes sense to not use in production if you need source to make sense of features.
By contrast, Kong Enterprise gave us source access to commercial offering plugins we needed. Not to all things but the things we needed yes.
> If you're a heavy Traefik user...
...shouldn't you be paying then? Expecting developers to work for free to provide you with a product you use heavily is acting pretty entitled.
Just to give a contrasting account, I have been using Traefik to manage my public server (a $4 Digital Ocean VPS running a web server and a Bluesky PDS) and my local home server (running dozens of services with all kinds of weird configurations) flawlessly for more than 5 years now.
No. That is emphatically NOT entitled -- if the Traefik people have made heavy use of "open source," either practically or in marketing.
If you tout "open source" ideas in the work you do, then you can reasonably be held to the social contract that the ideas of open source originate in.
Lately (by lately I mean maybe the last 20 years or so) there's the idea of "because the open source ish company needs to pay the bills, they can completely abandon the ideas of open source."
Nah. You took from the commons, the commons has at least SOME right to ask for something back.
I never became a heavy user. All of the features that I needed were closed source so I moved on.
> If you're a heavy Traefik user you're eventually going to need a feature that has been carefully omitted from the F/OSS projects
That's literally the point of open core software. It's free and open source at the core, but "enterprise" / "scale" features are behind a license.
Enterprises/Scaled users that can pay, have to, to get the features they need. Everyone else can enjoy and profit off fully free and open source piece of software.
Win-Win-Win.
It's probably the only software business model that allows for a company to actually make money while also giving out most of their products for free as open source. Just selling support/services does not work and does not scale. Cf. literally everyone, the only orgs that somewhat pull it off are foundations/volunteer based projects like Django, Debian, etc but they are not commercial for-profit entities (there is nothing wrong with that, but most people want to be paid well). And your $1k/year, while decent towards a volunteer organisation, would be probably worse than nothing for a commercial company that has costs associated with each contract (legal, administrative, support, etc). For a fun story on the topic, check out HashiCorp's first commercial deal with Apple for a Vagrant plugin, that resulted in HashiCorp losing money on the deal due to the amount of money spent on lawyers reviewing Apple's terms and time spent supporting them afterwards. The only existing somewhat exception is Red Hat, but even they have moved more and more into open core with Ansible Automation Platform and OpenShift, which are their money makers, and have scrapped CentOS as a RHEL compatible free OS.
Same. At this point I've spent more time in devops moving away from shit that does this, and then doing it again, just to keep things as they are in a way that can be trusted. It fuckin sucks
I’ve deployed Traefik in-front of Kubernetes on some moderately large traffic sites with and without enterprise licensing. Recently I switched to using Caddy though. I know the stigma is that Caddy is not “production” ready and battle tested but I haven’t encountered any issues with it in terms of performance. It just works. Let’s Encrypt with CloudFlare DNS verification is super easy to setup and the configuration is very intuitive.
> It's current year, why are JWTs only supported in the closed source/enterprise versions of Varnish, NGINX, and Traefik?
I've found auth at the proxy to be a major antipattern. It adds a semblance of your backend being secure without adding the real user authentication and authorization it should have directly.
VPN is the better tool if you want to keep certain projects hidden from the general public and your application should be handling the JWT (hopefully in current year we're talking OIDC or some additional open standard on top of JWT) itself in order to properly enforce access controls.
With JWTs I don't do anything at the proxy beyond "This is a protected route. Is there a JWT? Is it valid? No to either? 403." This is one of the primary use cases for JWTs and it takes a majority of the load off of my application servers.
The route is open to the public for authenticated and authorized users. You wouldn't use a VPN here.
That's really just added work, IMO, and likely room for security misconfiguration between backend and proxy. You should still be validating and everything on the application server to inspect identity and possibly attributes like roles, so in the cases where you have invalid tokens you do the work once, just in the proxy instead of the backend, and with valid tokens you will do the signature validation work twice.
Security starts at the edge.
Have you used JWTs in production? Better to bounce a bad JWT with a server written in C/C++/Rust/Go at the edge than to pass it back and have it tie up a Python or Node process.
Even in Python the time to validate a small JWT is negligible. At the edge it's nearly imperceptible.
If you're concerned about misconfigurations, just verify/validate everything in tests.
Caddy my guy, caddy.
Traefik is really only useful in k8s. Soon we’ll be replacing ours.
[dead]
[dead]
They have to put bread on the table somehow.
If I had access to the code I would pay for it. Create a private repo for paying customers.
The problem is that you would be one of the 1% doing that, the rest of the companies would just not bother with that and it will end like many open source problems that constantly have to come up with ways to get funding.
Was just taking a break from reading Traefik documentation - thank you for this amazing project.
[dead]
[dead]
[dead]
Usual tribal bollocks in the comments.
Personally, I generally rock Apache but Traefik, Caddy, ngnix and co are all superb projects.
If you are going to get tribal about web servers, I suggest you think really hard about your career choice.
Use the tool that works for the job in hand.
My main takeaway was "traefik has worse docs and more complex configuration but if you grok it, the fit with docker is fantastic"
The first this I ever do when setting up k3s is pass --disable-traefik I don't know what it is, I never used it, never had the motivation to look into what I am losing out because everything else I am familiar with already works and I don't have many complains. I do not remember why I have this opinion, but I usually only treat software like this when they're trying to sell themselves too hard.
Traefik is used by k3s for ingress.