How to use fly.io to manage the multiple domains for our project

Hi

This is my first time here

I want to know how to use the fly.io for the following use case

  1. User will come on our website and register their workspace
  2. The workspace url will be https://<workspace>.our-platform.com
  3. For higher plans they can even change the complete url, https://manager.mywebsite.com

When any of these url is hit, it should open https://manager.our-platform.com

Our DNS is managed on CF and application is hosted in GCP

2 Likes

We plan to implement this as well very soon. Following :pray:t2:

An example for something like this would be amazing! We had something like this in production a few years ago now on the original fly model and only found the experience to be amazing.

Having an example that makes something like this super simple to understand and implement is pretty valuable to the platform as a whole, specially for SAAS partners.

Another note, in the past, we had to do some CNAME flattening on Route53 in order to give out more friendly on brand CNAME’s to our customers and to have the nameservers where we can change where they point at any moment. Would love to hear more on this as well :grin:

I can give you a quick outline of how it could work:

  • Create a wildcard certificate with Fly for *.our-platform.com and go through the steps necessary for us to generate a certificate for it.
  • You create wildcard A and AAAA records for *.our-platform.com and point them at your Fly app’s IPs
  • For higher plans, you tell your users to create a CNAME record for their hostname and point it at manager.our-platform.com (or their <workspace>.our-platform.com, this might be easier if you want to move some workspaces at some point)
  • Every time you create a new “higher plan” workspace in your app, you can call our hostname API to create a certificate for this custom hostname (this is detailed here: Custom Domains and SSL Certificates · Fly Docs, this whole doc might be of some help!)

You can stay with Cloudflare, but regarding GCP: it would be best to host your app on Fly! It’s also possible to keep GCP and just create an app on Fly that’s a reverse-proxy (like nginx, Caddy, etc.) to it. This adds an extra layer though, where things can go wrong and definitely adds latency.

2 Likes

Wow this is amazing, it’s almost too easy!

1 Like

Would the client need to add the acme challenge as well? If so would we need to expose the flydns.net CNAME record instructions?

The client wouldn’t. We use the ACME TLS ALPN challenge for everything but wildcard certificates. As long as there’s an AAAA record pointing to your IP (a CNAME will od that if the DNS provider flattens them), certificates will get renewed automatically without any intervention.

Im sorry just to clarify, I meant this for the https://manager.mywebsite.com certificates the customer would only add the CNAME pointing to manager.our-platform.com correct?

Yes. Or a CNAME to any other hostname pointing at both A and AAAA. As long as the AAAA is being flattened to your app’s IPv6, then we can issue certificates.

1 Like

I feel a bit odd giving out IPs to customers incase they change or we some how loose access to the IP in anyway.

I like that we can generate a subdomain on our branded wildcard and have them point their custom domain to that as a CNAME.

To confirm this is just as “correct” as using A/AAAA records? Any downsides to CNAME over AAAA?

My knowledge on SSL certs is limited haha Something I have always just let services like fly/heroku/cf handle for us :slight_smile:

Sorry, I wasn’t clear.

That’s the correct way yes. Your users should point a CNAME record at your hostname.

The only downside is that some of them might not be using a DNS provider that does CNAME flattening, but that’s increasingly rare.

1 Like

Awesome, great to hear.

Do you have a best practice for the case in which they do not have flattening on their nameserver provider of choice?

I’m afraid there aren’t any alternatives other than asking them to switch to a support provider or point their A and AAAA records to your IP on Fly.

These IPs will stay yours. It will be a bit painful if you move away from Fly, to get them to change their DNS records.

1 Like

Perfect, that is fine, we can always have the IP A/AAAA records in our back pocket for our support team to use as a backup. Being thats its so rare, we can just instruct these clients to use the IP if they are having issues.

Thanks again for all the help @jerome

@jerome This is pretty awesome. However we setup our Fly account before there were Wildcard certs and have created hundreds of .listingvillage.com certs. We’ve tried adding a *.listingvillage.com cert to the Fly dashboard and have setup the * CNAME record on our end, but the wildcard cert has not been created.

Are there any known issues when trying to create a wildcard cert when single site certs have already been created?

-Matt

It should be fine, but there are special instructions like setting a CNAME for _acme-challenge.

It should be detailed in the flyctl certs show *.listingvillage.com command.

Should we email support if we have setup the _acme-challenge, the DNS is “resolved”, but the SSL is “missing”? Normally the SSL is ready to go in a few minutes and it’s been several hours.

It’s a Namecheap DNS we control directly. Ever one of the 400+ Fly certs we’ve setup using the same configuration has worked perfectly.

I actually don’t see the _acme-challenge CNAME for that domain: DNS Checker - DNS Propagation Check & DNS Lookup

Can you double check the _acme-challenge record?

Oh it might be that you have a TXT record there already. Make sure there’s no TXT record for _acme-challenge too!

Should be set exactly as instructed here:

Namecheap DNS:

Resolved?