# Service dependencies

**URL:** <https://forums.balena.io/t/service-dependencies/373382>\
**Category:** Feature Requests\
**Tags:** balenaos, open\
**Created:** [July 3, 2023, 3:45pm UTC](https://forums.balena.io/t/service-dependencies/373382 "2023-07-03T15:45:20Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/balena/original/2X/6/60e5c11e1222480d38bea45d7ab9ea57bbe86d53.png) [@system](https://forums.balena.io/u/system)\
**Post date:** [July 3, 2023, 3:45pm UTC](https://forums.balena.io/t/service-dependencies/373382/1 "2023-07-03T15:45:20Z")

</div>

We’ve got a few services running on our devices that have dependencies between each other, most notably several services which need a local MQTT broker to be up before they can successfully start themselves.

Docker Compose supports dependencies between services, it would be great if that information could be used to block a service from starting until another service has passed a health check.

---

<div class="post-metadata">

**Author:** ![anonymizeduser](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/anonymizeduser/32/10188_2.png) [@anonymizeduser](https://forums.balena.io/u/anonymizeduser)\
**Post date:** [April 2, 2024, 7:43pm UTC](https://forums.balena.io/t/service-dependencies/373382/2 "2024-04-02T19:43:11Z")

</div>

I agree with this! Waiting for service-healthy would be super helpful as it causes a lot of errors on startup when one service is dependent of another.

---

<div class="post-metadata">

**Author:** ![anonymizeduser](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/anonymizeduser/32/10188_2.png) [@anonymizeduser](https://forums.balena.io/u/anonymizeduser)\
**Post date:** [May 27, 2024, 1:41pm UTC](https://forums.balena.io/t/service-dependencies/373382/3 "2024-05-27T13:41:54Z")

</div>

+1, I would honestly like to know why this feature wasn’t part of the default featureset. Seems like a no-brainer, especially since using systemd, you can get pretty complex and powerful service dependencies “for free”.

---

<div class="post-metadata">

**Author:** ![anonymizeduser](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/anonymizeduser/32/10188_2.png) [@anonymizeduser](https://forums.balena.io/u/anonymizeduser)\
**Post date:** [June 27, 2024, 1:15pm UTC](https://forums.balena.io/t/service-dependencies/373382/4 "2024-06-27T13:15:15Z")

</div>

I ran into a similar issue. We have an audio processing service that has to be running before our UI service that uses it to initiate some web streams/audio output. If the UI service starts first, it fails to create the audio streams and displays errors to the user. We can obviously work around this with error handling/retries/wait loops, but it would be nice if we could push this off to the service initialization layer (e.g. compose).

---

<div class="post-metadata">

**Author:** ![anonymizeduser](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/anonymizeduser/32/10188_2.png) [@anonymizeduser](https://forums.balena.io/u/anonymizeduser)\
**Post date:** [July 5, 2024, 8:09am UTC](https://forums.balena.io/t/service-dependencies/373382/5 "2024-07-05T08:09:58Z")

</div>

+1, currently using scripts to workaround, but would love to streamline our code to run on balena devices as well as it runs on other compose scenarios

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/balena/original/2X/6/60e5c11e1222480d38bea45d7ab9ea57bbe86d53.png) [@system](https://forums.balena.io/u/system)\
**Post date:** [December 23, 2024, 9:40pm UTC](https://forums.balena.io/t/service-dependencies/373382/6 "2024-12-23T21:40:21Z")

</div>

cywang117: This sounds like it falls under the umbrella of long syntax depends\_on as specified in the compose docs: [Services top-level elements | Docker Docs](https://docs.docker.com/reference/compose-file/services/#long-syntax-1)

We’ve specced this out and would like to push towards this as it will be useful internally as well.
