This hasn't even made the roadmap's "under review" in 5+ years, a bit disappointing given any workaround comes with ugly downsides – that can quite literally result in downtime.

For folks still waiting for this, you can kind of hack it with predeploy scripts. I have the predeploy script of downstream services poll on the deploy status of earlier services before exiting successfully and starting the deploy.

We are waiting for this as well, to coordinate our jobs server and web server. For a service like Render, trying to simplify server management for us programmer types, I think it would make a lot of sense to offer a dependency option of basically "the deploy doesn't complete until [these services] are all successfully built". Once the services are built, switch traffic over to the newly built services at once.

Providing simplified orchestration like this seems vital to what Render is trying to offer on the market. Hope you can add it soon!

Update: Render's CLI now supports a flag in the command, which waits for the deploy to finish and returns a non-zero exit code if it fails. See render.com/docs/cli for more info!

Similar use case here to those mentioned above.

I have a monorepo with a backend web service, and a frontend static site. Whenever there are breaking changes in the backend, I need the frontend and server to release simulataneously.

Currently the frontend compiles a lot faster, meaning there are always a few minutes where users will be using the latest frontend with a stale backend, which causes errors. Or worse, one of the two deployments fails and the whole app breaks until I'm able to manually rollback.

This is important to us as well. The most obvious use case in our app is pre-deploy database migrations.

We have different services hitting the database, deployed at the same time when we push code. This is great. However, there is an obvious issue if the one container that runs the migrations takes some time to do so, and so the other services come online beforehand. They would use a data model that isn't live just yet, and probably cause the app to fail.

This is why we cannot use an automatic deploy process as of now, and need to manage it manually.

Today I am thinking to use the main branch for the first service, and another branch for the dependent services, for simplicity.

A smarter way could be a "wait" script that checks migration state at deploy time in the dependent services, but this would requires some work and testing.

Happy to hear about a more convenient solution! (or an ETA :) )

Just come to say I also would love this to be available. I have a spring config server which if is not up, the rest of spring backend services I have, are not able to start. So, when I make a request to these BE and both have spinned off, it doesnt make sense to have the BE startup failing once and again until the config server starts, its just waste of resources. I would love to configure the dependencies between them to having working properly without wasting platform resources.

Just adding my 2c to this. I've got a v similar scenario as this (rails back end being built and an angular front end - which I'd like to deploy simultaneously).

The thing that I'd love is the ability to trigger a build separately from switching the traffic to the new build.

As far as I understand it, when Render deploys, it builds the updated service and then once it's fully built, it switches the traffic from the old service to the new service and before finally shutting down the old one.

I'd love to have API-access to those final steps so that I could allow all services to be built, confirm that's happened successfully and then switch traffic over to all services simultaneously.

Since this is planned, it would be very helpful to get an update on how far up it is on the TODO list. We need a solution for this soonish and implementing it ourselves into the build scripts would not only be flaky, but also superfluous once this feature has been rolled out. However, we can't migrate a few remaining things to Render unless there's a solution to this, so we'd really need a word in this matter.