How much maintenance does a small self-hosted Forgejo instance require?
Asked by
MellowPine47
We're considering moving from GitHub to a self-hosted Forgejo instance after another service outage. Our organization has fewer than 50 developers and roughly a dozen active repositories, but the repositories see fairly frequent activity. We already operate self-hosted runners and would configure them for Forgejo as well. For anyone running Forgejo in a company or production-like environment, how much ongoing work is involved? I'm especially interested in storage and I/O requirements, backups and restore testing, upgrades, integrations, and any issues that only become apparent after supporting multiple users.
Answers
The application itself is generally easy to maintain at this size, whether deployed with containers or on a VM. The part that deserves serious attention is recovery. Make sure backups include both the database and Forgejo’s repository and data directories; a database-only backup may not be enough. Test restoring everything into a disposable VM periodically, ideally with runners pointed at the test instance. After that, routine work is mostly controlled upgrades, disk monitoring, and checking that retention policies are actually removing old artifacts.
Reply to this answer
I run Forgejo and its runners in a Proxmox homelab using an LXC container, with Terraform and Ansible managing most of the setup. Pinning versions in configuration variables makes upgrades predictable. It runs comfortably with several active repositories, and external access through Tailscale and HTTPS is straightforward. For a more production-oriented deployment, I’d separate the database and runner hosts, and consider more deliberate high-availability and backup design.
SilverBirch19: How do you handle downtime and storage redundancy? Are you using shared storage or a cluster?
MellowPine47: Have you noticed any push or pull slowdowns, or run into hardware and I/O limitations?
Reply to this answer
Git operations themselves are usually cheap at this scale. The bigger performance problem can come from runner checkouts, build artifacts, and package or container storage sharing the same disk as the repositories. A busy CI period can make normal Git operations appear slow. Separating repository storage from artifacts, setting retention limits, and monitoring free disk space are more useful than simply watching CPU usage. Moving runners elsewhere helps with checkout load, but uploaded artifacts and packages still use Forgejo’s storage unless configured otherwise.
MellowPine47: That makes sense. We already manage our runners separately, so my main concerns are the Forgejo volumes, artifact retention, storage growth, and reliable backups.
Reply to this answer
We run Forgejo for more than 100 people on OpenShift and it has been very low-maintenance. The initial setup for the application and runners took some work, but day-to-day operation has been uneventful. Kubernetes makes deployment and upgrades fairly manageable, although the exact experience will differ on a standalone VM.
MellowPine47: That’s exactly the kind of experience I was looking for. I’m also curious whether you moved from GitHub and how you handle integrations with tools such as monitoring or issue-management systems.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowPine47: Good point about testing restores. Losing a repository would be far more serious than dealing with routine maintenance, so we’ll make recovery testing part of the initial rollout.