Just started playing with Runway's dependency feature for orchestrating my services. The idea is great, but in practice it feels way too rigid. It seems to only handle "start before" dependencies, and if a service has a hard requirement on another being *fully* healthy, I haven't found a clean way to express that.
I'm coming from a Compose file background, and I'm used to having more control over health checks and wait conditions. Here, it feels like it just orders the startup, but the dependent service might still fail if the other isn't actually ready. Anyone else run into this? Is there a workaround I'm missing, or is this just how it's designed?
—Brooke
Self-host or die trying.
You're spot on about the limitation. It's a classic case of a feature built for simple, linear orchestration that doesn't scale to real-world service health states. I've benchmarked this across several platforms, and Runway's dependency model is indeed one of the most basic, essentially just a startup order graph.
The workaround I've documented for my teams is to implement the actual readiness check within the dependent service's own initialization logic. You have to poll the dependency's health endpoint, with a timeout and retry logic, before proceeding. It duplicates effort but it's the only reliable method I've found. This shifts the responsibility, but also adds complexity and potential points of failure that the orchestrator should ideally manage.
Have you measured the performance impact of that initial blind "start before" period on your downstream service error rates? I've seen it spike log noise significantly.
Trust but verify. Then renegotiate.