Show HN: An API to provision custom hostnames with SSL

We launched an API for custom hostnames today. A simple HTTP post with a hostname gets a temp hostname with CNAME/a record instructions, as soon as DNS is setup we issue SSL and start accepting traffic for that hostname. It's the quickest way we know of to provision custom hostnames: https://fly.io/mix/custom-hostnames/

When we started building Fly, we figured it was too late to "make SSL easy and the customers will come". Lets Encrypt changed the world, and we knew many companies rolling their own SSL support with nginx, Traefik, etc, etc. It seemed like a solved problem.

It turns out that SSL is still a pain, particularly companies with lots of hostnames pointed at them ... anyone hosting apps/content on behalf of their own customers. Distributing certificates, keeping them renewed, and — most of all‚ making https fast is still hard. Devs can solve the basic problem in a week or so with a proxy, but then it sits, and no one feels very comfy with untouched infrastructure. And it's usually something distracting devs from more important work that's core to their own customers.

So this is our way of solving that problem. We can handle any number of hostnames for applications, devs can spend more timeon what makes their apps special. It's a relatively "simple" use of what we've built, but solves a really fundamental problem for a many companies. It's the most fun thing we've discovered this year.

So, if you're building an app, and serve stuff on behalf of your users, we can make your life easier:

https://fly.io/mix/custom-hostnames/

It's not, it's meant for cases where people need entirely different custom hostnames. Subdomains are quick and easy, but people have become quite a bit more demanding about how their stuff is branded, and tend to want it all on mydomain.com (instead of me.service.com).

Actually I lied, it's probably a little easier than a wildcard cert. :D But not enough to matter. People who just need wildcard subdomains might want to use us for other reasons. We handle all load balancing, global SSL termination, etc. These things are stuff you'd use even if you were just using a wildcard cert.

As I understand it, this is for domains provided by their users. The rate limits would not be problematic unless the domain uses Let's Encrypt for a lot of other subdomains.

I'm guessing they're using a wildcard certificate for the temporary hostname.

pfg is correct, the rate limits don't really come into play when you're issuing certificates with a lot of different root domains. We'll get the rate limits raised if we end up issuing a lot of subdomains, but for now we recommend people bring their own wildcard certs, and as soon as LE starts issuing wildcards we'll just use those.

Can you help me understand how this is different than Cloudflare's offering [1]?

1- https://www.cloudflare.com/lp/sector/saas/