Stephen Barlow are there any plans for getting this to also work with services that use Docker?

This functionality is now available in early access! We call it the . Enable it from the Early Access section of your Account or Team Settings page.

After enabling, you can specify a service's pre-deploy command in the Render Dashboard alongside build and start commands.

You can set a pre-deploy command for paid web services, private services, and background workers. Note that while running, pre-deploy commands count toward your allotment of build minutes.

More on deploy steps: https://render.com/docs/deploys#deploy-steps

(Hate to be THAT commenter, but....)

...any chance y'all have a planned release date for this feature? Stoked that it's in progress and would love to plan around it. We're hoping to use this feature to automate migrations upon deploy and would prefer not to roll our own solution.

Sorry to bug - thanks in advance.

This is such an essential feature that would make the migration from Heroku much easier.

I'm currently running migrations as part of , but I can't have migrations run multiple times when having multiple instances (manually or with auto-scaling). I'm currently managing this with a hacky script, but it's far from ideal.

I know that I could alternatively call migrations in my Dockerfile, but that would apply them 1-2 minutes before the release is live, during which customers would get errors.

We are also looking forward to this. Since we use Docker and can't use a simple python environment, we're unable to cleanly run our database migrations for Django as part of the release cycle and the buildCommand. We are putting it in the docker build but it is less than ideal.

This is absolutely essential - we are speaking to support about the many issues this causes for complex apps. Would be fantastic to hear where this is in the pipeline

This is so essential for a complex application with interdependent services. Even simply opening up the ability to build locally and then ship containers all at once would still be a major improvement over the current options.

https://architecturenotes.co/12-factor-app-revisited/ -> another article which emphasises the need of the release phase.

Since our additional machine dependency requirements necessitate a Docker based setup, this is preventing our switch from Heroku as well.