Forgejo started as a way to learn how self-hosted Git works and to support Git-backed Docker workflows. It has grown into the local version-control backbone for the lab: Compose stacks, Ansible playbooks, homelab documentation, small development projects, and AI-agent work all benefit from having visible history.
Role In The Lab
Forgejo is the history layer rather than a runtime dependency for the services it documents. A DNS service or container should not stop working because Git is unavailable, but Git should make it possible to understand how that service was configured and what changed over time.
That boundary keeps version control useful without turning it into another hidden single point of failure.
Current Pattern
- Portainer pulls Compose stacks from Git-backed configuration.
- Automation experiments can use versioned playbooks instead of loose files.
- Homelab notes and documentation can be changed, reviewed, and rolled back.
- AI agents get a safer workspace because their edits are visible in Git history.
- Small app, website, and game experiments have a local place to live before anything needs to be public.
The shared pattern is simple: configuration and documentation live as readable files, changes produce a diff, and recoverable work has a history beyond the current state of a running container or VM.
Why Self-Host Git
The point is not replacing hosted Git for every use case. The point is having a local, controlled backend for private experiments and infrastructure configuration.
That matters most for agent-assisted work. When an agent changes files, Git gives the work a paper trail: what changed, when it changed, and how to roll it back if the result is wrong.
Agent Safety Boundary
Git does not make an automated change safe by itself, but it makes the change inspectable. An agent can work inside a bounded repository, show a diff, run validation, and leave a rollback point. That is a much better operating model than allowing tools to edit loose production files with no visible history.
The same rule applies to human changes: small commits and readable configuration are easier to review months later than a collection of undocumented UI edits.
Reliability Notes
The repositories contain history and configuration, but runtime services should keep functioning when Forgejo is temporarily unavailable. Local clones provide another copy of active work, while normal backup routines protect the service data itself.
The recovery priority is the history and configuration, not preserving every temporary development artifact.
Current Maturity
The workflow is still growing. The current pattern is mostly straightforward push/pull work, Git-backed Compose stacks, and configuration history. Deeper workflows such as branches, pull requests, forks, and worktrees are still learning areas.
Lessons
Version control is not just for software projects. In a homelab, it becomes the history layer for infrastructure, documentation, automations, and agent-driven changes.
The more useful lesson is that version control changes behavior. Knowing that a change will become a diff encourages smaller edits, clearer files, and more deliberate review.
Next Pass
The next pass is to make the review workflow more consistent: use branches for riskier changes, document validation expectations beside each repository, and keep deployment steps explicit enough that an agent or future version of me can follow them without guessing.