Add Support for Path-Based Routing in Kamal

[jvkassi]

Currently, Kamal only supports host-based routing, which limits its flexibility when managing requests on a single domain or multiple applications under the same host. To enhance its functionality and improve usability, I suggest implementing path-based routing for the following reasons:

• Efficiency in Resource Usage:

With path-based routing, multiple services can be deployed under a single host (e.g., example.com/app1, example.com/app2), reducing the need for additional hostnames or subdomains. This is particularly beneficial when using wildcard SSL certificates or when managing applications within a single domain.

• Simplified Application Management:

Path-based routing allows for the separation of different applications or services under distinct paths (e.g., /api, /admin). This simplifies management and reduces complexity, especially when dealing with microservices or multiple frontends that share a domain.

[kevinmcconnell]

@jvkassi yes, agreed. We've been talking about adding this, and I have a solution in mind that I'm starting to work on. My current thinking is we'll add a path prefix option that you can use when deploying, either in combination with host-based routing or on its own. If you specify a path prefix, then only requests that match the prefix will be routed to that service. That should be enough to have apps share a domain but split according to /api, /admin, /app, etc.

I expect to have something more concrete to try out for this soon.

[nuschk]

My usecase (with Kamal 1.9) is to have a CMS and an app server behind the same Traefik instance, on the same domain. What I do is route the root path (/) and all paths with a content prefix (/c/*), as well as some CMS related paths (/_next/* etc.) to the CMS, and have all other requests fall back to the app server.

I wonder how that would be able with your proposal. It would probably require either some sort of service priority (which is what Traefik offers) or some sort of negation ("not these paths"). And also, not just path prefixes, but also paths (a distinction Traefik makes as well).

Would be great if that would go into your consideration!

[stefsava]

Great news that you are working on it, it is very similar to what I need to install multiple Odoo instances on a single server (or more than one with load balancer).

Specifically, Odoo requires / requests to be routed on port 8069, while /websocket requests are routed on port 8072.

Here is the nginx configuration suggested by the official documentation:
https://www.odoo.com/documentation/18.0/administration/on_premise/deploy.html#id8

I use rails and odoo and I am happy to abandon dokku and embrace kamal as soon as possible.

[grimesp]

I would also love to see this. Our use case would be deploying multiple Java web applications as separate docker containers as part of a large ERP system. In the Java world, you can have multiple war files in a single Java web server (Tomcat), but each war file is an independent Java web application, they all have different URL paths. We like to keep one war file per Tomcat container so we can upgrade components of the ERP independently. It is also nice for security, keeping them in separate docker containers provides a nice layer of isolation.

[shiny]

My case is deloying a mastodon instance. When I convert docker-compose.yml to deploy.yml, It requires the path /api/v1/streaming to serve a websocket instance by default.

[voberoi]

Is this feature still in the cards?

Was a lot easier when you were using Traefik because this was baked in and I could use Docker labels.

But now I have to deploy my own proxy (Traefik/Caddy/whatever) with its own settings in addition to apps. This is workable, but annoying/more to keep track of and mess up.

[nikklavzar]

I am also waiting on this feature before migrating to kamal v2.

[mkuklis]

@voberoi I'm curious did you turn off kamal-proxy completely and setup Traefik via accessories?

[voberoi]

@mkuklis I didn't. kamal-proxy is too usefully integrated into Kamal.

My use case is that I have a stack of monitoring tools that I deploy (prometheus, grafana, dozzle) that are basically configured the same way on a single app server. These are pretty basic app deployments.

I started using accessories to deploy them in Kamal v1.

I use Kamal v2 now. And I just have a separate app where:

• The main app is Caddy. Path-based routing is set up there.
• The app uses kamal-proxy at a subdomain (e.g. monitoring.mydomain.com)
• I have set up all three services as an accessory, and Caddy's set up to proxy to them.
• They're all on the same network and their names are deterministic, so I use those.

This does the job but there are still annoying things about it --

• I don't want to have to set up a proxy in front of the proxy just so I can benefit from path based routing
• kamal doesn't allow a public Docker image for the main app. So instead of using the Caddy public image, I had to create my own that extended the public image and was uploaded to my private registry. There's a ticket about this somewhere but I can't find it.

[mkuklis]

@voberoi thank you so much for finding time to respond to me. Your setup makes a lot of sense given this current limitation in kamal-proxy.

[kevinmcconnell]

Thanks for all the suggestions on this issue so far, everyone. Apologies for the radio silence 😬

The feature is still on the cards, and it's been on my list to get it shipped. I have some sketches of how I think it should work, and I'm aiming to have a working version soon that folks can try out. Stay tuned :)

[gedw99]

@mkuklis I didn't. kamal-proxy is too usefully integrated into Kamal.

My use case is that I have a stack of monitoring tools that I deploy (prometheus, grafana, dozzle) that are basically configured the same way on a single app server. These are pretty basic app deployments.

I started using accessories to deploy them in Kamal v1.

I use Kamal v2 now. And I just have a separate app where:

• The main app is Caddy. Path-based routing is set up there.
• The app uses kamal-proxy at a subdomain (e.g. monitoring.mydomain.com)
• I have set up all three services as an accessory, and Caddy's set up to proxy to them.
• They're all on the same network and their names are deterministic, so I use those.

This does the job but there are still annoying things about it --

• I don't want to have to set up a proxy in front of the proxy just so I can benefit from path based routing
• kamal doesn't allow a public Docker image for the main app. So instead of using the Caddy public image, I had to create my own that extended the public image and was uploaded to my private registry. There's a ticket about this somewhere but I can't find it.

Hey @voberoi

I started to use caddy in front of kamal-proxy also .

I needed it for the path based routing also.

The json events that kamal proxy throws out are normally used by the ruby side, but I found I can use them with caddy and other choreography layers to react to changes in kamal.