Please let me know in the replies what you'd like to see at Fly that would make it as good, if not better, than Heroku. I recently started working at Fly to focus on making Rails & Ruby app deployments awesome, and of course Heroku set that benchmark almost a decade ago. I can't promise I'll get to everything, but I can promise that it will help me better prioritize what I should be focusing on to make Fly better for ya'll.

1) We would love an equivalent to the HEROKU_RELEASE runtime variable: A strictly increasing int that is incremented with any change to the environment (deploys or env/secrets).

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

These are all really great ideas. I don't have any specific replies to each, but I can say I'll check around internally to see what it would take to ship some of these.

We spend more on Heroku CI than we do running our app on Heroku and it's well worth it.

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.

Yeah that sounds like an awesome CI! Fly won’t ship anything that integrated anytime soon because there’s so much great CIs out there now. What you will see is Fly integrating into CIs for deployment steps, which could be to a staging env per branch or a final deploy to production.

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.

I recently migrated a few systems to Fly

- 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

On the top of my list is being able to use a local repository and providing no credit card.

CC’s are an abuse prevention tool and essentially a proxy for real names since lots of companies ban “privacy” cards. Would you be willing to instead turn other proof like a government id with face recognition to auth it?

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.

While I do understand the trouble, having a way to try the product without revealing my identity makes it `as good` as Heroku.

By local repo, do you mean like how Heroku's `git push heroku` works? Or do you mean you want to deploy from your local machine's repo? The `fly deploy` command is a local deployment in the sense that it copies the files of your application and deploys it to the server, regardless if you have git or not.

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.

With `local repository` I meant not involving a thirdparty like Github or Gitlab which is a requirement for some Heroku-like providers. `git push heroku` is very nice to have - for me it would be enough to not having to leave the terminal as it seems to be the case.

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.

Got it! There's no plans to implement git repos in the same way Heroku is doing it (FWIW I love how Heroku does this). When Heroku introduced this feature, cloud CI services were practically non-existent. Today a similar effect can be achieved in Github, Gitlab, etc. with their CI integrations (See https://fly.io/docs/app-guides/continuous-deployment-with-gi... for Github)

I realize that's what you're trying to avoid. In your case I'd recommend running `fly deploy` from your CLI If you don't want to leave the CLI. You could wire this up as a git hook either on your workstation or third-party git server. I recognize this isn't the same thing as Heroku, so I'm calling these work arounds :-)

+1

Fully managed PostgreSQL service, with point in time recovery like in Heroku + ability to take manual snapshots if needed. Daily snapshots are not flexible enough.

Give us a look at Crunchy Data, suspect we'll check most of the boxes on the Postgres side.

Having a horrendous time moving from Heroku to fly.io...

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

The main drawback I saw compared to Heroku is no longer a drawback now that Heroku will have no free plans. But Fly's 256M free apps just OOM-ed for a hobby project whereas they ran fine with Heroku's 512M free dynos so I moved there.

My big want here is containerized deployments with build + release steps to allow me to e.g. run migrations and after-deploy tasks (we use both). This prevented a move to Render for us previously.

Could you go into one more level of detail about your app? I think this will help me better understand content for some documentation.

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.

To double tap the sibling's replies here - I'm a fly user and found it challenging to locate the release_command docs. Highlighting these in the docs somehow would be a good idea since I think _most_ apps will need something like this.

Oh, it looks like the release command would fit the `build` step I mention.

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.

We're going to start working on a release phase at Render in the next month. Stay tuned! We'll also update feedback.render.com.

I have a production rails app that I've been thinking of migrating to Fly from Heroku. After reading the Turboku[0] docs, it seems that the process only migrates the rails app itself, and continues to connect to the Postgres database on Heroku. Is that right?

Are there any plans to "upgrade" Turboku or release a similar tool that makes migrating Heroku Postgres databases to Fly just as easy?

You're correct! The tool stops short of migrating the database from Heroku to Fly. I'm actually going to start working on this soon. Here's what that will look like:

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'm looking forward to this! It'll make moving from Heroku a lot easier. The other thing I'm looking for is a way to put a hard cap on spend so it doesn't feel risky to enter my credit card.

Hey, thanks for your warm outreach and help! I'm trying to use the https://fly.io/launch/heroku page to migrate my heroku application. I am already a paying customer for heroku, but I want to switch based on their direction.

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?

I can’t provide support here, but I can say next week I’m going to be cracking open the source code in that project to look into issues like this and figure out it I can’t get it to also move over the database.

