My MAGI-inspired Homelab Setup
(IFYKYK) Bro has a supercomputer? Nah, just an exaggerated description of my homelab setup.
Introduction
Having used my Synology for quite a while, I eventually ran into its biggest limitation: performance. Replacing my DS120j outright didn’t really make sense—it would’ve been too expensive for what I actually needed. Instead of upgrading, I started looking for something that could complement it.
While browsing through homelab setups, I noticed something interesting: a lot of people treat their Synology boxes primarily as storage appliances, not all-in-one servers. That clicked. I didn’t need my NAS to do everything. I just needed it to do what it does best—store files. The heavier workloads could live somewhere else.
As a huge fan of Neon Genesis Evangelion, I naturally found inspiration in the MAGI supercomputer system. Three machines, each representing a different aspect of Dr. Naoko Akagi’s personality:
- Melchior-1 — As a scientist
- Balthasar-2 — As a mother
- Casper-3 — As a woman
Together, they handled the toughest decisions in the series.
Now, I obviously can’t build a personality-driven supercomputer of my own.
“I’m limited by the technology of my time.” - Howard Stark
And even if I could, I’d have absolutely no practical use for it.
But I could take inspiration from the structure. Not personas—but clearly defined roles and responsibilities. So I reimagined my homelab in a similar triad:
- Melchior-1: The Archivist — dedicated to storage and long-term preservation
- Balthasar-2: The Orchestrator — handling services, automation, and heavier workloads
- Casper-3: The Mediator — acting as the gateway and infrastructure layer of the network
Implementation
I originally had Melchior-1 running the majority of my services. It worked… until it didn’t. Once I started deploying more customized services via Docker, I quickly realized that I needed something more powerful. That’s when Balthasar-2 entered the picture as a complement.
At that point, there was no real need for a third node yet. But as I explored more homelabs, I inevitably fell down the networking rabbit hole—routers, OpenWRT, OPNsense, and everything in between. Casper-3 eventually found its place, although not in the way I initially planned.
Melchior-1
This server is where it all started—my true entry point into homelabbing. A Synology DS120j, relatively new when I got it back in 2023.
It primarily replaced cloud services for me—Google Photos, Google Drive, and essentially anything storage-related that I relied on daily. It wasn’t about being fancy. It was about control.
Today, it remains focused on what it does best: image backups, general storage, and long-term preservation.
Balthasar-2
Technically the third device I obtained, but the second one implemented in the MAGI structure.
To compensate for Melchior-1’s performance limitations, I went with a Minisforum UN150. Compared to the NAS, it’s significantly more capable. It runs primarily as a multimedia server (Plex and similar services), hosts my self-hosted API, and doubles as my Linux playground whenever I feel like experimenting.
Not all of its workloads are essential—some are purely for entertainment or curiosity. But that’s kind of the point. It gives me room to experiment without breaking the core storage node.
Casper-3
Ironically, the first device I obtained but the last to be properly implemented: a Raspberry Pi 4 (2GB).
I originally bought it to explore hardware tinkering after my Raspberry Pi Zero W died. The initial plan was ambitious—turn it into an OpenWRT router using a TP-Link UE300 USB-to-Ethernet adapter. But after diving into the configuration complexity (and questioning whether the hardware could handle everything I wanted to run), I scrapped the idea.
In its current form, it runs Raspberry Pi OS with Docker hosting:
- Pi-hole
- Tailscale
- A Wake-on-LAN application
It acts as a network-wide ad blocker and secure entry point for remote access. In the future, I plan for it to become the dedicated monitoring node for the entire MAGI network.
Usage
These nodes are part of my everyday routine.
Casper-3 is probably the most “invisible but essential” node. It blocks ads across the entire network and acts as the entry point for non-local devices. It also runs Icinga for monitoring.
As a complement to that monitoring setup, I knew a proper dashboard would tie everything together. So I built one—specifically designed for TRMNL (also self-hosted)—and integrated it directly with Icinga to give me a clean, at-a-glance view of the entire MAGI network.
Balthasar-2 is used less frequently, but since its power consumption is relatively negligible, it comfortably sits there as a media server and experimentation environment.
Melchior-1, on the other hand, is used almost daily—especially for image backups and general storage. It’s quiet, consistent, and reliable (well… mostly).
Plans
After experiencing an HDD failure on Melchior-1, I started thinking more seriously about disaster recovery.
At the moment, even with Melchior-1 in place, Balthasar-2 still relies on its local storage. That somewhat defeats the purpose of having a NAS in the first place—the storage isn’t truly unified. This setup is mostly the result of the earlier HDD failure on Melchior-1 for unknown reasons. To mitigate excessive reads and writes—and to reduce the risk of data loss—I migrated personal files and media to an alternative storage solution so that the data hosted on Melchior-1 remains reasonably safe.
Recently, I acquired another machine—an older i5-3470 system with a power draw of nearly 80W, which is honestly crazy. It’s currently running Proxmox VE, and I plan to use it primarily as a playground and disaster recovery environment. Proxmox lets me spin up almost any operating system as long as I have the ISOs, without interfering with the services running on the MAGI cluster.
With the addition of this node, I’m planning to name it after SEELE—which feels fitting, considering its role as an “organization” of LXCs, VMs, and containers. Its purpose, however, is very specific: it is not a 24/7 node.
The idea is simple:
When everything is healthy, it stays OFF.
When a node goes down, it powers ON.
That’s it.
It exists as a standby system—used periodically to perform backups, simulate failures, and test recovery procedures—but it does not run continuously alongside the rest of the cluster. Given its power draw, running it 24/7 would be unnecessary. It’s there for resilience, not routine workloads.
A quiet fallback. Waiting for failure—not attention.
Maybe soon, I’ll explore clustering in a more literal sense through Proxmox—or even begin experimenting with Kubernetes.
Why?
Honestly? Curiosity.
None of this is strictly necessary in a home environment. Cloud providers already offer convenient subscription-based backups. But I wanted to avoid recurring costs and have full control over my own infrastructure. That naturally pushed me toward self-hosting.
An unexpected bonus is how much it sharpened my technical skills. Most of my services are containerized with Docker—something I had little to no experience with before starting this. Coming from a primarily software engineering background, getting hands-on exposure to concepts overlapping with DevOps, cloud engineering, and networking has been both challenging and exciting.
More than anything, this project helped me figure out what I actually enjoy working on.
And for that alone, it was worth building.
