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.

The “nothing new, devs always commit secrets” take misses the bit that makes this one nasty: the file isn’t a .env someone chose to commit, it’s an agent settings file that silently accumulates the exact commands you approved, secrets included, and then gets accidently committed with the project because it lives in the repo, so it ends up publically exposed. YSK that’s a different failure mode to a one-off .env leak.

If you use Claude Code (or any coding agent, tbh), the practical fix is boring but it works: rotate anything that was in that file — deleting the file from the repo doesn’t un-expose it, it’s already scraped — then check git history, because the secret is still in there unless you rewrite it. Add settings.local.json to .gitignore, run a secret scanner like gitleaks in pre-commit, and stop using ‘don’t ask again’ for commands that echo tokens or passwords. Also audit the approved-commands list now and then, and keep tokens scoped as tightly as you can so a leak like this is annoying rather than catastrophic. FYI, GitHub’s secret scanning will catch some of this after the fact, but it’s no substitute for not committing the file in the first place.

You don’t actually need Duplicati on her end at all, Duplicati can back up to a plain SFTP or WebDAV target, or S3, so her side just needs to recieve files. The simplest setup I’ve seen for a non-technical friend is SFTPGo in Docker over Tailscale, it has a web UI for managing a user and a folder, and nothing is exposed to the internet.

Keep the encryption on your side, Duplicati encrypts before upload, so she only ever sees encrypted blobs, and store the passphrase somewhere seperate from the backup itself. Set a quota if you can, agree on how much disk she is giving you, and test a restore to a spare folder once, a backup you haven’t restored is just a hope. FYI scheduled backups plus a monthly restore test is what actually saves you when a disk dies.

This is the exact trap with agents, they will use whatever privilege is lying around, they don’t stop and think ‘should I?’ like a person might. The docker group really is root, just with extra steps, so anyone in it can mount the host root fs and write to /etc.

What worked for me: run the agent as a seperate unprivileged user with no docker group at all, rootless Podman if you can, and give it a dedicated project dir only. Mounts read-only where possible, no host socket, no --privileged, and keep it off your real home dir and secrets. FYI I also log everything it runs and review the diff before anything gets applied, because the audit trail is the only way you notice it doing something sneaky after the fact. YMMV on tooling, but the principle stays the same, least privilege plus a sandbox you actually trust in your enviroment.

The June part is what stuck out to me. The device was replaced and credentials were changed, yet the attacker still knew the wallet team’s roles and came back in September through a second engineer. That definately suggests the first compromise should have been treated as exposed credentials, sessions and code access, not just a swapped laptop. YSK, for anyone in a similar job hunt, cloning a repo from an interview is the risky step here - do it in a separate throwaway machine or VM first, and don’t run anything from it untill you’ve checked who actually owns the repo. The internal AI tool angle makes logging matter too: if it can reach wallet systems, its actions need the same audit trail as a person. The October 20 and 29 dates show how long that access can sit quietly before it is used. Hope that helps.

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.