I host my side project[0] on Fly.io using their "not for production use" LiteFS distributed SQLite database.<p>I'm currently still in the free-tier. But I'd be perfectly happy to pay for the product. It's super easy to use, and the happy path of the cli tool is well designed.<p>The various configs for the fly.toml file could be better documented, as could some of the more advanced cli commands like sftp and ssh into your machine.<p>I think fly really shines when you design your app intending to run it close to users. If you just want to host an app, there are other hosting products. But fly is particularly good at hosting and scaling into different regions and presenting those regions as a single app. Trying to do the same on AWS is messy.<p>It's also nice to see them investing in the database problems you get when trying to run at the edge. (Like the db being in one region, which defeats some of the value of running close to your users).<p>[0] <a href="https://packagemap.co/" rel="nofollow">https://packagemap.co/</a>
Not so good with databases, they even tell you: we aren't a managed database provider. So careful there.<p>Very difficult to set up basic domains for your apps. An attitude of "you solve it." It's been two weeks and nobody from their support has bothered to help me with this fundamental setting. <a href="https://community.fly.io/t/for-your-phoenix-app-how-did-you-configure-nonwww-and-www-domains-in-your-dns/9502">https://community.fly.io/t/for-your-phoenix-app-how-did-you-...</a> - other threads are similar, with some even saying "use cloudflare"?<p>_Too_ locked down. You can't just connect to your database from the internet. Should be an option, I don't really care about the security implications of it. Let me choose.<p>---<p>I've since moved my app to Render.com and it's been really great for me as an indie startup founder. I focus on my app and not the plumbing. Fly felt too much like plumbing.
Before fly, each additional user was costing me a non-trivial amount (I built an uptime monitoring service entirely on AWS Lambda). I managed to build a proof of concept in an afternoon and slowly move most of my architecture across in a week.<p>I wrote about the experience here: <a href="https://onlineornot.com/on-moving-million-uptime-checks-onto-fly-io" rel="nofollow">https://onlineornot.com/on-moving-million-uptime-checks-onto...</a>
Fly.io recommends an external DB provider. So it's not batteries included if you are looking at deploying to production<p>Also fly.toml seems to be designed for a single image/app from what i remember. What I mean is, I can't configure redis, background job worker, web worker using a single fly.toml<p>I wish they would spend more time making fly.toml more like render's monorepo support - <a href="https://render.com/docs/monorepo-support" rel="nofollow">https://render.com/docs/monorepo-support</a><p>Streaming SQLite is cool but as it stands for all my apps deploying on fly.io
is very difficult.
Great engineering team and content but I hate the fact that I have to use the cli to get things done, and there's no clear guide to deploy and scale a simple hello world nodejs app without wrapping my head around images, containers, etc. i know it's doable, but i did expect it to be more easy.
Just moved our app (tourcandy.com) from Heroku to fly.io. The experience was not great.<p>The product is far less mature than Heroku and the pricing is confusing. For example, it took us 3 days to figure out how to run Redis properly (their integrated UpStash Redis has quite a few bugs. We ended up going with self-host Redis on fly.io). Besides, we have no idea on how the pricing would work when fly.io shows our app as one app but there are actually 3 processes running (web, Sidekiq and Redis).<p>The good part is it's seems much cheaper. And because it has more edge nodes to choose from, it's also much faster in our case.
I have been using Fly.io for a few projects with Elixir and Phoenix (e.g. [0] )<p>The main advantage is, that I don't have to worry about hosting and the simplicity of deploying Phoenix applications (I don't know how well Fly.io works with other stacks).<p>The CLI is dead simple, and as with any other 3rd party services: if it works, you're in heaven - if doesn't you're in hell.<p>The reason I went with Fly.io was the following:<p>- It's pretty cheap (e.g. <5$ is free), I have been using it for a few months, and just hit the 5$ limit<p>- It's easy to migrate to a different service, if Fly gets expensive (again for my elixir / phoenix projects)<p>- The community support is great!<p>Some improvements Fly.io could make:<p>- I had an issue with blocked ports on my side and ended up wasting half a day to figure out why certain commands worked and others didn't. Again this is on my side. The error message could be better than saying: "Error tunnel unavailable: failed probing "personal": context deadline exceeded"<p>- Once in a while the something is down ([1])<p>- The billing is not very clear (e.g. split by projects could be useful, then instead getting an overall usage)<p>[0] <a href="https://ogtester.com/" rel="nofollow">https://ogtester.com/</a><p>[1] <a href="https://status.flyio.net/" rel="nofollow">https://status.flyio.net/</a>
I took it for a spin and got a Golang panic every time i tried to deploy a container.<p>Not a good impression of the service. I think some of their engineers are excellent and will check back again in a few years to see if it is stable.
We recently migrated from AWS to Fly.io. It is definitely different, more lean, but we have intentionally kept our stack simple so we are ok with that. We need a container and a PostgreSQL instance. And, for us, it's a lot cheaper than AWS. We wrote a blog post about the experience.<p><a href="https://terrateam.io/blog/flying-away-from-aws" rel="nofollow">https://terrateam.io/blog/flying-away-from-aws</a>
Maybe I did not use it as intended, but I have an app running on fly.io that exposed the metrics endpoint on another port as the webapp itself, so it is not publicly reachable.
This app suddenly broke and I had to disable the metrics endpoint to get it running again. Since it is a toy project, I didn't investigate further but internally everything worked fine (the healthcheck got the expected 200 response) but the routing of external requests just broke.<p>Also when building and deploying an image, some non-obvious and undocumented changes are made. My app generates version information based on the git repository state. The build process deletes (or ignores, I don't know, never got an answer to my issue) the fly.toml file in the docker build context, which resulted in uncommitted changes and a "dirty" repository when building the app. My dirty workaround is to `git checkout fly.toml` in my dockerfile. It works but it isn't pretty...
I started migrating my projects from Dokku to fly 4 months ago. It’s going great.<p>For new projects, I default to SQLite with Litestream. The only non-fly.io component I need is an S3 bucket.<p>The DX of the CLI and the config file are quiet good. Once an app is live with proper health checks, I find it quiet hard to take the app down by accident. They stage secret changes for instance.<p>I find the pricing to be straightforward and fair.<p>A week ago there was an issue with certificates, which they fixed in a few hours.
I created a repo for deployments alone, where I have directories for my different app fly.toml files and a script that deploys/updates them all.<p>Fly is great in a lot of ways, magic even, but there are blind spots and you have to learn new methods of keeping everything "in sync".
I use it for several personal projects (ex: Cyberfeed.io) and it costs me nothing because my spending is sub-$5. I really wish I could use it for work instead of ECS Fargate but it would be a nightmare cutting through the bureaucratic red tape. Maybe one day.<p>A lot of my projects are FastAPI/SQLite in a Docker container and Fly seems to complement this well.
Once set up it is fine. The setup felt a little more hands-on and idiosyncratic compared to Heroku or Scalingo. Moving a free tier app from Heroku to fly.io, I also noticed a few small details that Heroku had conveniently taken care of, e.g. installing only production dependencies by default.
I love fly.io! It has all the configurations you need without getting in your way.<p>Load balancing, geo-replication, canary deployments, and Postgres instances/replicas "just work" out of the box.<p>Highly recommended!