<story><title>Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments</title><url>https://github.com/basecamp/kamal-proxy</url></story><parent_chain><item><author>ksajadi</author><text>This primarily exists to take care of a fundamental issue in Docker Swarm (Kamal&amp;#x27;s orchestrator of choice) where replacing containers of a service disrupts traffic. We had the same problem (when building JAMStack servers at Cloud 66) and used Caddy instead of writing our own proxy and also looked at Traefik which would have been just as suitable.&lt;p&gt;I don&amp;#x27;t know why Kamal chose Swarm over k8s or k3s (simplicity perhaps?) but then, complexity needs a home, you can push it around but cannot hide it, hence a home grown proxy.&lt;p&gt;I have not tried Kamal proxy to know, but I am highly skeptical of something like this, because I am pretty sure I will be chasing it for support for anything from WebSockets to SSE, to HTTP&amp;#x2F;3 to various types of compression and encryption.</text></item></parent_chain><comment><author>jauntywundrkind</author><text>Kamal feels built around the premise that &amp;quot;Kubernetes is too complicated&amp;quot; (after Basecamp got burned by some hired help), and from that justification it goes out and recreates a sizable chunk of the things Kubernetes does.&lt;p&gt;Your list of things a reverse proxy might do is a good example to me of how I expect this to go: what starts out as an ambition to be simple inevitably has to grow &amp;amp; grow more of complexity it sought to avoid.&lt;p&gt;Part of me strongly thinks we need competition &amp;amp; need other things trying to create broad ideally extensible ways or running systems. But a huge part of me sees Kamal &amp;amp; thinks, man, this is a lot of work being done only to have to keep walking backwards into the complexity they were trying to avoid. Usually second system syndrome is the first system being simple the second being overly complicated, and on the tin the case is inverse, but man, the competency of Kube &amp;amp; it&amp;#x27;s flexibility&amp;#x2F;adaptability as being a framework for Desired State Management really shows through for me.</text></comment>
<story><title>Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments</title><url>https://github.com/basecamp/kamal-proxy</url></story><parent_chain><item><author>ksajadi</author><text>This primarily exists to take care of a fundamental issue in Docker Swarm (Kamal&amp;#x27;s orchestrator of choice) where replacing containers of a service disrupts traffic. We had the same problem (when building JAMStack servers at Cloud 66) and used Caddy instead of writing our own proxy and also looked at Traefik which would have been just as suitable.&lt;p&gt;I don&amp;#x27;t know why Kamal chose Swarm over k8s or k3s (simplicity perhaps?) but then, complexity needs a home, you can push it around but cannot hide it, hence a home grown proxy.&lt;p&gt;I have not tried Kamal proxy to know, but I am highly skeptical of something like this, because I am pretty sure I will be chasing it for support for anything from WebSockets to SSE, to HTTP&amp;#x2F;3 to various types of compression and encryption.</text></item></parent_chain><comment><author>hipadev23</author><text>I feel like you’re conflating the orchestration with proxying. There’s no reason they couldn’t be using caddy or traefik or envoy for the proxy (just like k8s ends up using them as an ingress controller), while still using docker.</text></comment>