Ask HN: What's Your Experience of Fly.io? | Hacker News Reader

Ask HN: What's Your Experience of Fly.io?

47 pointsnabi_nafio40 comments

If you have used fly.io, what is your experience of the service?

I host my side project[0] on Fly.io using their "not for production use" LiteFS distributed SQLite database.

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.

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.

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.

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

[0] https://packagemap.co/

I find toml format so annoying, that it makes me doubt fly.io’s UX

That site loads instantly on my mobile device over wifi. Is that fly.io only or do you use other caching services?

Thanks for sharing your experience. Sounds like fly.io is good. One question: did you use your credit card to sign up or bought credits?

Not so good with databases, they even tell you: we aren't a managed database provider. So careful there.

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. https://community.fly.io/t/for-your-phoenix-app-how-did-you-... - other threads are similar, with some even saying "use cloudflare"?

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

---

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.

The way they manage domains is so obfuscated that it took me a whole day to figure out how to do it.

It’s almost as if they were intentionally avoiding writing a simple “how to set up your domain with Fly” tutorial on the docs.

And I say this as a somewhat happy Fly customer! I had some gripes with it, and now I don’t — they improve the service every month.

I don’t understand why they don’t try to make this amazing tech more accessible.

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.

I wrote about the experience here: https://onlineornot.com/on-moving-million-uptime-checks-onto...

Have you completely migrated off of AWS and running only on fly.io?

Btw congrats on the launch of onlineornot.

Thanks! It's been running almost two years now haha

Apart from RDS, and a few ad-hoc serverless tasks, yep.

Nice! All the best for the future of onlineornot.

Fly.io recommends an external DB provider. So it's not batteries included if you are looking at deploying to production

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

I wish they would spend more time making fly.toml more like render's monorepo support - https://render.com/docs/monorepo-support

Streaming SQLite is cool but as it stands for all my apps deploying on fly.io is very difficult.

They don't have a managed DB like a hosted Postgres?

No, they don’t. They recently added Fly Postgres but it’s fully managed.

> I wish they would spend more time making fly.toml more like render's monorepo support - https://render.com/docs/monorepo-support

fly.toml is for a single app, but there's nothing stopping you from having multiple fly.toml files in a repo.

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.

Personally, I am more worried that every service I want to try out wants me to do something like this

> curl -L https://fly.io/install.sh | sh

What is the problem with this? (Really asking to get an answer)

Whoever terminates this http request gets to run arbitrary code on my computer that I haven't read, in the context of my user

How does it differ from running any proprietary software other than that you can read the script before running it?

You can usually checksum anything you download to ensure it's legit. A script that you curl is unlikely to have such a thing I guess.

You can always read it first. It isn’t much different than pip or apt.

Easy to change the content depending on user agent.

So curl it but don’t pipe it into shell.

Isn’t that just the nature of installing software period?

I suppose perhaps you could read all code you use before installing it, but I expect the number of people who do that rounds down to zero.

If it's open source and in a certain language I always peek. Not necessarily for security but to see how they structured things.

It basically blindly trusts (and runs) whatever the website gives you. If the website is taken over or somebody messes with the dns, you'd end up executing the malicious payload.

If this was a standard package, like the ones you get from apt, brew, npm, maven, pypy, or even a versioned binary, you have the option of verifying the checksum, pinning the version, analyze the package with a SAST thing like snyk, or whatever you are using, etc.

Esp considering today's popularity of such attacks, more and more companies/teams are becoming more security-minded. Thus increases the desire for an installation process to be something more than just running a sh with full privileges.

You're trusting somebody to run random stuff on your machine and you're trusting them to not do something like this: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Just moved our app (tourcandy.com) from Heroku to fly.io. The experience was not great.

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

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.

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

On Fly, you provision virtual machines. That's a "Fly app". That's what you pay for.

What you do inside that VM is up to you. Fly doesn't really care if you've made a single dockerfile that starts up a web server, sidekiq, and redis - they'll just charge you for the virtual machine it's running on.

I have been using Fly.io for a few projects with Elixir and Phoenix (e.g. [0] )

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

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.

The reason I went with Fly.io was the following:

- It's pretty cheap (e.g. <5$ is free), I have been using it for a few months, and just hit the 5$ limit

- It's easy to migrate to a different service, if Fly gets expensive (again for my elixir / phoenix projects)

- The community support is great!

Some improvements Fly.io could make:

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

- Once in a while the something is down ([1])

- The billing is not very clear (e.g. split by projects could be useful, then instead getting an overall usage)

[0] https://ogtester.com/

[1] https://status.flyio.net/

Thanks for providing your experience in such detail. I have one question regarding their signup flow: did you use a credit card or bought credits?

I took it for a spin and got a Golang panic every time i tried to deploy a container.

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.

https://terrateam.io/blog/flying-away-from-aws

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.

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.

For new projects, I default to SQLite with Litestream. The only non-fly.io component I need is an S3 bucket.

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.

I find the pricing to be straightforward and fair.

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.

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.

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.

Load balancing, geo-replication, canary deployments, and Postgres instances/replicas "just work" out of the box.

Highly recommended!

Can you give some more background info?

I found out about fly.io years ago but never used it. I think it looks great, but it could be more simple.

Reply on news.ycombinator.com