Rationale for Kaml Proxy in Kamal v2

[NatElkins]

Hi,

I was just reading about Kamal 2 and Kamal Proxy in this Hacker News thread: https://news.ycombinator.com/item?id=41608350

In that thread, the following comment was made about the use of Kamal Proxy:

They're using the autocert package which is the bare minimum. It's brittle, doesn't allow for horizontal scaling of your proxy instances because you're subject to Let's Encrypt rate limits and simultaneous cert limits. (Disclaimer: I help maintain Caddy) Caddy/Certmagic solves this by writing the data to a shared storage so only a single cert will be issued and reused/coordinated across all instances through the storage. It also doesn't have issuer fallback, doesn't do rate limit avoidance, doesn't respect ARI, etc.

Holding requests until an upstream is available is also something Caddy does well, just configure the reverse_proxy with try_duration and try_interval, it will keep trying to choose a healthy upstream (determined via active health checks done in a separate goroutine) for that request until it times out.

Their proxy headers handling doesn't consider trusted IPs so if enabled, someone could spoof their IP by setting X-Forwarded-For. At least it's off by default, but they don't warn about this.

This looks pretty undercooked. I get that it's simple and that's the point, but I would never use this for anything in its current state. There's just so many better options out there.

I was wondering if anyone from the project could give a rationale for why Trafeik was dropped in favor of rolling a custom solution. I tried searching in the kamal-proxy repo and and related PRs but couldn't find much.

This is a great piece of software and I'm looking forward to using it in my next project. Thank you!

[saiqulhaq-hh]

I am also wondering about this issue
Maybe because:

1. They don't know that there is a rate limit on Let's Encrypt
2. They use Cloudflare, so doesn't need to generate certificate
3. They haven't use it on the big scale yet. It's very fine to use it to run a blog https://x.com/mhenrixon/status/1837037559219732866?s=61&t=OMr797nPHm8qeBmfNz45pw
4. It just a temporary feature, they will fix it later. As we know that they never write any roadmap in many gems.
5. To fix this TLS support through Let's Encrypt using Traefik #112
6. Someone has to contribute to fix this issue

[NatElkins]

A bit of research yielded this blog post: https://nts.strzibny.name/kamal-proxy/

I found it helpful. That said, I would be very curious to hear some of the points from the comment addressed, in case there are truly some shortcomings that might be overlooked.

[saiqulhaq-hh]

I found the original idea #940
it says:

ssl - requires hosts to be set if enabled, if enabled it will automatically set up HTTPS via Let's Encrypt. Should only be used with one server!

So it's wrong implementation if the OP uses it on many servers
which could hit the Let's Encrypt rate limit

[dhh]

Kamal Proxy was introduced to simplify both SSL certificate provisioning and multi-apps on a box deployment without needing any Traefik configuration. It also allowed us to build an integrated solution for gapless deployments that is faster than the old polling setup.

We use the same LE auto provisioning approach for all of ONCE. It's worked great for thousands of installations. But you don't need to use it. You can provision your own certs and provide that. Or put caddy or Cloudflare or whatever in front to do SSL termination.

I don't think most people need that, and I think it's more important to compress the complexity surrounding all of this. But whatever floats your boat. If you're already a Traefik or Caddy expert, feel free to stick that in front.