Take a look at Traefik, even if you don't use containers (opens in new tab)

> Technical writers: documentation by example is good only for newbies skimming through. People familiar with your product need a reference and exhaustive lists, not explanation for different fields spread over 10 tutorial pages. Focus on those that use the product day in and day out, not solely on the "onboarding" procedure.

I agree. We all would benefit by giving more exposure to documentation frameworks such as https://diataxis.fr

My latest gripe in this category - opentelemetry. Thousands of pages. Very little about actually achieving basic common workflows.

One of the problems that the yaml interpreter class of languages, or whatever you'd call them, suffer from is the fact that yaml itself is a language and tends to be more or less undocumented in the interpreter docs.

It's sort of assumed that you are going to do extremely simple tasks on very flat data structures. That doesn't tend to be the reality that most of us live in. And to really get the most out of these languages you have to understand an entire unspoken set of rules on how to use yaml. That's never really pointed out in the docs.

Additionally, there are docs for the unique settings for each module but as far as using the standard settings, additionally, its rarely clear how to operate on the data that might be returned or combined with anything mildly complex, you are given a dozen 1 stanza examples for each item like a stack of ingredients and then told to bake a cake.

I've had this experience with basically every one of the various yaml interpreter systems I've used.

After a few 100k lines of yaml I can get things done but the docs are useless other than a listing of settings.

Ansible is definitely requiring constant lookup in the documentation.

I've found a pretty good workflow with using ansible-doc though, with two-three aliases that I use constantly:

    alias adl='ansible-doc --list'
    alias adls='ansible-doc --list | less -S'
    alias ad='ansible-doc'

Then I'll:

1. Use adls to quickly search (in less with vim bindings) for relevant commands,

2. Check up the docs with `ad <command>`.

3. Almost always immediately jump to the end (`G`) to see the examples, which typically provides a direct answer to what I need.

Since authoring Ansible scripts is so dependent on the docs, I think they really should make this process work better out of the box though, providing some interface to do these lookups quicker without a lot of custom aliases.

Pydantic falls into this box for me. The maintainer refuses to build API reference documentation, as they feel that there should only be one source of information. It's their project, of course, but every time I need to find a method on an object, I am scouring pages of prose for it. Sometimes it's just easier to read the source.

Funny you say that because we don’t have nearly any examples in the Caddy docs. We’re working on improving them later this year.

This is strange. I also don't like the docs but for a different reason.

I would rather have a more examples. And kinda _advanced_ and complex, rather than trivial we see in the docs.

Even though I had a working V1 configs and had a know-how about lingo / architecture like routes / services I still struggled for a day or two to properly configure a pretty simple workflows in v2 like:

* add TLS with LetsEncrypt

* configure multiple domains

* configure multiple services

* add Basic Auth for some domains

That said, more detailed and extensive docs would be much better.

I also remember finding things in github issue comments that worked as bugfix/workaround of something from the docs.

PS. For now I've moved to Caddy for simplicity and better Caddy DSL compared to yaml/label verbose config.

Do not agree WRT ansible, been using it for well over 5 years and usually a google search points me right at the correct part of the documentation to answer my question. Ansible, the tool itself, can be a bit obtuse, largely IMHO because of the YAML source language, so some concepts are hard to translate into the tool, but the documentation has never bothered me.

As far as "a lot of words written, can't find what you need", Fortinet is my poster child there (based on trying to use it a decade ago). Everything I looked up there had 10,20,30 pages of introductory material with the Fortinet stuff spread throughout it.

Possibly unpopular opinions to follow. This is made even worse by:

- Having documentation split between v1 and v2, that is similar yet different enough to yield half-baked configurations before you realize what you did wrong. The website itself provides the barest of subtle changes to distinguish the two. Edit: I learned all this prior to v3.

- Supporting multiple config formats (TOML and YAML) which makes it that much harder to hunt down relevant forum posts for support. That wouldn't be a huge problem if it weren't for things that you need that aren't in the documentation (above)

- Multiple configuration _modes_. You can set options on the CLI, or in config files, and they are not 100% reflected between the two; some things must be in config files no matter what. Config files themselves are split between "dynamic" and "static" configs, and you must place the correct options in the right file.

- The one thing that Traefik does well is routing traffic to/from containers. Container labels are used to drive this. How to map those label namespaces to various internal and user provided aspects of Traefik is unclear in the docs, at best.

