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.