From 8995493730882b98a84e6d238219328f12c0b0a2 Mon Sep 17 00:00:00 2001 From: Aner Zakobar Date: Tue, 12 May 2026 23:44:54 +0300 Subject: [PATCH] Wrote blog entry further. --- ...-08-nix-selfhosting-in-the-age-of-llms.org | 29 ++++++++++++++----- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/content/blog/2025-05-08-nix-selfhosting-in-the-age-of-llms.org b/content/blog/2025-05-08-nix-selfhosting-in-the-age-of-llms.org index 1c3c2b1..5cec9d5 100644 --- a/content/blog/2025-05-08-nix-selfhosting-in-the-age-of-llms.org +++ b/content/blog/2025-05-08-nix-selfhosting-in-the-age-of-llms.org @@ -3,9 +3,9 @@ * My usecase -I recently had to redo my homelab hosting suite. I run everything off a Raspberry Pi 4 8GB, and lately, it has been hardly chugging along. I don't know if it was system rot or just a buildup of dust, but my home run services were becoming a bit slow. I wanted to run maintenence on it, but I was sort of afraid to touch anything from what I built. +I recently had to redo my homelab. Homelab might be a very strong word for what is just a Raspberry Pi 4 8GB hooked up to a 2TB storage drive. Regardless, lately it has been slugging along at unacceptable speeds. I don't know if it was system rot or just a buildup of dust, but my home run services were becoming slow. I wanted to run maintenence on it, but I was sort of afraid to touch anything from what I built. -I based all my work on Helm charts to be deployed on Kubernetes (k3s to be exact). I reasoned it was the cutting edge way to do so with high security, and that Helm made everything declarative. At least, so I thought. Yes, it is already better than deploying everything straight from chart files, this much is certain. However, the system would still get stuck mid-deployment, previous configuration options wouldn't always go away, services needed to be manually deleted. It always felt like a great beast I was trying to wrestle into submission, which is not how I want to feel about a service backing up pictures of my children. +I based all my work on Helm charts to be deployed on Kubernetes (k3s to be exact). I reasoned it was the cutting edge way to self-host, it was highly secure, and that Helm made everything declarative. In the end I found it unwieldy, and the Helm charts weren't as declarative and pure as I would have hoped. The system would still get stuck mid-deployment, previous configuration options wouldn't always go away, services needed to be manually deleted... It always felt like a great beast I was trying to wrestle into submission, which is not how I want to feel about a service backing up pictures of my children. * Starting the migration @@ -16,9 +16,9 @@ It was time for a change. I wanted to restart my homelab and make it something v * Quick success story -I started to make a migration plan - I wanted to keep relevant data from my old homelab and migrate it into my new. Within a day I had backups ready to be ported. Within two more days I had my initial services running, with some bugs. Took another day to iron it all out (keep in mind, my time spent working on this project was 10PM to 11PM only, so I was making very quick progress). +I started to make a migration plan - I wanted to keep relevant data from my old homelab and migrate it into my new setup. Within a day I had backups ready to be ported. Within two more days I had my initial services running, albeit with some bugs. It took another day to iron it all out (keep in mind, my time spent working on this project was 10PM to 11PM only, I consider this quick progress). -Sure enough it all worked, backing up all my files and running my little suite of automations. It was working faster than ever before, and I felt more in control than ever, even though I delegated 50% of the coding work to a machine. +Sure enough, it all worked! I backed up all my files and ran my little suite of automations within a few days! It was working faster than ever before, and I felt more in control than ever, even though I delegated 50% of the coding work to a machine. I attribute this to the fact that, since everything was strictly declarative, I could always tear it all down and rebuild it exactly the way I want very easily. * Why NIX is so good, even on its own @@ -30,7 +30,7 @@ The state of my homelab is set directly from my project. With the exception of s Something I find myself doing for every one of my Nix projects is declaring a development shell with special commands for tooling. Every time I encounter myself writing long commands to do specific tasks (checking state of backups remotely, remote build and deploy, running commands inside podman hosted services), I just write a custom command that gets loaded into the shell. -In the previous version, this was accomplished by writing a bunch of bash files. This does work and acheives the same thing, but this feels more approachable, and the commands feel more accessible. I find myself using this tool much more within the NIX ecosystem. +In the previous version, this was accomplished by writing a bunch of bash files. This does work and acheives the same basic principle, but this feels more approachable, and the commands feel more accessible. I find myself using this tool much more within the NIX ecosystem. * The extra benefit of the LLM @@ -38,9 +38,22 @@ Of course using an agentic coding agent helps with selfhosted and automating tas For starters, the fact that it is fully declarative means the LLM has direct access to information about the state of the homelab. It doesn't have to hunt around and search for active processes - it knows the file layout and can infer immediately which services are running and how they are configured. Compare this to bloating your context by first reading a bunch of YAML files in the repo and then running a bunch fo commands to make sure everything exists in the repo and making sure it matches the YAML. -For the rest, it has ready access to custom tools and commands that are useful for debugging and commanding the system. I create them because they are useful to me, and they are sure useful for the LLM as well. +An additional benefit came along with all the custom commands I created for myself - turns out if they're useful for me, they're useful for the LLM! This allows it to perform routine tasks repeatably and correctly, instead of guessing what the best way to do so is. Checking on statuses of backups, for example, can be done in a few ways, but since I already have a command that checks all the relevant services and returns the information together, the LLM doesn't have to guess how to check for my backups - it does so first try every time. -* How this looks in practice +* Words of caution -I dunno check later +Of course LLMs did not solve all my woes. Worse, they introduced new ones. +When setting up the new homelab Claude decided to be pretty lax on security. Network isolation wasn't that important so it could just skip it, file permissions were a bit of a pain to deal with, so why bother... You get the picture. + +Needless to say this was not cutting it. Once I realized this was going on, addressing it with the help of Claude was easy, but I had to first see this issues myself. Even with LLMs there is no replacement for understanding the code you have. + +Another thing is the actual design of the repo itself and how it is organized. Claude can easily spaghettify a codebase if not kept in check. A disorganized codebase makes it harder for Claude itself to work, but more importantly, it makes it harder for me to understand the code I am using, which makes it harder to control Claude. It was critical for me to babysit Claude and give sensible repo design guidance so my code would be kept in check. Just because you're using AI doesn't mean you should let it make messy code. + +Even with these gripes - using an LLM saved me loads of time and allowed me to make this migration even if the time I have to spend on this topic is very, very limited. + +* Conclusion + +This is an ongoing exercise in bad sys-admining - but I am enjoying it very much. Everything so far is running smoothly, and within a short amount of time I surpassed the state my homelab was in - and not once did I have to delete and re-deploy an ingress configuration. I even managed to set up services that I gave up deploying before. + +I will keep using this for now. In the end, I don't want to have to rely on the LLM for every task I want to do with my homelab, and over time I am simplifying and restructuring the codebase further to make it easily maintainable by me, a silly old human. But even now it is in a very good state, and I am optimistic about the future of my selfhosted services.