- Traefik exposes a dashboard web GUI by default. Yet much of the useful diagnostic and troubleshooting information is only found in the container logs.

Retiring v1 completely, picking a single configuration language/mode, and providing a rich library of example docker-compose configs, would go a very long way to securing this project's future.

> Technical writers: documentation by example is good only for newbies skimming through. People familiar with your product need a reference and exhaustive lists, not explanation for different fields spread over 10 tutorial pages. Focus on those that use the product day in and day out, not solely on the "onboarding" procedure.

You really need at least three documentation targets:

- onboarding the newbies workflows/tutorials - intermediate "focus on the important bits" workflows/tutorials - exhaustive references

There might be other useful ones as well, but I never see those three hit at the same time adequately.

This was exactly my experience. It’s incredibly frustrating to search documentation only to be stuck with examples that are related, but don’t fit one’s exact situation, and don’t explain the underlying behavior.

Those are great points. Even the page layout of the documentation is terrible. Whywe have huge monitors and millions of pixels if I have to read content from a very narrow column, which is a mile long?

Eg: https://doc.traefik.io/traefik/routing/services/

If you visit that page in your desktop browser you'll get less words per column then seeing this on the iPad (works even in dev tools window). Mind blowing.

> Technical writers: documentation by example is good only for newbies skimming through. People familiar with your product need a reference and exhaustive lists, not explanation for different fields spread over 10 tutorial pages.

Well said, this extends far beyond Traefik. Far too much documentation these days is tailored for people who have never used software of it's type. This was a workable strategy during the Great Developer Boom, but that's more or less over now.

As a developer who didn't come from this Boom, I have been constantly frustrated by this trope, and I hope the changes in the industry will tip the scales back toward solid reference documentation, so that I can feel confident in deploying more of these technologies.

Putting that more general note aside, I have been a Traefik user for years and I do recommend it. But a lot of what it does is difficult to cite using solid docs.

I'm using the Traefik and have the same experience with the documentation. It can be time consuming to configure it properly if you are not a power user.

I'm happy with it though, it's a great piece of software. I wonder is there any other product out there with a similar feature set?

It's funny because one thing I like about ansible is how easy it is to get the reference doc for any module with `ansible-doc -t module`.

I do sometimes struggle to find the right doc when I'm searching for something about ansible core itself, but that doesn't happen too often.

I share the same sentiments. I dread having to go through Ansible docs because it's so densely packed. Meanwhile Caddy's docs feel too sparse, and too many spread out tutorials. The reference isn't well thought out either imo.

I want both, in the same page if possible, for every possible permutation of input arguments. In theory ansible does this, but then it doesn't link to "you might use it in combination with...", essentially, it lacks integration of multiple things in the reference docs. but I didn't find ansible docs that bad? Most of the time I search module name and find the reference doc

same reason why Terraform AWS Provider is better documentation than AWS documentation

https://registry.terraform.io/providers/hashicorp/aws/latest...

If I can't find the answer to what I need there I usually resort to LLMs, they are surprisingly good and fetching the info you need out of these massive documentations. The failure rate is quite high though so a lot of trial and error required, but the LLM at least gives you some hints to where to look for it.

You're assuming that Traefik has a team of technical writers taking care of the docs. From what I know, that's not the case.

From this point of view the Oracle RDBMS handbooks ca. 1998 were pretty good. Come to think of it, they were pretty good all around.

I don't think ansible docs are that bad.

I use duckduckgo and adding !ansible to my search usually gets me what I need pretty directly.

Some projects need documentation, some need cookbooks. Sounds like traefik is the latter.

Hopefully as an aside (I know very little about traefik so maybe I am talking about them too and don’t know it), it seems like in the time since I abandoned Java they have weaponized that architectural strategy and I have no patience for it. I look at that sort of documentation and my eyes glaze over. Or if they don’t I feel disgust or anger and all three result in my stomping off.

Opentelemetry, particularly the stats code (vs the span code) triggered a lot of this in me. It has several sets of documentation that say different things. It took me a long time to figure out how to connect the amorphous dots, and then I didn’t entirely agree with their solution anyway.

I agree that the documentation could be better, but it isn't that bad. I enjoyed all the gophers, and these images really helped me understand the structure.

However, I find it amusing that you wish there was a better reference. I think getting to the initial setup is quite hard. Once you have that, extending it is straightforward.

