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.
> 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?
I am also creating this and enjoyed the post and comments all going through the same thing :)
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...
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.
I had a conversation with my lawyer and I had “just one more question” that was going to take more than the time we had left in the current meeting. He said “schedule another 30 and let’s talk about that.”
Fair!
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
I still need to find the time to get into the Forgejo code and add that endpoint.
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.
But there is a different tool that is an API accessing CLI: https://codeberg.org/forgejo-contrib/forgejo-cli
Is it a deployment automation platform where it can run a project’s docker services, with rollback and all?
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
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. I recently moved them to Arcane so I can manage/deploy them with GitOps. The next logical step was using AI tooling to help maintain my services.
The first use that came to mind was using AI to help with container updates. Previously, I would spend time looking up the release notes for each of the services, checking for any breaking changes, running the updates, and manually checking each of the services for issues. I would spend a few hours on this. Now I can read a summary of the release notes in a few minutes, making version upgrades easier and safer. On top of that, I’ve used AI to add healthchecks to most of the containers to make it faster to spot issues.
I mainly used Claude Code, but AI providers have been really squeezing the value out of customers recently through token limits, so I took the opportunity to look into other options. I wanted something that was vendor agnostic and supported by the major plugins. I ended on OpenCode. There are probably other decent coding environments, but this was my favorite of the ones I tried.
Then I found it ships with a built in webserver and web UI, which gave me an idea.

I set up a simple VM on the Truenas host with basic dev tooling and added OpenCode webserver as a systemd unit. It’s a solid environment with a built in terminal, file browser, and git diffs, as well as git worktree support for managing multiple coding sessions at the same time. Plus, OpenCode had the best the question/answer popups in the mobile web UI that I’ve seen.
I gave OpenCode its own user on my Git server with dedicated SSH keys. It can clone projects and push branches, but it cannot push straight to the deploy branch.
My workflow keeps the AI behind PR review. OpenCode writes the change and I merge it myself in a PR. I think it’s cute, but more importantly, it keeps unreviewed code from getting deployed.
The VM has internet access and access to my Git server, but it cannot reach my actual services. Because the blast radius is small, I am comfortable giving OpenCode root on the VM when it needs to install build tools or test dependencies.
I could see building this into a production developer platform. Ephemeral containers available to developers with preinstalled tooling, access guardrails, and audit logs. But for me, it does what I need it to without too many moving parts.

My basic workflow is:
I migrated my services from Truenas to Arcane GitOps projects. This was mainly to have git-backed storage for all the docker compose stacks I was running in Truenas previously. I was surprised how well this worked in conjunction with adding OpenCode. Being able to update the networking across all containers, for example, from my phone makes the sprawl much easier to manage. Before it would take hours to comb through all of the compose stacks, tracing out network connectivity. Now I can point OpenCode at the codebase with a goal, check the resulting PR changes, and merge.
The main missing piece is CI feedback. On GitHub, I like pointing a coding agent at Actions logs so it can diagnose failing tests, linter errors, stack traces, and IaC plan changes. This helps maintain a fast feedback loop for changes that unit tests don’t cover.
Forgejo makes that harder. Forgejo Actions does not expose job logs through the public API. There are undocumented APIs, but I would rather not build around those.
This setup lets me make home infra changes from any device without giving AI direct access to the services it’s changing. I can start a change from my computer, review the PR from my phone, and let GitOps handle the deploy.
