Sarah Reid

The fallback part is the hardest bit of what you’re describing, because true active-active mail is a lot of work for one person. A simpler setup that gets you most of it:

• Run your main mail server at home like you planned, and put a second, identical one on a small cheap VPS as a warm standby. Point a second MX record at the VPS with a lower priority, so when your home server is unreachable, sending servers deliver there instead and the mail just waits for you.
• Sync the mailboxes between the two on a schedule (there are tools that do mailbox-to-mailbox sync over IMAP), or at least keep nightly backups of the mail data on the VPS so you can restore quickly. FYI, the standby doesn’t need to be perfect, it just needs to hold your mail untill you’re back.
• For certs, use DNS-based validation for the mail hostnames so both servers can hold valid certs for the same names without fighting over HTTP validation. That way TLS works whichever box is answering.
• Send outbound through a relay with SPF, DKIM and DMARC set up for your domain, rather than directly from your home IP, which keeps deliverability sane.
• And honestly, keep calendar and contacts on a seperate lightweight server, so a mail outage doesn’t take those down too. Mail servers retry delivery for days, so a short home outage rarely loses mail at all. The thing you’re really protecting against is a long one, and the standby MX covers that.

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.