Oh man are you on to something!!! One huge, bad side effect of web is the atomization of an overall body of work into 62.9 million links.

One pdf please. The book concept works!

You know who's docs blow too? Mellanox. I hate their stuff.

And to give credit where due: intel does a damn good job.

Just another one for collection: conda. Especially the parts about conda-build, meta.yaml etc. There are only examples w/o any way to tell what's available. And the source code is frustratingly twisted, undocumented and all over the place. Something that makes creating conda packages an extremely frustrating experience, to the point that it's significantly easier to create archives and write the metadata by hand than to rely on conda tooling.

If only there were a program that had crawled bazillions of documents, including all of the traefik documentation, examples, and thousands of code files using it, and if only said program were especially designed to answer natural-language queries about said documents.

This take is, at best, disingenuous, and at worst, dangerous. The Traefik maintainers and community contributors (including myself) have collectively invested hundreds of man-hours writing and improving documentation, specifically in response to feedback from users that things are hard, unintuitive, or complex.

You are discounting massive amounts of unpaid labor done specifically for people like you. At this point, if you can't find what you're looking for, it's on you. Maybe do a little bit of your own homework instead of throwing your hands up after 2 minutes and crying to the maintainers.

I usually feed all the documentation to an llm and ask the question to the llm that fetches the info with rag. For example:

> how do i configure Traefik to proxy traffic to two backend services?

Configuring Traefik to proxy traffic to multiple backend services is a common use case. You can achieve this by defining multiple entry points and routers in Traefik's configuration, each pointing to a different backend service. Here's a basic example of how you can configure Traefik to proxy traffic to two backend services:

  yaml
  
  # traefik.yaml
  
  # Enable API and Dashboard
  api:
    dashboard: true
  
  # Define entry points
  entryPoints:
    web:
      address: ":80"
    app1:
      address: ":8081"
    app2:
      address: ":8082"

[...more stuff...]

This is one area where I've found nixos to be really helpful. I can set this up with just adding some lines to the configuration.nix (which uses lego(1) and letsencrypt in the backend):

  security.acme = {
    acceptTerms = true;
    defaults.email = "admin-email@provider.net";
    certs."mydomain.example.com" = {
      domain = "*.mydomain.example.com";
      dnsProvider = "cloudflare";
      environmentFile = "/path/to/cloudflare/password";
    };
  };
  
  services.caddy.enable = true;
  
  services.caddy.virtualHosts."subdomain1.mydomain.example.com" = {
    extraConfig = ''
      reverse_proxy 127.0.0.1:1234
    '';
    useACMEHost = "mydomain.example.com";
  };

Configuring with nginx is also fairly similar I think.

1. https://github.com/go-acme/lego

I have moved to Traefik from NGINX aswell because of the built-in support for DNS challenge and wildcard cert. I myself spent many hours trying to get it working for my domain I use at work. I used the same config I use at home (which works perfectly) but could never get it to actually do anything, even though the setup was identical. Same domain registrar with same API based on the same docker configs etc. Had all logs enabled and still I get no information what so ever about why my certificate could not be created. It simply defaulted back to its generated cert without trying it seemed. After two troubleshooting sessions and several hours of searching and troubleshooting I had to admit defeat and just use my own self-signed cert files. Very frustrating when you get no information about why it doesn't work. Just a silent failure and fallback.

Overall that has been my biggest problem with traefik. Its awesome when it works, but when it does not I always seem to have problems troubleshooting and/or finding the information I need in the docs.

At work we will start using Traefik in prod towards the end of the year. I hope Traefik and I will become better friends before that :)

I’ve always just used go’s built in reverse proxy if I need an API gateway. You can adapt it to meet any specific need, easily find libraries to do common tasks (CORS, rate limiting, retries, etc), and the best part: no configuration language. You just write go.

> I decided to migrate to Traefik mainly because of the automatic let's encrypt integration.

You probably already know and maybe it didn't work for you, but there's quite a few Docker companion containers that automate let's encrypt certs for an nginx Docker container.

I had much of the same issues early on in my Traefik experience. Things like using TLS-01 validation but not having DNS records set before config was applied would cause a lot of frustration. Like you, I was frustrated with the amount of logging I was getting. I eventually learned that not having DNS configured appropriately would lead validation attempts to fail after N unsuccessful attempts, and LE would refuse to do another TLS-01 validation for a while, which sounds like the kind of issue you were having.

