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
[1] https://community.fly.io/t/application-vms-down-without-any-...
[2] https://community.fly.io/t/app-stuck-in-pending-state-after-...