Wild card domains

[simonhutchings]

Has anyone had any luck with wildcard domains?

[simonhutchings]

The strange thing is, the certificate seems to be ok, but not redirecting to the app.

proxy:
  ssl: true
  host: *.example.com
  app_port: 3000
  healthcheck:
    interval: 15
    path: /up
    timeout: 5

but if i use a full subdomain, it works

proxy:
  ssl: true
  host: subdomain.example.com
  app_port: 3000
  healthcheck:
    interval: 15
    path: /up
    timeout: 5

Wondering if it's anything to do with the load balancer on cloudflare, but was working fine with the traefik solution on kamal 1

[anthonynsimon]

AFAIK in order to issue wildcard certificates kamal-proxy needs to use the DNS challenge for let's encrypt.

Maybe relevant to this discussion too: https://github.com/basecamp/kamal-proxy/issues/26

[aarroisi]

I also need this functionality. It would be great if we can use wildcard, even without the auto SSL generation.

[kevinmcconnell]

Wildcard routing without SSL is something I think we can add soon. Then if you want to also handle SSL at the proxy, probably the easiest way will be to bring your own certs (once #17 lands).

Also, fwiw we do have limited wildcard support now: if you deploy an app without specifying a hostname, that app will get all the traffic that isn't explicitly routed to another app. In other words if you do this:

kamal-deploy app1 --target=host1
kamal-deploy app2 --target=host2 --host=app.example.com,api.example.com

...then app1 receives all the traffic that doesn't have a hostname of app.example.com or api.example.com. This doesn't allow having multiple apps deployed together that both use wildcard subdomains. But for certain setups it might cover what you need -- like if you have a single app, or if only one of your apps needs to handle wildcards.

[aarroisi]

That's awesome! Thanks for that.

Also, fwiw we do have limited wildcard support now: if you deploy an app without specifying a hostname, that app will get all the traffic that isn't explicitly routed to another app. In other words if you do this:

Yes, I'm aware of that and have been using it.

My use case is that in one server I need to handle:

• *.dev.example.com
• *.staging.example.com

to route to different apps. Currently, we need to make adjustment outside of Kamal to make that works, but if it can be handled all by Kamal that would be really great.

[simonhutchings]

This is how I’ve set it up for the moment, as no way of telling what the subdomain will be for tenants.On 1 Oct 2024, at 13:03, Kevin McConnell @.***> wrote: Wildcard routing without SSL is something I think we can add soon. Then if you want to also handle SSL at the proxy, probably the easiest way will be to bring your own certs (once #17 lands). Also, fwiw we do have limited wildcard support now: if you deploy an app without specifying a hostname, that app will get all the traffic that isn't explicitly routed to another app. In other words if you do this: kamal-deploy app1 --target=host1 kamal-deploy app2 --target=host2 --host=app.example.com,api.example.com

...then app1 receives all the traffic that doesn't have a hostname of app.example.com or api.example.com. This doesn't allow having multiple apps deployed together that both use wildcard subdomains. But for certain setups it might cover what you need -- like if you have a single app, or if only one of your apps needs to handle wildcards.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[kevinmcconnell]

@simonhutchings @aarroisi I've just merged support for routing with wildcards. It will be available when we do the next Kamal release (which is likely to be quite soon).

You can see the details in #45, but the idea is that you can now specify hosts like *.example.com in order to have an app to receive requests for all subdomains of example.com, and so on.

[aarroisi]

@kevinmcconnell Thanks a lot for this! Can't wait to try it on Kamal.