Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wild card domains #30

Closed
simonhutchings opened this issue Sep 29, 2024 · 8 comments · Fixed by #45
Closed

Wild card domains #30

simonhutchings opened this issue Sep 29, 2024 · 8 comments · Fixed by #45
Assignees

Comments

@simonhutchings
Copy link

Has anyone had any luck with wildcard domains?

@simonhutchings
Copy link
Author

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
Copy link

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: #26

@aarroisi
Copy link

aarroisi commented Oct 1, 2024

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

@kevinmcconnell
Copy link
Collaborator

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.

@kevinmcconnell kevinmcconnell self-assigned this Oct 1, 2024
@aarroisi
Copy link

aarroisi commented Oct 1, 2024

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
Copy link
Author

simonhutchings commented Oct 6, 2024 via email

@kevinmcconnell
Copy link
Collaborator

@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
Copy link

aarroisi commented Oct 6, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants