Fast HTTPS for Developers

By Kellen 

HTTPS is now considered requisite when building an application or hosting a website. For good reason! In short, using HTTPS keeps your users safe, provides SEO benefit, and enables the web's most cutting edge features. What's the easiest and fastest way to use HTTPS with your applications? We'll compare 3 solid options - we've included ourselves, but don't hold that against us!

Foggy on HTTPS? We've written a solid introduction.


Before Let's Encrypt valiant burst into the scene, users needed to purchase their own signed TLS/SSL certificates from a certificate authority. A respectable authority would sell you a certificate anywhere from $150 for a single domain to $650 for a wildcard domain. Let's Encrypt changed the game by offering free certificates.

The Electronic Frontier Foundation created certbot, a utility one could run on their servers in order to easily generate and renew Let's Encrypt SSL certificates. For HTTPS, a user simply needs to install it:

sudo add-apt-repository ppa:certbot/certbot  
sudo apt-get update  
sudo apt-get install certbot 

... Generate a certificate by following the instructions...

certbot certonly --standalone  

Then take the certificate and transfer it wherever it needs to be - differing whether you're using HAProxy, Nginx, Apache, or another hosting service.

While there has been improvement in reducing the difficulty of acquiring a certificate to use, this method still requires us to muck with servers and load balancers. For those hosting static content or using application hosting platforms, a more streamlined, less complex solution is desirable.

Content Delivery Network

The most common recommendation for free and simple HTTPS has been CloudFlare. CloudFlare provides HTTPS between the client and the first CloudFlare edge server. Folks who use GitHub Pages or host applications on Heroku often look to CloudFlare to secure their sites.

Setting up your site within CloudFlare requires you to change your domain nameservers. During setup, you receive two CloudFlare nameservers, for example: and With those in hand, you then visit your current DNS host and change the nameservers over to CloudFlare.

After you've made the change, CloudFlare becomes your new DNS host. From there, A or CNAME records that you create are routed through CloudFlare with "Flexible SSL" enabled.

Handy! But there are a couple caveats. The first is that you're forced into using CloudFlare to host your DNS. The second is that their free "Flexible SSL" only protects you from client-to-edge; the route from edge-to-app is exposed. Note the absence of the lock!



Fly can give you HTTPS in minutes. First, create a account. Afterwards, click 'Add site' and enter a valid hostname like, then select a backend type.

Screenshot of hostname additions

Fly then provides you with a secure URI, like: The next step is to take this URI and create an ALIAS or CNAME record wherever your domain is hosted.

If using an API is more your flavour, you can use the Fly API to create a signed certificate with on call.

curl -X POST \
-H "Content-Type: application/json" \
-d '{"data": { "attributes": { "hostname": "" } } }'

In return, the API will churn out an hostname. You, or the customer who you just provisioned a unique HTTPS hostname for, then creates a DNS record to prove ownership of the domain.

If we stop here, we'd have the same security as "Flexible SSL", only DNS-host agnostic; you can use any DNS host that you'd like. You just set-up one record. Another nifty benefit: Fly uses Let's Encrypt to automatically generate and renew SSL customized certificates for each hostname that you configure within the UI. They're custom, signed, trusted, unshared certificates made by a transparent party of industry leaders.

While simplified HTTPS from client-to-edge is valuable, true end-to-end encryption is optimal for keeping your users secure. If you want to secure the full traffic route - from client-to-edge then edge-to-app - you can install our open-source utility Wormhole. Wormhole creates an encrypted tunnel between to end-points, solving the problem of exposed data in someone else's network.

Summary: Fly Keeps It Simple!

Many services that seem to offer HTTPS, like GitHub Pages, don't provide you a signed certificate that matches your domain. This prevents you from reaping Google's SEO boost for HTTPS sites and doesn't prove your own ownership of your domain. For that, you'd need a signed SSL certificate like the above options provide.

Manually serving signed SSL certificates can be complex, requiring an initial setup and on-going maintenance. Other delivery networks like CloudFlare are viable, however you are required to make the CDN your DNS host and you don't have a secure route between edge-and-app. Fly requires only a DNS record to prove ownership of your hostname and you have the option of installing wormhole for full client-to-app encryption... She's got that API, too...

Fly is the easiest way to get HTTPS for your own applications or for your users; it's a CDN for developers. Both are faster and easier than self-hosting using something like certbot. Fly started when we wondered "what would a programmable edge look like"? Developer workflows work great for infrastructure like CDNs and optimization services. You should really see for yourself, though.