It's an interesting choice to make this a whole app, when the zero-downtime deployments can be achieved with other servers trivially these days. For example any app+web proxy which supports Unix sockets can do zero-downtime by moving the file. It's atomic and you can send the warm-up requests with curl. Building a whole system with registration feels like an overkill.
That does not address OP's point. Any plain old reverse proxy handles this usecase, particularly those already used extensively as ingress controllers for container orchestration systems. Some even support specialized routing strategies.
Other than NIH, what exactly does kamal-proxy offers that any other reverse proxy doesn't already provide?
Ah, I was more referring to why this tool was released and wanted to say it’s a component of their Kamal deployment tool and not so important on its own.
There’s some more explanation on why they decided to switch away from Traefik:
> There’s some more explanation on why they decided to switch away from Traefik:
Unfortunately no. I posted my comment after reading that PR. It says nothing of substance, and presents no justification. The case to roll out their own is summarized in this claim:
> No need for cordfiles, which were a hack used to stop Traefik from sending request to a container to make it unhealthy. Kamal-proxy just sends traffic where we tell it to.
The thing is, Traefik also "just sends traffic where we tell it to." It's one of it's most basic feature. In fact, that's the whole point of a reverse proxy. Why roll out their own?
And even if for any reason at all Traefik didn't cut it, why not pick one of the many many production-grade reverse proxies around? Why roll their own?
I'm not arguing for Kamal, but just to let you know you fell in to the trap of disregarding a sentence you didn't understand. You quote "no need for cordfiles...just sends traffic" but then you write a response as if they didn't just explain to you why Traefic doesn't just send traffic where you tell it to.
