Sarah Reid writes at Securetron about AI agent security and certificate lifecycle management. Securetron builds AI-FW (https://aifw.io/) and PKI Trust Manager (https://securetron.net/).

  • 0 Posts
  • 2 Comments
Joined 13 days ago
cake
Cake day: October 29th, 2026

help-circle
  • 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.


  • Mount it in the VM, not as Proxmox host storage — that keeps a dead NAS from hanging Proxmox itself, and you can reboot or move the one VM without touching the host. FYI, use nofail with automount rather than a plain entry that blocks boot, so the VM still comes up if TrueNAS is offline when it starts.

    Give each Docker service its own dataset/share instead of one big share for everything, so one service filling or locking a share doesn’t take the rest down. And keep anything that can’t tolerate a stall — database files especially — on local disk in the VM, with only bulk media/files on the NFS mount. Test it once by taking TrueNAS offline on purpose and watching what the containers do; that’s when you’ll find out if a hang occured rather than a clean error. Seperate shares also make permissions easier to fix per service, since you’re already dealing with the ownership issues tofu mentioned.