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?

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!

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.

And when you use a role like this, you really should use an external ID to avoid confused deputy attacks.

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_cre...

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.

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.

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.

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?

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?

That's right! It happens immediately. Thanks for checking us out.

I'm not sure how this is easier than a wildcard certificate and a wildcard CNAME...

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.

Actually when Let's Encrypt will provide free wildcard in early 2018 the later will be much more easier !

Yes! We're looking forward to this at Fly :)

> 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?

We do minimally integrate with G Suite, our auth middleware lets you require users to auth with Google, and restrict it to a particular @domain.com: https://fly.io/docs/guides/#google-auth-middleware

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

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

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.

howto vid link?

Who did the illustrations on the landing page?

https://twitter.com/annieruygt She's awesome! :)

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.

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)?

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.

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

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

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.

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?

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

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

Would there be a way to get it to work with App Engine?

Yes! Send us an email and we can help: support@fly.io