On: Removal of Heroku free product plans

[mpd]

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.

[bradgessler → mpd]

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.

[jtmarmon → bradgessler]

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.

[mpd → bradgessler]

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.

[anurag → mpd]

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.