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