So it’s been a little while. A few things have happened–I’ve moved across the country to a new apartment, and just bought a house so I’ll be moving again soon. Those are posts for another time, and maybe we’ll be getting exciting home-related posts soon! For now, let’s get back to the homelab migration. I set up a new server and began the process of migrating before it got boxed up in the move, so let’s chat about that, shall we?

The New World Order

So let’s start with the new stack!

The server is, as expected, a brand-new M4 Mac Mini I’ve named Maomao, with the following specs (as copied from my order):

  • Apple M4 Pro chip with 14‑core CPU, 20‑core GPU, 16-core Neural Engine
  • 64GB unified memory
  • 10 Gigabit Ethernet
  • 4TB SSD storage
  • Three Thunderbolt 5 ports, HDMI port, two USB‑C ports, headphone jack

So by Mac Mini standards, pretty beefy! Not quite the highest-end model, but not far off. My needs by no means require this much power, but this gives me breathing room for future software and enhancements, hopefully letting me get another 10 years of life out of this thing.

The big bonus here is, as mentioned before, the change in power draw. Even including the drives, which we’ll talk about in a bit, it requires so much less power that it’s not even funny.

Is any of the old stack still running? Well, strictly speaking right now, no, everything’s in boxes. Even the new stack. But more accurately, one component has yet to be replaced–Nadeko, the Intel NUC running Airprint. I simply haven’t had the time to do that migration yet, which is mostly a physical problem. I couldn’t get the printer connected reasonably to the Mac at my old place, so hopefully once we move into this new home that will just happen automatically, but we’ll see. The new Mac is going to be going into the (finished) basement most likely, so I’m unsure if the printer will live down there with it or in an office. Future problems for future me!

And the VPS running my Mastodon instance? Well, you may have noticed that the Mastodon link on my profile page is gone. I’ve shut it down! I’m not quite completely done with it yet, I want to take a backup of its disk before deleting the VPS entirely. One service, my personal SSO, has moved from that VPS to another, smaller, cheaper one in a different provider that’s even further locked down then this one was. The only reason it lives in a VPS is because I use it to log into Tailscale, so I can’t exactly hide it behind a tailscale network. This very blog you’re reading now lives in Cloudflare, but that’s another post for another time!

So, what about those spinning disks?

A NAS By Any Other Name

This is what I was hemming and hawing on for an unreasonable amount of time, but I ultimately landed on buying the OWC Thunderbay 8 without any disks.

Pricy, but probably worth it in the end.

This little NAS-looking box is actually a DAS, Direct Attached Storage. It’s different from a NAS, Network Attached Storage, in a fairly obvious way: it’s not network-attached. The difference from a normal external hard drive is a little more subtle, but sort of obvious once you see it: it has multiple drives and does not communicate over USB, instead over a higher-bandwidth protocol (Thunderbolt 4 in this case).

There were no Thunderbolt 5 DAS systems on the market when I looked, but considering I’m using spinning disks that’s not really a problem.

What about my BTRFS RAID? I finally gave it up, after many many years. I happen to have a very large external drive that I was able to rsync the entirety of Chiyuki’s BTRFS to–I originally bought it for the purpose of local backups after all. I then took the drives that were installed in Chiyuki and installed them in the new DAS, then went ahead and wiped them all.

I ended up using SoftRAID to set up a RAID 5, the highest level that it supports, and copying all of the data back over. It works wonderfully and has built-in SMART monitoring, so I’m not super concerned. Overall, performance is acceptable and everything seems to be pretty reliable.

I would provide numbers and more data, but, well, they’re both in a box. I’ll need to run some tests to make sure the drives didn’t get too beat up on their trip from coast to coast, but they were well packed and should be fine. I hope.

So yeah, I’m using SoftRAID for monitoring instead of Scrutiny, what about the rest of the software?

A Soft Landing

This is where I’m still in the process of moving. Not all of my services have been migrated yet, and several are just getting cut from the move entirely as unneeded cruft.

The biggest things that have been moved one to one are Plex (and friends) and Homebridge. Those saw very little change, and were largely just a lift and shift to the new server, with some migration pains because I’ve dropped Kubernetes.

Traefik as my reverse proxy “front door” has been replaced with Caddy, which makes things super easy.

Pi-Hole has been replaced with Adguard Home, which is different and has some nice features, but ultimately serves the same purpose. This also means I can get rid of the ASUS Tinkerboard that was dedicated to Pi-Hole.

…And that’s it. Nothing else has been migrated. The real question, though, is “If no Kubernetes, how config and deploy?” The answer there is: by hand. Let me explain.

Nixing Nix

My first attempt at configuration was utilizing Nix for this, because it’s super popular lately and people seem to love it. I have determined that, at least on Darwin/MacOS, it is not anywhere close to being ready for the prime time. After fighting with it for about two weeks, I finally gave up and just started installing things manually.

To wit, I’m not really doing this entirely by hand. I’m utilizing a Brewfile which holds every package that I install, including things from the Mac App Store. If I ever need to rebuild, reinstalling software is as easy as brew bundle install.

Configuration is held in a single git repository alongside the Brewfile. It holds the config for things like Caddy, which are deployed via Docker. I’m using Docker for most, but not all, services, which makes things fairly easy.

Actually, I say I’m using Docker, but I might be using Podman? It’s been a few weeks and I actually can’t remember. I’ll update this post when I find my server in one of the many boxes and set it up again. Probably. Ultimately, the configuration is basically the same.

No config manager at all? Since I only have a single server now, it’s not really necessary. Adding the additional complexity is sometimes fun, but it’s not something that I really need to worry about right now. If things get to the point where I need to have all of my config defined in a single place, I will probably move back to Ansible or give OpenTofu a shot (on a local system? Wild). At this point, though, doing everything by hand is actually more efficient and less prone to failure due to the number of servers I’m deploying–I’m not Google, so I don’t need that much infrastructure.

So what’s left to solve?

More Questions Unanswered

I have part zero posted up in another tab, so let’s go over those bullets to find out what we’ll be talking about in part two.

  • I still have no way to run Linux VMs, but at this point I’m questioning if that’s something I still need to do. It’s a nice to have, but I can always just use Linode or DigitalOcean or something if I really need a VM, at least in the short term. Maybe I can figure out some way to get Proxmox working.
  • Kubernetes has been excised. It will not return.
  • I’ve ultimately decided on Forgejo to replace my Gitlab server after reading about various licensing kerfuffles and drama and whatnot around both it and the Gitea projects. That still needs to be done, and is my next major target for migration.
  • Forgejo has Forgejo Actions, which is similar to GitHub Actions. I still haven’t decided if that or Woodpecker is the way to go, but I’ll probably start with Forgejo Actions for simplicity.
  • I’m using containers now, so…that’s set. This is sort of through the Mac itself, but ultimately all implementations of basic containers on Mac spin up a small VM under the hood.
  • As mentioned above, I decided to drop the config management thing entirely. After thinking about it, the overhead is just not worth it, at least for now.
  • I still haven’t worked out how to do backups. My current working assumption is Restic to something off-site like B2 or maybe just BackBlaze with their own backup tool.

So I guess my plan ultimately ended up being, “Let’s wing it.” And hey, it worked out for me! The next post in this series will probably explore Forgejo and setting up that, as well as some further explanation on parts of the stack that I, kinda, uh, forgot about while they’re in boxes.

The next post, though, is more likely to be about Obsidian, the blog migration, or my move. Only time (and my own motivation) will tell!