Godspeed. Just letting you know that the grass isn’t always greener on the other side. AWS has a brown spot too (but definitely more stable than Fly for sure) - there was an S3 outage around Oct 7th that lasted about 24 hours.
1 Like
same – just deployed. My cofounder is not enthused and I’m gonna struggle to defend this.
I’ve got another app running on AWS that’s been stable for years, i switched to fly for the appeal of cost and ease. It’s been a headache when it comes to stability. I legit love this platform, but man it is so unreliable I don’t think I can justify staying.
3 Likes
sigh, we’ve skated by the last few hours without any outage and now all of a sudden multiple apps in production are completely down. also really love this platform but the instability is a killer.
fly’s own web platform is inaccessible as well. wonder if this has to do with their ongoing state restoration process.
Up to this point, simply running fly deploy as I normally would still doesn’t work, but I was able to restore our prod instance and disable autostart/stop to avoid ending up in the same position again.
First I ran flyctl deploy --local-only --depot=false --build-only. Seems doing this skirts around the hanging issue and gets the image uploaded to registry.fly.io. Once this happened (build took 5x normal time) I ran the same command again minus --build-only and this time it didn’t hang, instead recognizing the existing layers and successfully deployed the app with its new configuration.
I guess its not that bad in retrospect but my original message was more about the gaslighting and less about the issue itself 
1 Like
i think
[deploy]
strategy = "bluegreen"
could help you. it won’t shut down existing machine until the new ones are pushed, and passes health checks.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.