Building a Homelab AI Development Platform with OpenCode and GitOps
An AI-driven development platform for homelab management allows for the automation of container updates and infrastructure changes while maintaining human oversight through a GitOps workflow. By isolating the AI agent in a dedicated VM and requiring Pull Request (PR) approvals, users can leverage AI for complex configuration tasks across multiple devices without granting the AI direct access to production services.
Architecture: OpenCode and Secure Sandboxing
The core of the platform is OpenCode, a vendor-agnostic coding environment chosen for its built-in web server and web UI, which enables persistent coding sessions that are synced across devices.
To maintain security and limit the "blast radius" of AI-generated changes, the system is architected as follows:
- Dedicated VM: OpenCode runs as a systemd unit within a simple VM on a Truenas host. This VM contains the necessary development tooling but is network-isolated from the actual services it manages.
- Restricted Git Access: The AI agent is assigned its own user on the Git server with dedicated SSH keys. It has permissions to clone projects and push to feature branches, but it is strictly prohibited from pushing directly to the deployment branch.
- Privileged Access: Because the VM is isolated from production services, the AI is granted root access within the VM to install build tools or test dependencies without risking the host system.
GitOps Workflow for Infrastructure Management
The platform replaces manual infrastructure maintenance—such as reading release notes and updating Docker Compose stacks—with an AI-assisted pipeline. The workflow follows a strict sequence to ensure stability:
- Planning: The user defines a feature or improvement in OpenCode, including a specification and implementation plan.
- Iteration: The user and AI iterate on the plan and verify changes where possible.
- Branching: OpenCode pushes the finalized changes to a feature branch.
- Review: The user opens and reviews a PR for the feature branch.
- Deployment: Once the PR is merged, GitOps tools handle the deployment. This includes Arcane for Docker service changes, a GitOps plugin for Home Assistant configurations, and Cloudflare Pages workers for blog updates.
This approach allows for high-level changes—such as updating networking across all containers—to be performed from a mobile device by reviewing a PR rather than manually editing multiple Compose files.
Technical Limitations and Challenges
While the platform streamlines updates, it faces a significant bottleneck regarding CI feedback loops. In environments like GitHub, agents can diagnose failing tests or linter errors by reading Action logs. However, in this setup using Forgejo, the public API does not expose job logs, making it difficult for the AI to autonomously diagnose and fix deployment failures.
Community Perspectives and Alternative Implementations
Discussion among developers reveals several alternative patterns for integrating AI into homelab and dev environments:
- Action-Based Agents: Some users run OpenCode inside Forgejo action runners, invoking the agent via
/occommands within an issue to automatically generate a PR. - **- Enhanced Sandboxing: Advanced implementations include using gVisor and Kubernetes agent sandboxes, or systemd-enforced private localhosts and proxies to prevent agents from accessing credentials directly.
- Integration Layers: Tools like Kimaki are used to add Discord integration, allowing users to interact with their codebase via voice or chat messages.
- Alternative Toolchains: Other users have implemented similar workflows using n8n, Argo, and k3s, utilizing models like Qwen or Gemma4 for automated workflows.
"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."
"I can start a change from my computer, review the PR from my phone, and let GitOps handle the deploy."