After moving to DNS-01 validation, which comes with the added benefit of letting me cut certs for services that aren't publicly exposed with way less orchestration required than with TLS-01 style validation, my experience was suddenly much better. Assuming the DNS provider is working (and if it's not, you're hopefully getting an API error from them before LE attempts to validate the record, the failure state happens well before any check failure backoffs happen at LE. At this point, regardless of whether I'm using Traefik, Caddy, Nginx, or any other reverse proxy, I'm pretty committed to only using DNS-01 based validation from LetsEncrypt from now on, or if I have to do TLS-01 based validation, to make darn sure things are right the first time with the Staging API first.

Which, speaking of, if you cut a Staging cert with LE via Traefik, there's no good way to invalidate the staging cert. You have to munge the ACME JSON to remove the cert and restart Traefik (could maybe do a SIGHUP? didn't try) to get it to pickup the changes.

All said, lots of weird silent failures and behaviors, but the biggest pains are making dependent service errors opaque.

I use NGINX and Traefik in prod at work, and for my personal stuff I only use NGINX. It's all just orchestrated containers, no ingress controllers or similar magic anywhere.

I agree with your comments about Traefik being finicky, and would like to add that my very basic inhouse solution to do automatic Let's Encrypt integration (that also works with other ACME compatible CAs) is ~30 lines of bash, which is ran by cron every day. It's rock solid simply by failing hard when standard return codes fail. Monitoring for failed certificate renewals is as easy as handshaking with the endpoint and parsing the NotAfter field in the OpenSSL output. I run this as part of my regular HTTP endpoint monitoring solution at it tells me if any certificate will expire within 14 days.

The absolute worst failures I've experienced is having new domains start with a self-signed certificate until I reloaded nginx manually, and that I had 2 weeks to jump in and sort out some error because a certificate renewal failed.

So at least in my experience it turns out that LE-integration isn't a strong selling point. Logging and ease of configuration is. NGINX is not perfect in those aspects either, but it is a bit more robust and well-documented at least.

You might be happy to know that integration between Let's Encrypt and Nginx is something that's been provided by Certbot for years. The Nginx plugin for Certbot will identify active domains from your Nginx config, create and renew certificates, automating domain validation through the web server in real-time, and will automatically update your config files with both certificate paths and HTTP redirects to HTTPS (if desired).

I've considered Traefik for that too. We had 1800+ domains, so automatic TLS would be useful. But the OSS version didn't have good options for certificate storage imo.

Ended up using nginx and adding a .well-know/certbot endpoint orso that used lua to call certbot. Some bash, rsync & nfs for config management, never had an issue with it. Not fully automated, but close enough. And very debuggable!

