{"id":21,"date":"2026-03-11T12:50:58","date_gmt":"2026-03-11T20:50:58","guid":{"rendered":"https:\/\/satchnet.io\/?p=21"},"modified":"2026-03-19T05:36:11","modified_gmt":"2026-03-19T13:36:11","slug":"the-day-i-decided-my-homelab-needed-therapy-a-notification-infrastructure-journey","status":"publish","type":"post","link":"https:\/\/satchnet.io\/?p=21","title":{"rendered":"The Day I Decided My Homelab Needed Therapy (A Notification Infrastructure Journey)"},"content":{"rendered":"\n

Or: How I Learned to Stop Worrying and Love SMTP<\/em><\/p>\n\n\n\n\n\n\n\n

The Problem Nobody Asked Me to Solve<\/h2>\n\n\n\n

So there I was, traveling for work, when I had a thought that would consume my entire evening: “My homelab notifications aren’t elegant<\/em> enough.”<\/p>\n\n\n\n

You know you’ve gone too deep into homelab territory when you start critiquing the aesthetics<\/em> of your alert delivery system. Most people get a text when their server is on fire. I apparently needed a philosophy<\/em>.<\/p>\n\n\n\n

I had Gotify. It worked. Proxmox and TrueNAS were happily shouting at it. But I’d discovered ntfy, and like a middle-aged man buying a sports car, I decided I needed to replace something that was working perfectly fine with something shinier.<\/p>\n\n\n\n

The Planning Phase (Airport WiFi Psychology)<\/h2>\n\n\n\n

While my coworkers were watching Netflix on the plane, I was sketching notification architecture diagrams in my notes app. This is what homelabbing does to you. You become the person who finds SMTP routing genuinely exciting<\/em>.<\/p>\n\n\n\n

“I’ll just add ntfy,” I thought. “Quick weekend project.”<\/p>\n\n\n\n

Narrator: It was not a quick weekend project.<\/em><\/p>\n\n\n\n

But then Claude (my AI buddy who I probably talk to more than my actual friends) asked the fatal question: “What about Apprise?”<\/p>\n\n\n\n

Oh no.<\/p>\n\n\n\n

Now we weren’t just replacing Gotify with ntfy. We were building a notification orchestration platform<\/em>. Because apparently, I’m the kind of person who needs enterprise-grade alerting for a homelab that primarily serves cat photos via Immich.<\/p>\n\n\n\n

The “While I’m At It” Cascade<\/h2>\n\n\n\n

You know that thing where you go to fix a light bulb and end up rewiring the entire house? Yeah.<\/p>\n\n\n\n

    \n
  • “I’ll deploy ntfy” became “I’ll deploy ntfy + Apprise + Mailrise”<\/li>\n\n\n\n
  • Which became “In a new dedicated LXC”<\/li>\n\n\n\n
  • Which became “With proper Docker Compose”<\/li>\n\n\n\n
  • Which became “And expose it securely to the internet”<\/li>\n\n\n\n
  • Which became “And migrate all my services”<\/li>\n\n\n\n
  • Which became checks watch<\/em> “…and there goes my entire evening”<\/li>\n<\/ul>\n\n\n\n

    The mission creep was real, folks.<\/p>\n\n\n\n

    The Great Memory Incident<\/h2>\n\n\n\n

    So I spun up the new Debian 13 LXC, gave it a whole 2GB of RAM (luxury!), and fired up the stack.<\/p>\n\n\n\n

    Everything started up beautifully. Containers running, logs looking good, and then…<\/p>\n\n\n\n

    ::LXC immediately maxes out CPU and RAM and becomes completely unresponsive::<\/em><\/p>\n\n\n\n

    Me, frantically checking Proxmox stats: “98.19% CPU, 99.97% RAM used… WHAT THE HELL IS APPRISE DOING?!”<\/p>\n\n\n\n

    For a brief, terrifying moment, I thought Apprise was mining Bitcoin or trying to achieve sentience. The LXC was so locked up I couldn’t even SSH in.<\/p>\n\n\n\n

    From the Proxmox host, I tried the graceful approach:<\/p>\n\n\n\n

    pct stop 125 --force\n<\/code><\/pre>\n\n\n\n
    Proxmox: “Unknown option: force”<\/p>\n\n\n\n
    Right. Because when would you ever need to force<\/em> stop a container? \/s<\/p>\n\n\n\n
    Eventually got it killed, doubled the resources (because throwing RAM at problems is the homelab way), and discovered… Apprise was using 3.3GB of memory on startup.<\/p>\n\n\n\n
    3.3 GIGABYTES. FOR A NOTIFICATION ROUTER.<\/strong><\/p>\n\n\n\n
    Turns out it was some weird startup anomaly. Restarted it, and Apprise settled down to a totally reasonable 2MB. But for a hot minute there, I thought my notification system was preparing to launch Skynet.<\/p>\n\n\n\n
    The SMTP Detective Story<\/h2>\n\n\n\n
    With the stack finally stable, I started testing. Sent a notification via Apprise to ntfy and… nothing.<\/p>\n\n\n\n
    Logs showed Apprise received it. Logs showed it sent to ntfy. But ntfy? Crickets.<\/p>\n\n\n\n
    Ten minutes of head-scratching later, I realized: I was testing against the internal IP but viewing the external domain in my browser. The notifications were going to the internal<\/em> ntfy, but I was watching the external<\/em> ntfy through NPM.<\/p>\n\n\n\n
    Facepalm.<\/em><\/p>\n\n\n\n
    Fixed the NPM config, refreshed the browser, and BOOM – there were all my test notifications, patiently waiting like dogs at the door.<\/p>\n\n\n\n
    The Mailrise Revelation<\/h2>\n\n\n\n
    Then came Mailrise testing. This was supposed to be the easy part. SMTP goes in, notifications come out. You can’t explain that.<\/p>\n\n\n\n
    Except Mailrise kept rejecting everything:<\/p>\n\n\n\n
    ERROR: Recipient is not configured: root@localhost\nERROR: Recipient is not configured: critical@mydomain.com\nERROR: Recipient is not configured: literally-anything@anywhere.com\n<\/code><\/pre>\n\n\n\n
    I had configured routing! I had a default<\/code> catch-all! What more did it want?!<\/p>\n\n\n\n
    Turns out Mailrise’s “default” isn’t actually a catch-all. It’s more like a “default suggestion that we’ll completely ignore.”<\/p>\n\n\n\n
    The fix? Just… explicitly configure every recipient email address. No wildcards, no clever routing, just good old-fashioned manual labor.<\/p>\n\n\n\n
    Once I figured that out, the beautiful moment arrived:<\/p>\n\n\n\n
    swaks --to notifications@mydomain.com --body \"Test from Mailrise SMTP\"\n<\/code><\/pre>\n\n\n\n
    And on my phone, 3,000 miles away from my homelab:<\/p>\n\n\n\n
    \ud83d\udcf1 ding<\/em> “Test from Mailrise SMTP”<\/p>\n\n\n\n
    Chef’s kiss.<\/em><\/p>\n\n\n\n
    The TrueNAS Plot Twist<\/h2>\n\n\n\n
    TrueNAS Scale has moved the email settings in Electric Eel (version 25.10), and apparently nobody at iXsystems thought to tell anyone where.<\/p>\n\n\n\n
    “Just go to System \u2192 Email,” they said.<\/p>\n\n\n\n
    There is no System \u2192 Email.<\/p>\n\n\n\n
    “Try Alert Settings!”<\/p>\n\n\n\n
    No email config there.<\/p>\n\n\n\n
    “General Settings?”<\/p>\n\n\n\n
    Getting warmer…<\/p>\n\n\n\n
    Turns out it’s hidden in a “Email Options” dialog that you access by clicking a button that’s in a place I would never<\/em> look first. It’s like iXsystems hired the same UX designer who did the Windows Control Panel.<\/p>\n\n\n\n
    But I found it, configured it, sent a test and…<\/p>\n\n\n\n
    ERROR: Recipient is not configured: myemail@gmail.com\n<\/code><\/pre>\n\n\n\n
    TrueNAS was sending test emails to MY personal email, not to the configured recipient. Because of course it was.<\/p>\n\n\n\n
    Had to override the recipient in Alert Settings, because TrueNAS apparently believes in a separation of church and state when it comes to email configuration.<\/p>\n\n\n\n
    The Mobile Moment<\/h2>\n\n\n\n
    After hours of debugging, configuring, and questioning my life choices, I installed the ntfy app on my phone.<\/p>\n\n\n\n
    Added my server: https:\/\/ntfy.mydomain.com<\/code> Entered my credentials. Subscribed to topics.<\/p>\n\n\n\n
    And there they were. All my test notifications. From hours of debugging. Staring at me like a digital graveyard of my evening.<\/p>\n\n\n\n
    But then I sent a fresh test from Proxmox and…<\/p>\n\n\n\n
    ::Phone buzzes in my hand::<\/em><\/p>\n\n\n\n
    IT WORKED.<\/strong><\/p>\n\n\n\n
    I was in a hotel room, 3,000 miles from my homelab, on cellular data, and my Proxmox cluster was notifying me in real-time.<\/p>\n\n\n\n
    I may have done a small victory dance. Don’t judge me.<\/p>\n\n\n\n
    The Scoreboard<\/h2>\n\n\n\n
    What I started with:<\/strong><\/p>\n\n\n\n