[HN Gopher] Traefik's 10-year anniversary
___________________________________________________________________
Traefik's 10-year anniversary
Author : beckford
Score : 174 points
Date : 2025-09-24 08:29 UTC (2 days ago)
(HTM) web link (traefik.io)
(TXT) w3m dump (traefik.io)
| miiiiiike wrote:
| 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.
| zukzuk wrote:
| 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.
| miiiiiike wrote:
| 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.
| btreecat wrote:
| > 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?
| miiiiiike wrote:
| > 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.
| nickstinemates wrote:
| Running it in production for free and complaining about
| the offering is a choice.
| fisf wrote:
| They are not complaining about the price, but about the
| closed source nature of the product.
| miiiiiike wrote:
| I'm not running Traefik in production. The features that
| I need are all closed source so I moved on.
| bigyabai wrote:
| A choice is a far cry from the "standard" the title
| purports.
| stackskipton wrote:
| 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.
| HexDecOctBin wrote:
| > 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.
| miiiiiike wrote:
| I never became a heavy user. All of the features that I
| needed were closed source so I moved on.
| jrm4 wrote:
| 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.
| sofixa wrote:
| > 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.
| renewiltord wrote:
| 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.
| reactordev wrote:
| Caddy my guy, caddy.
|
| Traefik is really only useful in k8s. Soon we'll be replacing
| ours.
| andrewstuart2 wrote:
| > 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.
| miiiiiike wrote:
| 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.
| andrewstuart2 wrote:
| 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.
| miiiiiike wrote:
| 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.
| miiiiiike wrote:
| If you're concerned about misconfigurations, just
| verify/validate everything in tests.
| pjmlp wrote:
| They have to put bread on the table somehow.
| miiiiiike wrote:
| If I had access to the code I would pay for it. Create a
| private repo for paying customers.
| dewey wrote:
| 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.
| monster_truck wrote:
| 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
| nodesocket wrote:
| 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.
| mhogers wrote:
| Was just taking a break from reading Traefik documentation -
| thank you for this amazing project.
| hoistbypetard wrote:
| 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.
| AceJohnny2 wrote:
| 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
| BoredPositron wrote:
| 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.
| arrty88 wrote:
| I never understood why folks use Traefik. HAProxy feels more
| configurable and resilient.
| mirzap wrote:
| 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.
| doctoboggan wrote:
| I use it because it's built in to k3s.
| pjmlp wrote:
| Easy to configure.
|
| We use Kong, and while it is quite powerful, oh boy better get
| some coffee when doing those rules.
| sofixa wrote:
| 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.
| maherbeg wrote:
| 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.
| diegoperini wrote:
| 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.
| gethly wrote:
| 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.
| AceJohnny2 wrote:
| 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
| satvikpendem wrote:
| Anyone know of a Traefik alternative but in Rust? I'm looking to
| oxidize a lot of my stack so just curious.
| nokun7 wrote:
| 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.
| satvikpendem wrote:
| 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.
| rirze wrote:
| 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.
| vovavili wrote:
| 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.
| satvikpendem wrote:
| 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.
| LtdJorge wrote:
| 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.
| mindcrash wrote:
| 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.
| __turbobrew__ wrote:
| 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.
| LtdJorge wrote:
| Traefik is proper OSS tho, not Open Core
| aranelsurion wrote:
| Honorable mention in the API Gateway space:
| https://gateway.envoyproxy.io/
| denysvitali wrote:
| 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 :)
| laz wrote:
| 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.
| germandiago wrote:
| 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.
| ktosobcy wrote:
| 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 :)
| xyst wrote:
| 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.
| aprdm wrote:
| > 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
| dang wrote:
| Ok, we've made the title non-standard by switching to the HTML
| doc title above.
| pjmlp wrote:
| Standard where?
|
| We use Kong on our projects, when not using the preferred gateway
| from the respective cloud vendor.
| mynegation wrote:
| 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.
| coredog64 wrote:
| Is there a way to use Envoy with common self-hosting software
| stacks like Docker Swarm?
| LtdJorge wrote:
| Isn't Docker Swarm dead?
| gethly wrote:
| 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.
| skibbityboop wrote:
| 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.
| tracker1 wrote:
| I use caddy similarly, but it's a pretty straight forward
| setup.
| theSuda wrote:
| As a self-hosting noob, I never got traefik to work properly,
| then caddy just worked and has been working since.
| trenchpilgrim wrote:
| 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.
| Jnr wrote:
| 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
| eurekin wrote:
| 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.
| frogperson wrote:
| 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.
| LtdJorge wrote:
| 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.
| brainzap wrote:
| 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
| stackskipton wrote:
| 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"
| firesteelrain wrote:
| Managed Nginx is standard for AKS. I wouldn't say it's gone.
| kachapopopow wrote:
| 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.
| cmckn wrote:
| Traefik is used by k3s for ingress.
| kardianos wrote:
| I use traefik quite a bit. Easy to use, easy to understand.
| Optional dashboard for understanding the current state of the
| configuration.
| tecleandor wrote:
| 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.
| justsomehnguy wrote:
| 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.
| aborsy wrote:
| 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.
| Ajedi32 wrote:
| 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.
| sph wrote:
| 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.
| Ajedi32 wrote:
| 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.
| LtdJorge wrote:
| Traefik is a proxy first
| rirze wrote:
| 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.
| tecleandor wrote:
| 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!
| therein wrote:
| 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.
| Vaslo wrote:
| 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.
| Jnr wrote:
| 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.
| IOZ wrote:
| Congrats, awesome product! Traefik saved me a lot of time when
| working with Docker Compose and certificates.
| ctippett wrote:
| 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.
| mpyne wrote:
| 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?
| drnick1 wrote:
| 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.
| chrisandchris wrote:
| 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.
| gh02t wrote:
| 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.
| jprd wrote:
| Sigh. Congrats and all that, but this just makes me feel old.
| evnix wrote:
| 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.
___________________________________________________________________
(page generated 2025-09-26 23:00 UTC)