HN Explorer

Show HN: An API to provision custom hostnames with SSL

90 points by mrkurt ↗ HN
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/

37 comments

[ 2.6 ms ] story [ 83.3 ms ] thread
tom169
I'm not sure how this is easier than a wildcard certificate and a wildcard CNAME...
mrkurt
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.

askz
Actually when Let's Encrypt will provide free wildcard in early 2018 the later will be much more easier !
matahwoosh
Yes! We're looking forward to this at Fly :)
RKearney
How do you work around the rate limits imposed by Let's Encrypt?

https://letsencrypt.org/docs/rate-limits/

If you're getting certificates issued for subdomains of your domain, you're limited to 20 certificates per week of up to 100 SANs per certificate.

Are you just not hitting this limit yet, or do you load balance certificate requests across a pool of domains?

pfg
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.

mrkurt
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.
stevoski
Timely. I launched a SaaS a few months ago and have found early customers have expected custom domain names with SSL. It seems that not offering this is a deal breaker these days.

I didn't even consider that third parties such as yourself might offer a solution.

Edit: I tried to sign up. I have to already choose lots of detailed config options? No option for AWS elastic beanstalk or EC? Asking for my AWS secret key without explaining why?

mrkurt
Send me an email and I'll help (kurt@fly.io, or support@fly.io)! We've been working on improving the onboarding flow for new apps, but it's definitely complicated. Elastic Beanstalk and EC2 will work fine, and we can help you get setup. You can either run through ELB (if you already have that setup) or use our agent and let us handle all the load balancing: https://fly.io/docs/agents/

It should be obvious when and what we need AWS keys for. We only need those for private S3 buckets and to invoke Lambda functions. We don't want full access keys, just scoped IAM stuff!

theossuary
One thing I really appreciate from companies is when they give me a policy with just the permissions they absolutely need to function (or a reference to a cross-account policy). That way I can review it and I'm not dicking around with trying to figure out the right permissions, and I know what all you may have access to. Getting s3 objects may be a deal breaker for example, unless the action is properly scoped to a bucket.
mrkurt
Yeah agreed. We should make that explicit, or even give people a CloudFormation template to set up a restricted policy.

And to be clear, we don't need s3 access unless you want to serve files from a private s3 bucket. Most sites don't use that at all.

subway
You don't need AWS keys at all. This enrollment flow flies in the face of best practices.

Intead, you should be providing your users with instructions to create an IAM role for cross-account utilization. Ideally in addition to the instructions, you'd provide a minimal CloudFormation template defining such a role, with your minimum required permissions.

Asking a customer to create a user and ship you a secret is asking for trouble.

samstave
DING DING DING

The problem is that a junior level of exposure may result in access+secrets being mistakenly given out.

Yeah - they should be looking into say, cloudability, or any number of thousands of offerings ding just this.

Gys
I am trying to understand what you offer, compared to AWS. Does it kind of substitute the combination of API Gateway + CloudFront + Certificate Manager ?

I have some Lambda funcs running and just today starting looking into this AWS combination to access Lambda from the outside world. So I wonder if Fly would do the same.

If its the same then it certainly is simpler to set up. And might be cheaper as well, but the pricing of AWS is unclear as always (meaning always having some unexpected aspects).

mrkurt
Fly is a good alternative to API Gateway + Cloudfront + Certificate Manager. We can invoke lambda functions directly.

And yes, AWS pricing is a monstrous headache. I'm really not sure if we're cheaper at scale, but we're easy to predict at the very least (and the first 2 million requests are free).

Gys
Ok thanks. Might be good to mention comparable AWS services (and maybe others) in your faq. Its only because of this being on HN that I gave it more then a few seconds of consideration ;-) If I ran into it by accident I might have missed the essence.
bosdev
Can you help me understand how this is different than Cloudflare's offering [1]?

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

mrkurt
It's superficially similar. The most obvious difference is that you need a CloudFlare Enterprise plan to do that stuff, and we have a free tier + easy metered pricing.

You can probably do a complete Fly implementation in the time it takes to setup a call with one of their sales folks.

andrewbarba
I may have missed this in the docs, but how are you verifying that someone owns the hostname they are trying to create a cert for? Do you need to cname the hostname to a fly domain first?
andrewbarba
I see, read too quickly. So after the POST we/user needs to create a DNS entry and then you guys will poll for that and kick off cert generation, right?
goodroot
That's right! It happens immediately. Thanks for checking us out.
[deleted]
(comment deleted)
firekebab
I found the same problem also exists for the end users who are sometimes using apps that don't support custom hostnames but they still want a brandable domain for it.

So I recently made https://www.ManagedAlias.com/ as an experiment to see if there is demand.

I avoided the bulk/business route because you essentially have to be a CDN to pull that off (since you are doing the TLS termination).

This is just geared towards non-technical people who need a pretty name for a site without fuss and they don't want to mess with anything technical.

le-mark
How's this going for you? Are you getting any traffic/signups? Do you have an mvp that people are actually using? What are you doing to get traffic (other than posting here)?
firekebab
Not well :D

It was only "launched" recently and as an experiment.

Don't have a cheap way of getting traffic really.

I ran an AdWords campaign, grand total of 1 signup out of it, and they haven't done anything with it.

I have a basic form for someone to create their alias, the rest of it is just manual setup now as I didn't want to waste time before validating.

Not getting any clicks/signups since it's not linked from anywhere.

type0
> If you use Netlify and want to use Fly to broaden your application scope, perhaps hosting Netlify as your marketing site on your root domain, then something like a Heroku application at /app/, then you've come to the right place.

Oh this is cool, you've got me intrigued there.

> Google Auth -- ... Do you want to gate off a static page so that only your Google Org may see it? We make it easy!

So does it integrate with G Suite?

[dead] poopoopoopoo
pure unadulterated awesomesausomeness in a bottle. well done dudes
corobo
Can it be whitelabel? That is to say will everything still work if I were to myself CNAME/ALIAS mysaas.example.com to <presumablyMySiteId>.shw.io then instruct my user to CNAME/ALIAS their domain to mysaas.example.com?

Edit: Answered my own question by testing - Yes it does work but with a suspicion it may break if shw.io ever splits off into more IPs instead of all resolving to the IP I'm given now

mrkurt
That will work fine if all the hostnames are on the same Fly site. It won't break down the road. :D