Afaik you don’t need the depends_on at all, it’s basically implied. If you configure the container to use gluetun’s network, it shouldn’t just bypass it even if there’s any problem with the gluetun container. The gluetun documentation also says to just use network_mode: container:gluetun, even when connecting from a divergent compose.yaml. if you want to be sure, maybe test out what happens if that gluetun is down.

You can’t use dependencies cross-stack.

If you know the IP that the gluetun interface is supposed to have you tell the BT client to use that interface as output interface. Usually BT clients have this option, other apps might not.

Another thing you can do is wrap the client in a script that waits for the interface to be up (respond to ping) before it moves one. Something like (in sh):

while ! ping -c 1 -q -W 1 "$IP" &>/dev/null ; do
    echo "Waiting for ${IP} to come up..."
    sleep 5
done
# run BT client here

Alternatively if the gluetun interface itself doesn’t respond to ping, you can ping something else (like 1.1.1.1) through the interface, and use the -I ${IP} option for ping to bind to it for output.

Yeah, depends_on only works inside a single compose file/project, so it can’t see gluetun from stack 2 — that’s why you’re getting the undefined error. There’s no built-in cross-stack depends_on, unfortunately.

The cleanest fix IMO is to merge them into one compose file if you can, then depends_on with service_healthy works for everything. If you really want to keep them seperate, a couple of options:

• Start stack 1 first, then have a small wait script before stack 2, something like looping on docker inspect until gluetun’s health status is healthy, then docker compose -f stack2.yml up -d. A bit clunky, but it works and it’s explicit.
• Or use a systemd unit or a wrapper script that runs the two up commands in order, with the wait in between.
• What I wouldn’t do is just add a fixed sleep — gluetun can take a while to bring the tunnel up, and a sleep that works today will bite you on a slow day.

One caveat too: service_healthy only means the container is healthy, not neccessarily that the VPN tunnel itself is fully up, so it’s still worth checking the torrent client actually has the VPN IP before you trust it. FYI, you can test that from inside the client container with curl to an IP checker.

deleted by creator