Fly makes it surprisingly easy to configure wildcard DNS, such that anything.your-new-domain.dev is served by a single Fly application (which can include multiple instances in multiple regions with global load-balancing).
Their documentation is at SSL for Custom Domains. Here's how I set it up.
\nI'm using your-new-domain.dev in this example, which is not a domain I have registered. .dev is interesting here because it requires SSL (or TLS if you want to be pedantic about it).
First, create an application:
\nfly apps create --name your-wildcard-dns-app\nThen create both an IPv4 and an IPv6 address for the application:
\nfly ips allocate-v4 -a your-wildcard-dns-app\nTYPE ADDRESS REGION CREATED AT \nv4 37.16.10.138 global 7s ago \n\nfly ips allocate-v6 -a your-wildcard-dns-app\nTYPE ADDRESS REGION CREATED AT \nv6 2a09:8280:1::1:3e99 global 4s ago \nThe IPv4 address is so you can serve traffic.
\nThe IPv6 address is needed as part of Fly's scheme to protect against subdomain takeover - see How CDNs Generate Certificates: A Note About a Related Problem for details.
\nNow setup the following DNS records:
\nyour-new-domain.dev A: 37.16.10.138\nyour-new-domain.dev AAAA: 2a09:8280:1::1:3e99\n*.your-new-domain.dev CNAME: your-wildcard-dns-app.fly.dev.\nThat CNAME record does the real magic here.
You can ask Fly to issue the certificate (which uses LetsEncrypt under the hood) by running this:
\nfly certs create \"*.your-new-domain.dev\" \\\n -a your-wildcard-dns-app\nThere's one last step: you need ta add an additional DNS record to verify the certificate.
\nInstructions for doing this can be found at:
\nhttps://fly.io/apps/your-wildcard-dns-app/certificates\nClick to view your unverified certificate and you should get a set of information that includes the extra DNS entry you need to add.
\nIt will look something like this:
\n_acme-challenge.your-new-domain.dev CNAME your-new-domain.dev.6g0mj.flydns.net.\nAdd that DNS record, then click the \"Check again\" button on the certificate screen and your certificate should be verified shortly afterwards.
\nWith the certificate in place, you can deploy a Fly app (using regular Fly or the new Fly Machines). Traffic to any subdomain of your domain, with or without https://, will be served by your new application.
One last detail which caught me out: you need to configure your Fly app to accept traffic on both port 80 AND port 443 for this to work.
\nThis is needed even if your app itself only serves on port 80 (or 8000 or whatever). The configuration here tells Fly's routing proxy what to do.
\nUsing fly.toml this means there should be two services.ports sections - here's an example that includes those:
app = \"your-wildcard-dns-app\"\n\nkill_signal = \"SIGINT\"\nkill_timeout = 5\n\n[[services]]\n internal_port = 8000\n protocol = \"tcp\"\n\n [services.concurrency]\n hard_limit = 25\n soft_limit = 20\n\n [[services.ports]]\n handlers = [\"http\"]\n port = \"80\"\n\n [[services.ports]]\n handlers = [\"tls\", \"http\"]\n port = \"443\"\n\n [[services.tcp_checks]]\n interval = 10000\n timeout = 2000\n grace_period = \"10s\"\nIf you are using Fly Machines you'll need to include the following in the JSON that is used to launch the machine:
\n \"services\": [\n {\n \"ports\": [\n {\n \"port\": 80,\n \"handlers\": [\n \"http\"\n ]\n },\n {\n \"port\": 443,\n \"handlers\": [\n \"tls\",\n \"http\"\n ]\n }\n ],\n \"protocol\": \"tcp\",\n \"internal_port\": 8001\n }