We’ve been using Nginx is prod for 3 years. While I used Traefik in the past, I decided to migrate to Nginx mainly because of its scriptability (Traefik plugins suck). I am sorry for that decision. Nginx’s documentation is absolute trash full of non-explanations (far worse than Traefik or Caddy. It’s finicky and misbehaves constantly. Lurking around every corner is a decision from 1995 sticking around in 2024; Nginx can barely function on the modern internet without _significant_ tuning.

On top of it, the OpenResty community must be the rudest, most entitled people in the entire internet. Have a question, “YOURE DOING IT WRONG IDIOT” is the response. Of course every terrible decision they’ve made they justify with “BUT THE PERFORMANCE” as that’s the only thing worth considering.

We’re moving back to Traefik, or Caddy, both still in POC.

I moved from Traefik to Caddy with caddy-docker-proxy for my self-hosting setup.

All the features I need but *much* simpler.

https://github.com/lucaslorentz/caddy-docker-proxy

I love Caddy, I wish the docs were better on production deployments, too many unanswered questions about best practices especially RE: storage and config management. Like how local storage is supposed to be handled when you're using external storage? Allegedly it can be treated as stateless but maybe not?

You basically just have to pray the guy who made the module you need knows what he is doing, because there's no standards for documentation there either. Maintainers really need to put their foot down on random ass modules with 0 documentation providing critical functionality (i.e. S3 storage backend).

Yes. If you don't need all of the service discovery and auto-scaling shenanigans (or are willing to script it yourself), you can gleefully skip Traefik, Docker Swarm, Kubernetes etc. and just use Caddy! It can really do most things and it does them well.

I think https://github.com/caddyserver is the best option here. Automatic handling of SSL certs, it's incredibly lightweight, and has super clear config syntax.

I like traefik hot reload (among other things). Want to hide a service (the proxied app), a new route (a router in traefik terminology), a middleware (basic auth, https redirection, headers manipulation) ? Just drop the file and it gets automatically picked up, no need to reload traefik or that vhost.

Truth is: I don't like nginx syntax and traefik is/was shiny :]. I went in for the LE renewal and containers, I stayed for the configuration style.

If what you've got already works then no, I don't think you would see any benefit from switching.

The moment you need a feature which Traefik provides that isn't in Nginx is when I would consider the switch.

I also use NginxProxyManager (8 hosts) and I'm not seeing any replies to your post that would explain why caddyserver or traefik provide any benefit over NPM.

Yeah I agree with this. Nginx config is easy and you can just set it and forget it. Most of the time you're copypasting from other configs you already have anyways. Automatic LE is kinda a strange selling point when Certbot is available everywhere and supports more scenarios. Traefik's and Caddy's selling points just don't make any sense to me because they don't make anything easier than the alternatives that are already widely supported.

Traefik does certificate management for you

metrics with non enterprise nginx are very limited.

I use Caddy for single-purpose hosts and the like, but I 100% would throw Traefik at the problems you're describing--and I do, it's my k8s cluster ingest and it runs in my dev environments to enable using `localtest.me` with hostnames.

It's worth kicking the tires on. Both are great at different things.

I use (rootless) docker compose + traefik. Precisely because for wildcard certs it was really painless. Although I use my own DNS server and use RFC2136 DDNS for the LE DNS challenge. No plugins needed, really. I have basically one ansible playbook to set all this up on a vm including templating out the compose files. Then another playbook that can remove everything from the server again (besides data/mounts). For backups I use restic with a custom script that can back up files, different dbs etc to multiple locations.

In the past I deployed k3s but I realized that was too much and too complicated for my self hosted stuff. I just want to deploy things quickly and not have to handle the certs myself.

I have not used Caddy, I use traefik and it discovers docker properties for configuration and TLS certificates with auto update. Not sure about dynamic DNS - I do not use it from Traefik. Adding and removing containers does not need a restart AFAIR.

I've used caddy-docker-proxy in production and it doesn't cause Caddy to drop connections when loading a new config.

I just tested it locally to check and it works fine.

Those are giant limitations. This is the first I hear of any reverse proxy that has to restart and drop connections to update configuration. That is usually the first, most fundamental part of any such server's design.

Heavy +1 on the labels thing. Reduces the scope of things to keep track of massively, even if writing them the first time is slightly harder because of the escaping and verbosity.

I think a combination of traefik and docker compose are in the sweet spot for small scale self hosters that haven't reached the point where k8s will pay off. i.e. if you have less servers than a k8s HA control plane would use.

We're also using it in production. And people might laugh, but naming something which looks fine/cool/quirky on paper, but is actually terrible in practice is a big con. The amount of frowns and laughs we got from colleagues is staggering and a hindrance to implementation and using a product.

We've called it "tray-feek" and it was half ok, then we actually had a call with the official support and they told us its pronounced same as regular "traffic". So any discussion about that proxy goes with: "so we're receiving traffic on our public load balancer which used traffic's native load balancing to send traffic to traffic's pods...". It sounds stupid because it is stupid.

I just pronounce it "traffic". I'm not playing their damn head games.

I would say the biggest con is that, if a container is not existing/running, traefik is not aware of it or its labels. Otherwise you could more easily do cool stuff like maintenance pages, bringing up containers on the first request after inactivity etc. So for me, I have been thinking about creating a plugin that is aware of where I store my compose files and can look at them instead.

ae is closest to y, or hi. So Tryfik, is my guess, otherwise is Trayfik. If it's European fik, might be feek. *Just taking a guess here.

apparently "traffic" https://github.com/traefik/traefik/issues/795

All of these proxies seemed to have achieved feature parity within the last couple years.

Where they seem differ is the licensing, enterprise model, source language, and data plane model (sidecar vs no sidecar).

Same here, we've been using HAProxy for years now and only gets to improve

I tried to get caddy to listen to both ports 80 and 443 in a cluster. I failed miserably. The documentation simply dismisses this as a possible scenario.

If you like Caddy for it's ACME capabilities, then you might enjoy Traefik as well. It supports HTTP, TLS ALPN and DNS challenges and can be configured in one line as well.

Similar: https://git.deuxfleurs.fr/Deuxfleurs/tricot

Auth forwarding[1] is normally the route. This allows you to basically zero auth your services. You can also use wireguard or tailscale[2]

[1] https://doc.traefik.io/traefik/middlewares/http/forwardauth/ [2] https://doc.traefik.io/traefik/master/https/tailscale/

Cloudflare tunnels are super convenient and provide lots of auth mechanisms. If you set up a tunnel using cloudflared and proxy the IP through cloudflare, there's nothing even exposed directly to the internet. You can even have different auth requirements for urls (like /admin) or punch holes for stuff like webhooks.

I have set up quite a few as kubernetes pods that direct to private hostnames in different namespaces and pretty happy with it for internal apps.

> what people use to hide (and make accessible) the internal services such as grafana, prometheus, rabbit mq (the web interface) and such?

Proxies or VPNs like you mentioned. You usually don't expose things if you don't have to.

We use tailscale for this exact use case and has been working flawlessly so far. You can even set up ACL lists as a firewall.

For the purposes of some of my self hosted stuff, I wanted to see how far I could go without VPN and instead use mutual tls authentication with my stuff exposed to the internet. Client certs are issued by cert manager in my k8s cluster and traefik does my TLS Auth.

From the internet? Drop them at the ingress level (if using kubernetes). You could also do some ip filtering. Then use an internal proxy (or internal ip of some kind) to reach them.

For proof of concepts, I use cloudflare tunnels which allows you to add ACLs to particular routes.

They are open to the internet but each ingress is using the “external auth” feature of nginx ingress, pointing to our internal login. There’s no vpn or magic ip addresses. Once you’re logged in, you can access whatever you need.

Serve them on a firewalled port, then: 1) VPN if you need to expose them to multiple trusted users, 2) firewall rules to make them accessible to your IP range, or (probably easiest), 3) access them by ssh tunnel.

