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.
3 Answers
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.
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.
How do you handle downtime and storage redundancy? Are you using shared storage or a cluster?
Have you noticed any push or pull slowdowns, or run into hardware and I/O limitations?
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.
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.
That makes sense. We already manage our runners separately, so my main concerns are the Forgejo volumes, artifact retention, storage growth, and reliable backups.