No, Meg isn’t the name of my daughter, or a household pet. meg is the name of a collection of servers that I self-host various services on. The name was inspired by listening to Mila Kunis talk about the character she plays on Family Guy, “Meg”. At the time I thought it would be funny to have this “home assistant” background character that people mostly don’t care about unless it does something wrong1.

Where I imagined myself building most of the stuff, it didn’t quite work out that way. Instead I ended up learning a lot about dns servers, web servers, reverse proxies, infrastructure as code and just generally devops/networking. As I write this there isn’t a single line of code I wrote running2 on meg. So let’s talk about what meg can do, and celebrate the various tools that made it possible!

nix + colmena

This is how I deploy to my infrastructure. NixOS is a declarative linux distribution. This means that you write configuration files that describe the whole system. You can see an example, my NixOS configuration is open source, and describes the system I am currently writing this post on. When I want to add a new package or change how a program on my computer works, I update these configuration files and then “rebuild” my system3.

This just happens to make it perfect for orchestration. Instead of layering complicated tools like docker and kubernetes on top of an OS, I can get a lot of the same benefits running on bare metal. That said, there are security benefits you get when using containers that NixOS hasn’t addressed yet.

colmena is a deployment tool for NixOS that is stateless. I used nixops for a long time, but it depends on writing a state file to your device for features such as rollbacks, etc. I sometimes split my work between different machines, so a stateless tool is more flexible and bulletproof for my use case.

sops

sops is an amazing tool that lets you encrypt secrets in a yaml file that can only be read if you have one of the gpg keys it was encrypted with. This means your secrets can be defined declaratively as well! There is a sops integration for nix that makes using this with NixOS systems easy.

wireguard + frp

As is pretty common I have a wireguard tunnel running between my various devices. Together with the fantastic reverse proxy that is frp, I am able to tunnel traffic through a small VPS server I pay for to the various services running on my internal network.

unbound

This was probably the most surprising to me. I hadn’t considered how useful a DNS server could be. I have unbound DNS servers running on the small VPS server, and on a raspberry pi in my internal network. My router points to this raspberry pi, and devices connected to wireguard connect to the DNS server running on the VPS server. This means at two levels I can override DNS responses. So if I’m in my internal network, a url might point at a device on my internal network, whereas if I’m out and about connected to my wireguard tunnel, that same url will point to the wireguard interface to the VPS server, and will be tunneled to the internal device. It works really well!

nginx

In front of every service I have running is an nginx server. This allows me to direct traffic in a consistent way depending on the hostname. So example.parasrah.com might go to one service, while test.parasrah.com could be directed to another. It also allows for things like TLS termination, to upgrade a connection to TLS even if the underlying service doesn’t support it.

FoundryVTT

FoundryVTT is just one of the services I run on meg, but I wanted to give a shout-out. It’s a virtual tabletop for playing tabletop games (think Dungeons and Dragons) online. Unlike most of the competitors, it’s a one-time cost, and you can even self-host it yourself. It’s overall just great consumer-friendly software that I’m happy to recommend. This isn’t sponsored content, I just like to recognize when companies don’t go the subscription route when it’s not necessary.

Future Plans

  1. Add a backup service
    • Plan to add a NAS (Network Attached Storage) device to the network
    • Will push regular backups using borg backup
  2. Create a p2p mesh using batman-adv
  3. Build an Elixir cluster on this mesh
    • This will allow for robust communication and fault tolerance between nodes
  4. Add camera’s (meg’s “eyes”)
    • Camera’s have always been a privacy nightmare for me. This way I can build privacy into the system from the start
  5. Build my own router

  1. Now years and many hours later, I have grown almost sentimental about meg, and this rings less true. ↩︎

  2. which isn’t to say I haven’t written any code. At time of writing meg is the result of ~1500 lines of nix, which is used to deploy the system across 3 servers. ↩︎

  3. It isn’t really building much. If you follow a stable channel most of the packages are fetched from a binary cache as opposed to building from scratch. Unlike most other package managers, nix will fall back to building the package if the binary cache is unavailable. ↩︎