It’s nice to have a single roll up for all of the knobs — “what was the state of the environment” — to tag in things like crash logs.
(It’s also something we can’t easily tool ourselves.)
2) One click dashboard rollback button. Didn’t realize how much we missed this from Heroku.
3) Meta: Public roadmap and feature request tracker. Fly has a habit of surprising, usually pleasantly!, but it’d be nice to know how close or far off something on our wishlist is. (Render seems to do this well.)
CI runs on (almost) the exact same platform as production and we don't have to maintain any of it. When Heroku removes a package from their base image it gets removed from CI and we know if it broke anything.
The pricing model is the same as running our app. Which means if 10 people want to run 10 branches on CI at the same, and each CI run runs 32 nodes in parallel, and takes ~15 min, Heroku gives us 3200 nodes and we pay to run them for 15 minutes. No waiting, no upgrading to a different tier, etc...
I don't see many other people talking about Heroku CI, and Heroku doesn't seem to push it that much in their marketing, so either it's only really amazing for our use case or people just don't know about it yet.
For us it was a lot cheaper than other options when you consider how costly sitting around waiting for CI to start is.
Anyways that would be really hard to leave for another platform.
Here’s a sense of what that looks like: https://fly.io/docs/app-guides/continuous-deployment-with-gi...
This obviously doesn’t come close to the way Heroku does it and requires some effort. I have some ideas for fly CLI commands that would make setting up a basic CI a little easier, but again, not to the level Heroku is doing it.
- volume snapshot downloads (S3 or otherwise)
- built in log drain rather than needing to deploy fly-log-shipper
- customizable Prometheus alert rules. As is to get alerting using the fly-metrics.net “free” Prometheus we need to deploy a copy of Prometheus and federate scrape back, which seems like an anti pattern.
- review environments (eg PR scope deployments) would be ideal but I could see if that’s out of scope for Fly
Because yeah it sucks but Heroku is shutting down their free tier because of abuse so it's not a theoretical problem. Anyone who has even more lax requirements will get run over as well.
If you launch Fly from the CLI to test the free tier, you don't need a credit card. Obviously when you exceed the limits of the free tier, you'll need to provide a credit card.
Last time I tried fly.io I had to provide payment information before doing something useful. I'll give it another try as you suggested.
- After migrating my Heroku app to fly.io I also ran into an error that kept the app from booting: "Failed due to unhealthy allocations - no stable job version to auto revert". Its not clear what or how to diagnose this log error.
- I also tried to auth the cli and ran into an error that hangs all other applications requiring an internet connection on my MBP. I ended up hard restarting multiple times. The error is "Error Post 'https://api.fly.io/api/v1/cli_sessions': net/http: TLS handshake timeout"
Here's the rough bits of what Fly has:
1. There's a release command (https://fly.io/docs/reference/configuration/#run-one-off-com...) that runs after the container is built, but before its deployed. In Rails that's when a database migration would be run.
2. To run a task after the application is deployed, there's shell access. Here's what that looks like for running Rails tasks: https://fly.io/docs/rails/the-basics/run-tasks-and-consoles/
3. Pre-deployment/build commands can be run from the Dockerfile, like a Rails asset compilation. Here's a link to that https://github.com//superfly/flyctl/blob/master/scanner/temp...
I recognize that this is a lot for folks who aren't comfortable configuring stuff and want the "no-config ease" of Heroku, but it's at least possible on Fly.
As far as the after-deployment tasks go, we automate those just like migrations - they're (occasionally very slow) one-offs that we don't want to hold up a restart for. Really, an analogue to the release command that can run after restart is all that I'm talking about here.
Are there any plans to "upgrade" Turboku or release a similar tool that makes migrating Heroku Postgres databases to Fly just as easy?
1. A doc will appear at https://fly.io/docs/rails/ that walks through how to move over a Heroku app, including the database. I'm going to start drafting this next week since I have a few SaaS apps running on Heroku that I want to move over.
2. If the docs are complicated and have lots of steps, I'll look into automating most of this process. I don't think I'll be able to 100% migrate Heroku apps to Fly without any intervention, but I do think moving over the app code, ENV vars, and database would be a pretty big win.
I have authorized heroku access for fly.io page and yet no projects or applications appear in the last dropdown. Is there currently a known issue with this?
A small request: it would also be useful if `fly volumes snapshots list vol_123…` included the time they were taken, not just “n days ago”. If I’m having to rollback, it would be good to tell my team & users exactly when I’m rolling back to!
[1] https://community.fly.io/t/postgresql-database-backup-restor...
If somebody deploys a Java app to Fly, please consider documenting it at https://github.com/superfly/docs/tree/main/getting-started and we'll merge it into https://fly.io/docs/
