Rendered at 10:08:47 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
torgeros 31 minutes ago [-]
I think it is very descriptive for this AI title that the server is not available, HECK, the Domain does not even resolve to an IP... xD
david-giesberg 17 hours ago [-]
I've been doing something pretty similar, except instead of having a persistent opencode server, I've been using this workflow that runs opencode inside of the Forgejo action runners:
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.
chamoda 1 hours ago [-]
I did this with github actions + opencode. It has mainly two components called daydream and nightwatch. Daydream runs on a daily schedule looking at the VISION.MD file in the project and also look at the project and suggest new ideas, security , maintenance tasks (you can set a ratio of maintenance vs new ideas) and create a new issue. Then nightwatch runs daily at night and picks up oldest issue and suggest a PR. I'm in total control of merging, can ask for changes which agent again will execute immediately.
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.
I use hermes with crons and kanban for this. I have a "self driving" homelab where upgrades & config changes happen in a non-prod ct before being applied to "prod" (just, a diff ct). Its mainly compose stacks with data volumes on zfs that gets snapshotted a lot to limit possible data loss. I use the orchestrator to break down regular tasks like "health check the whole env" or "find all containers that need an update", "update terraform providers" into changes with their own card & MR, actioned serially via kanban. The task detail is just in playbooks in the repo, like a human would use. Executed by qwen 3.6 27B. I still use claude to help define and oversee workflows though.
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.
MisterPea 16 hours ago [-]
Some times I feel like a lot of people in tech independently go through the same things right around the same time with few people writing/sharing about it.
I am also creating this and enjoyed the post and comments all going through the same thing :)
plmpsu 14 hours ago [-]
Not only in tech. This is a common phenomenon. We're not that original.
jatora 9 hours ago [-]
nah im original af you wouldnt believe the stuff i have built even if i told you, its so unique it's borderline retarded to the eye.
iagooar 13 hours ago [-]
I have created this in 3 different ways, also with e2b.dev (great service). And yeah, that is my problem - I spend 99% of time hacking cool stuff, 1% yapping about it. Should do more yapping.
girvo 12 hours ago [-]
Depressingly in todays attention economy, you absolutely should! It'll be good for you directly. At least one upside is it can help others too I suppose, I just get sad when I think about how important attention is now
MAustriaGA 16 hours ago [-]
[flagged]
constGard 8 hours ago [-]
I've added a few more bells and whistles to my agentic rube goldberg, but the gist is forgejo tag listeners triggering argo workflows to orchestrate
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.
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.
doctorspazz 17 hours ago [-]
I've been trying to find the motivation to do a write up on my AI lab, and this is just what I needed. Thanks for sharing. My setup is a similar idea, just with n8n/git/argo/k3s. It's mainly for automated workflows that Qwen or Gemma4 can handle.
atn34 7 hours ago [-]
I've got a gitea instance and a systemd timer polling for issues assigned to my bot. The systemd timer clones the repo etc and spawns the agent in a restricted environment where it has a private localhost (enforced by systemd), and then I set HTTP_PROXY to an inner proxy that connects to an outer proxy over a unix socket. The outer proxy enforces an allowlist and injects credentials. The agent doesn't have access to any credentials inside its sandbox.
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
schanz 13 hours ago [-]
Any idea as of why this domain is blocked by quad9 resolvers? I am unable to open the website because Quad9 filters the domain:
> I set up OpenCode Web UI with Git access to make my homelab easier to manage. OpenCode pushes to Git, I approve the PRs, GitOps deploys the changes. Best of all, OpenCode runs as a server with persistent coding sessions synced across devices.
> 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?
zaptheimpaler 16 hours ago [-]
0? OpenCode is just a harness, it can connect to any model hosted online.
jagged-chisel 11 hours ago [-]
> ... hosted online.
Oh, so not that kind of Home Lab.
Carrok 8 hours ago [-]
It can connect to any model hosted anywhere.
templar_snow 15 hours ago [-]
This is great. Homelab AI feels like it's going to fun as heck. I currently have Claude maintain my homelab across all devices; it made homelab setup and maintenance go from "This is a trap that will fascinate you for years but never fully work right and waste time that would have better been spent elsewhere" to "This is actually a great idea and really extends my capabilities."
ohyoutravel 15 hours ago [-]
I’ve found, even using the latest models, there are some time saving nuggets but mostly subtle config difficulties that just cause an enormous amount of debugging and a net negative on balance, unless you’re just asking for super targeted tasks like “set up a docker compose file” or “give me an NSD config.” But with both of those you need to already know you need the underlying tech and what to ask.
dlxfoo 17 hours ago [-]
Im doing something very similar. Running my OpenCode on a proxmox lxc. I have an additional layer of Kimaki, which gives you Discord integration (hate it or love it). Chatting with your codebase (voice messages, too, if that’s your jam), is very very cool.
rsgm 17 hours ago [-]
That's very cool. Thanks, I'll have to check that out.
orangeisthe 13 hours ago [-]
Two main reasons I don't have this setup already is
- the resource you need to give the VM running opencode to build your projects
- Faster testing
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.
taleodor 17 hours ago [-]
Very cool, we're doing similar except we let agents open PRs as well + we track release metadata and agentic sessions via our ReARM system + we've recently launched an option for agents to track helm-based deployments via ReARM - https://docs.rearmhq.com/workflows/devops.html
rsgm 17 hours ago [-]
I didn't mention this part, but while writing this I realized I could easily add a skill to hit the Forgejo PR API. There's no forgejo CLI like there is with GitHub sadly.
kenosha 12 hours ago [-]
I just use the tea CLI. There is pretty good compatibility between tea and forgejo. The only place I’ve found it to be incomplete is forgejo’s actions api was missing some endpoints.
There is, but it's limited. For example Forgejo does not expose CI build logs via the API so it's hard to make Claude auto-fix a build issue.
I still need to find the time to get into the Forgejo code and add that endpoint.
bityard 17 hours ago [-]
That seems like a problem an LLM could solve. ;) (Assuming Forgejo has a reasonable REST/whatever API.)
vinnymac 7 hours ago [-]
I’m working on an open source Forgejo Frontend that exposes additional features like this, and offers a better user experience, faster large diffs, and basically fixes every little thing I don’t like about Forgejo. Would be interested in hearing more of your complaints so I can continue to improve.
vannomad 3 hours ago [-]
Isn't contributing a better way especially if it's fixing broken stuff?
CGamesPlay 10 hours ago [-]
Nice! I am still looking for the best AI integration for my setup. Currently I don't have any interaction between Forgejo and my coding agent. I experimented with a Forgejo Actions runner, but the problem that I had was there's not a great way to manage the context there: you get what's in the issue or PR, but it gets muddy once you have multiple rounds and/or discussion moves from the issue to the PR.
variety8675 18 hours ago [-]
How do you run inference for Open Code? What models are you running
znnajdla 5 hours ago [-]
For me personally: I sync OpenCode authentication tokens across all containers using Syncthing (will probably get a NAS at some point) and keep it signed it to Codex, DeepSeek, Kimi as well as a local Gemma 4 12B running on a MacMini. For frontier inference API endpoints you can also use vibeproxy to give you OpenAI compatible endpoints to Codex/Antigravity.
cantalopes 12 hours ago [-]
I get DNS_PROBE_POSSIBLE trying to open that domain
msukkarieh 14 hours ago [-]
We have a lot of folks using Sourcebot in their home lab as a nice free code search across their projects. Hope it could be helpful!
I see a lot of people using Komodo for it, though if I had to pick I'd go with Doco CD[0]. You can also use standard Ansible for just cron+bash script to git pull.
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.
I recently setup Arcane and started migrating stuff from Truenas apps, they were all deployed as custom docker compose services so it worked out. Arcane supports Git syncs to auto deploy compose stacks, https://getarcane.app/docs/features/projects#sync-from-git
I'll write up some posts on my full setup soon.
Is it a deployment automation platform where it can run a project’s docker services, with rollback and all?
rsgm 17 hours ago [-]
so, the project is pretty much vibe coded, including the docs. It makes a lot more sense if you play around with it. It's just a docker host management UI, I like using it. It has gitops built in and a nice container log view. It doesn't do rollbacks, it only seems to sync from git and run compose up.
zbentley 9 hours ago [-]
Is it analogous to portainer with a git-pull-compose-apply loop?
c-hendricks 15 hours ago [-]
A long long time ago I wrote something for the company I was with to allow for pre-merge staging environments (preview environments but I didn't have a name for them then)
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.
fazgha 18 hours ago [-]
So first post in the blog, and it went directly HN frontpage.
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...
rsgm 18 hours ago [-]
I looked into running local models last month. They just aren't quite there for agentic tool use workflows without spending a small fortune. I'm hopeful smaller local models get much better soon.
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.
sosodev 17 hours ago [-]
I think it heavily depends on what you're asking the model to do. Qwen3.6, both 27B and 35B-A3B, do agentic tool use very well. Their decision making is sus, but the dense model is decent in that way. A 4-bit quant for either of those can run on many home systems with a bit of configuration.
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.
nyrikki 16 hours ago [-]
My workflow is too different right now (gradually constrained to network less builds for reasons) but I am really enjoying how zeds agents have worked out in the past few weeks.
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
reactordev 18 hours ago [-]
you can't explain the HN hug. You feel it, or your servers do.
estetlinus 16 hours ago [-]
Do you use this at work or is it for vibe coding? Also, I don’t quite understand the problem you are solving. The solutions is a lot of technical parts put together, but why?
johnnytech 18 hours ago [-]
Really cool! Do you autoapprove edits or do you approve manually?
rsgm 18 hours ago [-]
I'll verify the PR code myself before merging, but that's usually a quick skim.
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.
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.
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.
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
dig @9.9.9.9 rsgm.dev NS
> 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.
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.
https://github.com/sourcebot-dev/sourcebot
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
Is it a deployment automation platform where it can run a project’s docker services, with rollback and all?
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