If you post about this at https://community.fly.io/ others in the same boat as you and other folks from Fly will see this and give you a better response.

Thanks for your quick response! I was able to work around the broken Turboku form and also get my database migrated to fly.io with a bit of adjustment period with flyctl. Just closed out my last invoice with Heroku and closed my account!

Alrighty, I wrote some docs! https://fly.io/docs/rails/getting-started/migrate-from-herok...

That includes a section on migrating your Heroku DB :-)

That’s great to hear! Thanks for the reply.

In addition to a built in log drain, my other FR would be better tooling for specifically build and deployment logs. When upgrades or remote builds fail, I've found finding the logs for either of these to be a bit of a challenge. Heroku has that nice deployment logs interface that I'd love to see in fly.

managed postgres

Heroku's pg is ridiculously good. I recently wrote a document that demonstrates what Fly's pg is capable of at https://fly.io/docs/rails/the-basics/backup-and-restoring-da.... It obviously not nearly as extensive as Heroku's pg offering, but for some people its enough—for others not so much.

It seems like managed pg improvements aren’t high up on the priority list (there’s a mention of outsourcing it to a third-party like supabase[1]), so I’d just like to +1 this request — for personal projects the snapshots are fine, but I’m starting a new role where I wanted to use fly but without easier backup/restore it’s likely a non-starter.

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

Second this — Heroku pg is the main reason I've stayed with them, paying $$$/month to host my service. If Fly (or Render) can match the seamlessness of that experience, that'll be where I host next.

Would it be OK if service like https://www.crunchydata.com was integrated with Fly?

We're definitely thinking about a deeper integration here. As it stands you can absolutely connect a Crunchy Bridge instance to fly and we have folks that do just that, and it works for them.

Adaptable.io just launched managed Postgres, included in the free tier

I really like the build-in statistics provided by Heroku. It is the main reason for staying with them. The statistics are basic but clear enough to keep an eye on an application (my apps are mainly in golang).

The most used features are probably direct deployments from github or a direct connection to personal github repository in web gui. Variables and secrect should be changable in web gui.

Better Frontend UI. I feel like everything is CLI

A Java/JVM stack.

This is an unsatisfactory answer, but Fly does run Java/JVM apps via Dockerfiles. The best docs we have for it at the moment are at https://fly.io/docs/getting-started/dockerfile/, but its clearly not written for folks who want to deploy Java apps.

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/

Fly was the subject of a front-page story a few months ago: https://news.ycombinator.com/item?id=31390506

IME, Fly does not have as good a developer experience than Heroku does. I've tried several of their guides but run into hiccups each time. The web admin UI isn't very useful - almost looks like a simple wrapper around Nomad.

I haven't used Heroku's free product plan myself, but I personally use Fly for my personal blog and website and thoroughly enjoy its pain free deployment process. They also have built in secrets management which I was happy to see. There is GitHub Actions for automating things too.

They supposedly also decrease latency for your application if you migrate your Heroku app there (again, I haven't used this myself so YMMV): https://fly.io/launch/heroku

You do need to enter credit card information as mentioned in this thread.

Thanks for bringing this to my attention. I run an instance of https://www.monicahq.com on Heroku, which I use about once a week. Transferring it to fly.io was a breeze and I'll happily pay the $0.02 per GB of outbound data transfer (which I'll probably anyways never reach) instead of the 7$/month on Heroku.

I just tried it. Apparently, unlike heroku free tier, you need to add payment information on fly.io in order to use their free tier.

Given that Heroku is killing their free tier because of "fraud and abuse" I'm pretty ok with Fly requiring a CC for their free tier. Requiring a legit CC has to cut that by a substantial amount, I'd think.

Yes, this. We (Fly.io) get a lot of abuse from users with stolen credit cards, too. But credit cards are the most useful anti-fraud tool we have.

When we've relaxed the credit card restriction (like on https://fly.io/launch/livebook), it gets "exploited" within about 48 hours.

This sucks and we hate compromising the experience for legit users. We _want_ people to run their side projects on Fly.io without paying us money. The credit card gate makes this happen less.

Are you using Stripe's fraud protection, MaxMind's tools, or something else to detect card fraud?

Stripe for CC fraud. That part of Stripe has been great.

They have crazy low bandwidth limits though... puts me off quite a bit

Is it possible to import the app from Heroku (like in the top link) and then detach it and deploy directly from command line to Fly?