I don’t work for Fly so I can’t help with the feature suggestion, but focusing on what you’re trying to achieve: I expect you’ll encounter quite a few challenges if you try to avoid any sort of datastore, especially with certificates involved.
Here are a couple of scenarios that come to mind:
- A customer asks for a new domain name (e.g:
x.example.combecomesy.example.com) - A customer swaps from your hosted service to self-hosting and wants their old domain to redirect
- A pentest highlights that serving user-code from
*.example.comis a security issue and you must migrate to using*.examplecustomers.com[1] - Fly has a bad day and a zone goes down forcing you to move apps – which could require a change of app name
- You decide to migrate from Fly to a new provider, but want to do it customer-by-customer, or new customers only
- Fly changes how DNS is allocated for new apps
The traditional way to handle this would be to use a wildcard record (e.g: *.example.com) which points to server(s) responsible for routing requests to the appropriate tenant based on some internal lookup. Removing the datastore and using a Cloudflare worker style runtime determination of the destination based on parsing the domain name and then calculating what the .fly.dev domain should be is will cause you a lot of headaches as soon as you encounter some of the weird things customers need/want. You’ll still remember writing this post when you get your first request to add some special code for one special high-paying customer, and before you know it, you’ve got middleware filled with lots of special cases – and shipping a bug in it can take down all your customers.
Personally, I’d use DNS records until I got to the point where it was too costly. There’s a little extra upfront work required to write code to publish DNS records, but it’ll pay dividends as soon as you have to do something that deviates from your current use case.
A good principle to keep in mind when managing infrastructure for customers: there’ll always be a customer with deep pockets who wants something ridiculous, so build a system that can capture that revenue without needing a rethink.
[1] You should do this regardless of approach, so just in case you haven’t already planned to, definitely use a customer-specific domain. Fly have fly.dev, GitHub have github.io, Google Cloud Run uses run.app etc.