3 ms·

I've migrated several services from GCP to Fly.io, and I've been very happy with Fly. All of my apps are low-volume hobbyist web apps that run on a single mach

I've migrated several services from GCP to Fly.io, and I've been very happy with Fly. All of my apps are low-volume hobbyist web apps that run on a single machine, so I don't do any Terraform, k8s, or Postgres, so my use case is a little simpler than OP. My biggest complaint has been with outages,[0, 1, 2] but that's gotten better. The original architecture meant that larger servers could evict other users' running servers, which they admitted was a bad idea.[2] I'm not sure if they've fixed that since, but I haven't seen it happen in a few months. >The container logging solution provided by Fly.io is basic. It's easy to view logs with the Fly.io CLI and via the Fly.io dashboard. However, there's only a small window of logs that are kept, forcing you to create a remote logging solution either internal to your application or via a separate Fly.io application that ships logs to an external service. This is a piece of operational overhead that I'd like to see removed. I very much agree. This is a big feature gap I feel when using Fly as well. >Fly.io is not a support-first company. If this bothers you, then Fly.io is probably not for you. >When emailing support, and email is the only option, it can take from hours to days to get a response. Sometimes they don't follow up. It does not feel like their level of support is on par with other cloud providers. This hasn't been my experience. I go through the forum rather than email, but I typically see responses within hours, even on the weekends. By contrast, when I reported bugs to GCP through their designated support channels, there was multi-day latency, and they'd just keep dismissing my report.[3] [0] https://community.fly.io/t/cant-deploy-my-app-in-iad/7746 https://community.fly.io/t/cant-deploy-my-app-in-iad/7746 [1] https://community.fly.io/t/application-vms-down-without-any-change-cant-deploy/7618/11?u=mtlynch https://community.fly.io/t/application-vms-down-without-any-... [2] https://community.fly.io/t/app-stuck-in-pending-state-after-restarts-rescaling/5972/6?u=mtlynch https://community.fly.io/t/app-stuck-in-pending-state-after-... [3] https://stackoverflow.com/q/53410165/90388 https://stackoverflow.com/q/53410165/90388

mrkurt 4y ago
You probably had a different community experience than recent folks. We've grown like 4x in the last 3 months and haven't kept up with community as well as I'd like (because hiring). And over holidays, we've had a difficult time with email support as well. It'll get better, but it's not great right now!
- sausagefeet 4y ago
  It's a breath of fresh air to see honesty about the good and bad from those at the company. Thank you for the transparency, I really appreciate it.
garganzol 4y ago
To avoid outages, just scale up the number of app instances to like 2 or 3 and choose a diverse geography for them. Outages is not something specific to Fly. For example, if you have an app on Azure and it has only one instance then... well, you asked for it to go down from time to time. Maybe not a big deal for hobby projects, but for business critical stuff one should always consider deploying several instances of the same app when possible.
- mtlynch 4y ago
  Yeah, but going from 1 to N instances is a big jump in complexity for not much more uptime. I'd rather have a host that can do around three nines and just accept that as my upper bound.
  - garganzol 4y ago
    The key moment is not to have any persistent state in the app. App may use a database, that's ok, but the app itself should not store any persistent state on a hard drive. Once that simple requirement is met, the scaling becomes easy.
    - mtlynch 4y ago
      Right, but keeping a database externally adds a lot of complexity. My apps are self-contained in a single Docker container. Just Go, SQLite, and Litestream: https://mtlynch.io/litestream/ https://mtlynch.io/litestream/

mrkurt 4y ago

You probably had a different community experience than recent folks. We've grown like 4x in the last 3 months and haven't kept up with community as well as I'd like (because hiring). And over holidays, we've had a difficult time with email support as well. It'll get better, but it's not great right now!

sausagefeet 4y ago
It's a breath of fresh air to see honesty about the good and bad from those at the company. Thank you for the transparency, I really appreciate it.

garganzol 4y ago

To avoid outages, just scale up the number of app instances to like 2 or 3 and choose a diverse geography for them. Outages is not something specific to Fly. For example, if you have an app on Azure and it has only one instance then... well, you asked for it to go down from time to time. Maybe not a big deal for hobby projects, but for business critical stuff one should always consider deploying several instances of the same app when possible.

mtlynch 4y ago
Yeah, but going from 1 to N instances is a big jump in complexity for not much more uptime. I'd rather have a host that can do around three nines and just accept that as my upper bound.
- garganzol 4y ago
  The key moment is not to have any persistent state in the app. App may use a database, that's ok, but the app itself should not store any persistent state on a hard drive. Once that simple requirement is met, the scaling becomes easy.
  - mtlynch 4y ago
    Right, but keeping a database externally adds a lot of complexity. My apps are self-contained in a single Docker container. Just Go, SQLite, and Litestream: https://mtlynch.io/litestream/ https://mtlynch.io/litestream/