We get asked questions about Fly in a lot of places on the web which we answer. But, not everyone is everywhere on the web, so with Fly Answers Questions, we bring those answers to you. If you have questions about Fly, why not ask @flydotio on Twitter, or drop a query in our Fly Spectrum.chat forum.
Q: Can I set up a custom hostname or domain with Fly?
A: You can. In fact you can set up as many of them on an application as you like. When you create a custom hostname on Fly and validate it, you also get Let’s Encrypt certificates automatically. You can read more about this in Custom Domains with Fly which takes you through the process and how to automate it.
Q: If I delete the fly.toml file, can I regenerate it easily?
The fly.toml file is the file which contains a Fly application’s configuration. This question was via HackerNews.
A: Sure. flyctl config save -a <appname> will retrieve the last used configuration and save it locally as fly.toml. If you want to save it with a different name, use -c for the config file name, flyctl config save -a <appname> -c <config.toml>.
Q: When using the Turboku adapter do you actually run my Heroku slug as a container on each edge?
This question (and the two following) came via Twitter.
A: Yes, we do run your Heroku slug as a container in one of our datacenters. We spin up instances as near as possible to where a request enters our edge network, which may be in the same region or geographically very close. We don’t put the actual slug at the edge though, to give us more flexibility in responding to load.
Q: Isn’t the DB connection latency insane, though, for pages with lots of queries?
A: You can choose the regions your app runs in to minimize database latency. We do this by default for Heroku/Turboku apps. You can do this for other apps too - for example if your database runs in datacenters in Virginia then - flyctl scale regions iad=1 will bring up the applications in the Virginia region or in regions close to it. You’ll still get benefits of SSL termination at the edge with restricted regions for the app.
Note: 13/05/20: The scaling commands have been updated since this article was published.
Q: Can I do only SSL termination?
A: Yes you can. Setting handlers=['tls'] in the fly.toml configuration file will let you TLS terminate at the edge; currently it supports up to HTTP 1.1 (so no HTTP2 support).
Q: What is Fly doing about global databases in general?
A: We’ve got Redis for local caching already and have a replication system to distribute changes for that in place. We have tested CockroachDB as a distributed drop-in replacement for PostgreSQL, but have found it not as easy to migrate from PostgreSQL as our users would have liked. That said, we’ve heard that CockroachDB is filling that compatibility gap and we’ll be looping round to it as soon as possible.
Q: Our application has a repository on GitHub. Is there a recommended way to continuously deploy our application to Fly?
A: You can use GitHub Actions to deploy straight to Fly. We’ve got a guide to it - Continuous Deployment with Fly and GitHub Actions - which takes you through the steps with an example application.
Q: Could you clarify if Fly automatically scales down to zero for completely idle apps?
This question via Twitter.
A: Sure can. We don’t scale to zero for completely idle apps, we keep one instance ticking over in a region on our default region model (close to the edge region where the app was created) so that its always there to respond to traffic quickly.
Scaling to zero on idle means an app can be very slow, cold-starting regularly, so we’ve gone for a single instance in a region model as our lowest scale point. The good thing is that the Anycast IP address and edge TLS termination still make this a faster option than other alternatives.
If you want to know more about Fly scaling, check out this recent Scaling blog post or delve into Fly’s scaling documentation for even more detail.