Happy Friday!

I don’t know about you, but I’m always on the lookout for more services to try out in my home lab. I regularly check out https://github.com/awesome-selfhosted/awesome-selfhosted and https://www.reddit.com/r/selfhosted/ to see what looks interesting.

This past week I was wanting to host something similar to Airtable and found that there were a few decent looking options including Baserow, Grist, and NocoDB. Being a lazy man, the natural question came up:

So I did what any sensible person would do. I built a tool.

The ultimate tool

I actually decided to combine that problem with the problem of finding new services into a singular tool.

It pulls down the awesome-selfhosted repo and travels the git history to build out a timeline of every service ever added to it along with the details of each. With my infinite creativity I named it selfhosting-updates, or shu for short.

I can simply run shu latest and it’ll show me the latest services added (with a --pending flag to see those in PRs).

If I want details about any of them I can run shu show and it’ll let me interactively select any of them.

That helps me keep on top of what new services are coming out. But then there is the matter of actually getting them up and running. For that, I decided that running them as Kubernetes services would be the easiest. It might seem overkill, but since I already have a mature K8s setup, I can simply run kubectl apply -f and it’ll be up and accessible in moments with a working hostname. And to tear it down I simply run kubectl delete -f and it is cleaned up. So I just needed a way to point to one of the GitHub repos and automatically build a Kubernetes manifest.

Thankfully, it is 2026 and we have the technology. I’ve created a shu k8s command that lets me select any of the services and it’ll spin up a container with omp (oh-my-pi, an AI coding agent which has a bunch of handy things like web search built in) pointed at a self-hosted ollama server with qwen and it does all of the the research against the target repo and generates a Kubernetes manifest following a template I provide with specifics around my exact setup (using the right ingress type, storage class, and all of that). And I have it use kubeconform to validate the manifest so it doesn’t give me junk.

It usually takes a few minutes since local LLMs are pretty slow. Using OpenRouter or OpenCode Go or similar would be much faster. But there is something cool about having it entirely run on your own hardware (at least that is how I cope). And so far it has been flawless. The agent has correctly determined the correct images and environment variables, has generated throwaway secrets and credentials, the right storage paths, and followed my requirements so I can very quickly test out a given tool.

As it happens, I found Grist to be the winner for my needs.

With the manifest it generated, I just took it and used it as the foundation to chuck into my GitOps repo and tweak the config as I desired. But 95+% of the work was done for me.

I’ve already used this to add a few more services to my stack as it has become so trivial to do so.

Takeaways

This might have been a bit of a tease, since I don’t have this up on GitHub at the moment as it is currently built for my exact setup. But that is the beauty of these coding agents. If you like any of the ideas of this tool, you can take inspiration and quickly build out your own tool that meets your exact needs for your environment.

Here is roughly how I thought about the problems before working on it:

• I want a way to get an “event log” of services added to the self-hosted list
• I don’t want to deal with scraping/fetching GitHub and rate limiting and all of that
• Pulling the Git repo with full history should allow us to “replay” every commit to build the log that I want

• I want to be able to pass in a GitHub repo and output a Kubernetes manifest
• I don’t want to have to customize the YAML at all, it should be fully demo ready
• It needs to have the specifics ready for my environment such as knowing the hostname pattern
• It needs to generate any secrets and credentials, and no fussing about it being insecure, it is for a throwaway demo

• The AI is going to need all relevant information before it can create the manifest
• Using an AI Agent rather than direct API calls will be easier as it can do its own research and use tools
• It needs to be able to validate the YAML
• It needs to be in a sandbox so that it can’t touch my cluster and mess anything up
• Shoving it into a container should be simple and effective

It is a fun little project. If you find yourself with a spare afternoon it is worth building your own tool like this.

Though as I’ve been writing this I’ve been filled with ideas for how I can make shu more generic and support more deployment targets. So maybe I will get this up on GitHub before long. If you’d be interested in that, let me know and I can share it with you.

– Logan / Terminal Velocity