zero trust, host firewalls, mtls, ssh tunnels, bastion hosts.

I'm using a reverse proxy just to terminate TLS. Pretty sure it is possible to do that at a service level, but don't think it's worth the trouble.

Devops guys are mostly incapable of using any service that isn't a) written in Go and b) configured using a YAML-based DSL.

For Caddy, LetsEncrypt: Free TLS in one line without talking to anyone

For Traefik, afaict, something about k8s

If I am not misunderstanding (sorry if I am) it sounds like you use the http challenge where your cert provider tries to GET your challenge file — if so, could the DNS challenge be better suited? There, you put the challenge in a TXT record value

Could you say more about how a non-network socket would be beneficial? I'm guessing simpler code and lower resource usage, but I'm curious what you're interested in. And by "single node", do you mean one server / one user (even if the user is, say, a single API consumer or whatever), or something else?

You'll likely have an ingress controller provided with openshift, which tends to be more batteries included. There are quite a few options: https://kubernetes.io/docs/concepts/services-networking/ingr...

Even on Hetzner, it's not amazing and not a one-click workflow.

Load their Photoprism image on a standard server with only IPv6 (as a v4 address costs extra) and certificates will not get generated; logs point to Traefik although the solution is modifying Dockerfiles; thanks Dockerphiles, for insisting your software is the answer to everything server...

Traefik can't serve static files, or interact with CGI providers like PHP.

The rest of the sentence you quoted explains that nginx, Caddy, and Apache are all webservers (which can also reverse proxy). Traefik and HAproxy are only reverse proxies and not webservers.

Caddy is primarily a web server like nginx and apache httpd. Traefik and HAproxy are primarily reverse proxies.

Caddy is at the same level as nginx/apache. It is able to do everything a web server is expected to (serving web sites, files and proxying services) plus handling LetsEncrypt automatically. It does not, afaik, do dynamic service discovery like traefik nor load balancing of TCP at the protocol layer, like e.g. haproxy. https://caddyserver.com/features

I don't see why you're opposing HTTPS everywhere and SNI, HTTP already had the Host header so it is not a new information leak.

It's pretty much mandatory if you intend to serve multiple domains with different certificates from the same host/proxy, which seems like a very very common use case, and there is no alternative to this right now.

can you elaborate?