My Homelab AI Dev Platform
rsgm.dev
rsgm.dev
https://codeberg.org/dragonfyre13/forgejo-opencode
Still tinkering with it, but the gist is that I can invoke Opencode with /oc inside of an Forgejo issue, then it will come back with a PR for me to review.
This has been helpful to revive few old projects and keep momentum on active projects. I've been closing more PRs than merging but I think that's fine. I quickly ran out of free github action hours so I had to self host actions. However basic self-host actions setup may not be secure enough because VM is not destroyed after each action like github own action jobs environment.
Anybody can try it out actions from https://github.com/chamoda/agent-foundry, minimal setup don't need any API keys, works with mimo 2.5 free model by default.
I am also creating this and enjoyed the post and comments all going through the same thing :)
1. issue tag
2. write pr
3. testing
4. review+revise loop
5. merge mutex to ensure you don't get a merge storm
6. rebase and merge
I've been trying really hard to have it properly implement agentic identity where the pod gets a spiffe-attested token and then trades that for access to the vault secret for a project-scoped forgejo service account. I wish forgejo could configure a trusted external jwt signing authority so I could skip vault and the accounts.
Here's the inspiration for the auth model I've been trying to implement: https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/
The last piece has been using gvisor + kubernetes agent sandboxes. My fable adventure last week was having it debug the process of attesting and distributing workload identities for agents running in gvisor, as it creates a layer of indirection that confuses spire to the point it won't issue an ID.
dig @9.9.9.9 rsgm.dev NS
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 17 (Filtered)I find it convenient to interact with frontier LLMs through a Kanban board powered by Kanboard. For example, the LLM creates backlog tasks based on alerts from the cluster. I manually move selected tasks from the backlog to Ready, the model picks them up, works on them, and submits a patch for review in the comments. From there, the usual pipeline takes over: CI, LGTM, merge, and CD.
Another surprisingly useful part is desktop configuration management, covering everything from the compositor and system tray to text editor configuration with the same pipeline. For once, I genuinely enjoy using Linux on the desktop.
> I’ll share my homelab setup soon. There are about a dozen docker compose stacks for the services that I manage.
That is probably neat, but before I read, how many thousands of dollars would I need to spend to acquire the RAM and GPUs needed to do something similar?
Oh, so not that kind of Home Lab.
For the agent I was using `claude -p` with a pro subscription, but they've been treating their paying subscribers like they're on a free trial (they're subsidizing it so heavily it might as well be). So now I'm using an ollama pro subscription and a homebuilt agent with a bash tool and a str_replace tool. It gets on just fine with only those two
I run pi coding agent right on my mac and I run our entire software suite - example: redis, postgres, kratos, .. etc. With coding agent running on my main development device, I can build faster (assuming opencode VM is a on a low specd machine) as well as test it faster. Example: I can just rebuild the backend and restart it and test it on the UI client with the new changes.
But there is a different tool that is an API accessing CLI: https://codeberg.org/forgejo-contrib/forgejo-cli
I still need to find the time to get into the Forgejo code and add that endpoint.
Probably CI is the better primitive, I usually use gitlab though and I felt "put off" by all their native AI features being license gated.
Is it a deployment automation platform where it can run a project’s docker services, with rollback and all?
On the Podman side, I wrote a tool named Materia[1] for it, but there's also the wonderful Ansible quadlet role as well as Quadit and Orchess.
[0] https://github.com/kimdre/doco-cd
[1] https://primamateria.systems or https://github.com/stryan/materia
Used docker-compose + git for application servers, and docker-compose + sync for static sites.
Actually worked pretty well! There's bound to be better options nowadays.
Then, I said homelab AI, I thought it's an interesting post about local GPU setup (and I am really interested in this topic).. but no, just another hype post about how to use whatever-code...
I was also hoping to put out another post on my homelab setup, it has some neat stuff, but I haven't had a chance to finish it.
The biggest issue I've noticed is that the chat templates for open models are really hit or miss. The default Qwen3.6 chat template mostly works these days, but depending on your workload it may cause major issues. There are plenty of "fixed" chat templates on hugging face, but people report mixed success. It really seems to depend a lot on what the tool you're using expects.
I have 27b, 35B-A3B and a cpu backed gpt-oss configured and use them in parallel, checking if one is getting ratholed and adding context or manual fixes.
I had various other systems setup and commercial models but really don’t use them.
It may be too interactive for some people, but it is a good mix of fail fast and often the places qwen3.6 was failing was eventually problems with the frontier models.
And this is with the unsloth defaults and hardened llama.cpp podman containers.
I do sometimes load other models or honestly just feed things into google’s free agent. But that is rare and to be honest manually fixing is typically faster and less error prone