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.
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.
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 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
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 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 in the end.
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.
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.
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.
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.
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 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.
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!
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 :)
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
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.
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.
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.
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 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.
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'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.
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.
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.
...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.
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 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.
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.
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 :)
Ok, we've made the title non-standard by switching to the HTML doc title above.
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
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.
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 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
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 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 in the end.
I use caddy similarly, but it's a pretty straight forward setup.
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.
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!
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 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.
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.
Honorable mention in the API Gateway space: https://gateway.envoyproxy.io/
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 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.
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
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 :)
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
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 it because it's built in to k3s.
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.
We use Kong, and while it is quite powerful, oh boy better get some coffee when doing those rules.
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.
[dead]
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.
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?
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.
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.
Anyone know of a Traefik alternative but in Rust? I'm looking to oxidize a lot of my stack so just curious.
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.
I use traefik quite a bit. Easy to use, easy to understand. Optional dashboard for understanding the current state of the configuration.
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.
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
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"
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.
> 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.
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.
I'm not running Traefik in production. The features that I need are all closed source so I moved on.
A choice is a far cry from the "standard" the title purports.
> 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.
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 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
Caddy my guy, caddy.
Traefik is really only useful in k8s. Soon we’ll be replacing ours.
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.
[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]