Setting up a personal forge with Forgejo

After multiplying the number of small personal projects, I wanted to take back control over the entire development chain: hosting my repositories, running my automations and tracking Pull Requests without depending solely on external platforms. I therefore set up a personal forge with Forgejo, accompanied by a runner, Renovate and my Hermes Agent instance on a VPS to automate part of the reviews.

Why Forgejo

I was looking for a lightweight forge, simple to maintain and complete enough for personal use: Git repositories, issues, Pull Requests, user management and integration with runners. Forgejo meets this need well. The interface remains familiar, resource consumption is reasonable, and administration is simpler than with a much heavier platform.

• Hosting my personal repositories on my own infrastructure.
• Keeping an interface close to classic Git forges.
• Being able to add automation without complicating the whole stack.

Docker Compose Architecture

The platform relies on three building blocks: the Forgejo service, an isolated execution engine for jobs, and a runner responsible for launching automations. This separation makes it possible to keep the forge readable while avoiding mixing repository hosting and workflow execution.

• Forgejo runs with a rootless image, which limits the privileges of the main service.
• Application data is stored persistently.
• The web interface and SSH Git access are exposed separately, then integrated into the rest of the infrastructure via the reverse proxy and the bastion.
• The Forgejo runner keeps its configuration separate from the main service.

Choosing Docker Compose makes the stack readable: one service for the forge, one service for job execution, and one service for the runner. I can back up the useful data and redeploy the whole setup without having to manually rebuild the configuration.

Forgejo in rootless mode

I chose a rootless approach to limit the privileges of the main service. Data remains persistent, and the configuration keeps consistent dates in both the interface and the logs.

The web interface and Git operations over SSH remain separate. This clearly distinguishes user usage, Git access and public exposure managed by the reverse proxy.

Runner and Docker-in-Docker

To run jobs, I added a Forgejo runner. It relies on a Docker-in-Docker container that exposes the Docker daemon only on the internal Compose network. The runner then uses this internal engine to create the environments required for automations.

The job execution engine requires caution: it must remain isolated and reserved for workflows that I control. In my case, it is mainly used to automate my own repositories and avoid running these tasks directly on the host.

• The runner starts after the Docker-in-Docker service.
• It runs with a non-privileged user on the runner side.
• Its configuration is separate from that of the main service.

Renovate to keep dependencies up to date

I also set up Renovate to monitor my projects' dependencies. The goal is not to update everything automatically without control, but to receive clear Pull Requests, with the changelog and necessary context to quickly decide if the update is acceptable.

On a personal forge, Renovate is particularly useful because it avoids the accumulation of forgotten minor versions. Updates arrive as PRs, which keeps a clean trace of changes and allows testing before merging.

Automated reviews with Hermes Agent

To go further, I connected the forge to my Hermes Agent instance hosted on a VPS. The idea is to have a first automated review on Pull Requests: spot risky changes, flag obvious inconsistencies and help me review faster without replacing human validation.

This part is especially interesting for PRs generated by Renovate. Hermes can give a first opinion on the scope of the change, which allows me to prioritise simple updates and keep more attention for modifications affecting the build, security or configuration.

Points to watch out for

• Regularly back up important data from the forge and the runner.
• Limit the repositories and jobs allowed to use the runner.
• Monitor Docker-in-Docker, as it requires elevated privileges.
• Keep Renovate and Hermes tokens separate with the minimum necessary permissions.

Summary

This personal forge gives me a more autonomous development chain: repositories are hosted at home, jobs can run via the runner, Renovate keeps dependencies under review and Hermes Agent provides an initial automated review of Pull Requests. The whole setup remains fairly simple to maintain thanks to Docker Compose, while leaving the option to gradually add new workflows.