We're considering moving from GitHub to a self-hosted Forgejo instance after another service outage. We currently have roughly 12 active repositories and fewer than 50 developers, with a fair amount of commit and CI activity for a company of that size. We already operate self-hosted runners, which we would presumably reconfigure for Forgejo. For anyone running Forgejo in a company, how much ongoing work is involved in keeping it reliable? I'm especially interested in storage and I/O planning, backups and restores, upgrades, package or artifact storage, integrations, and whether a VM, containers, or Kubernetes makes a meaningful difference.
4 Answers
Git operations usually aren’t the expensive part, even with plenty of commits and a dozen repositories. The bigger problem can be runner checkouts, build artifacts, and packages sharing the same disk as the repositories. During a busy CI period, that can make normal pushes and pulls feel slow. Put repository data, artifacts, and package storage on sensible separate volumes where possible, configure retention instead of keeping every artifact forever, and monitor free disk space. CPU graphs may look fine while storage is becoming the real bottleneck.
We run Forgejo for more than 100 people on Kubernetes and it has been very uneventful. Initial setup, especially the runners and integrations, took some effort, but day-to-day maintenance has been minimal. For a deployment of your size, the application itself should be quite manageable. Kubernetes makes upgrades and deployment convenient, although a well-maintained VM or container setup should also work fine.
That’s exactly the kind of experience I was looking for. I’m also curious how you handle integrations and whether you migrated from another platform or started with Forgejo.
Backups and restore testing are more important than the runtime maintenance. Make sure you back up both the database and Forgejo’s repository and data directories; a database-only backup can leave you with no usable repositories. Test restoring everything into a temporary VM periodically, ideally with runners pointed at the test instance. After that, the routine work is mostly pinned upgrades, monitoring disk usage, checking logs, and keeping artifact and package retention under control. Docker Compose can be perfectly adequate for a deployment of this size.
Agreed—losing a repository would be a serious incident. I’ll make a full restore test part of the initial rollout instead of assuming that successful backup jobs are enough.
I run Forgejo and its runners in a Proxmox homelab using an LXC container, Terraform, and Ansible. Version pinning makes upgrades predictable, and the service itself has been straightforward to maintain. I’d probably separate the database and runner hosts for a more production-oriented setup, but an all-in-one installation can handle a small team without much trouble. Access and HTTPS are also fairly simple when using a private network overlay.
Have you needed clustered storage or special handling for downtime? I’m also wondering whether you’ve run into noticeable push and pull slowdowns or hardware-related I/O problems.
That makes sense. We already operate self-hosted runners, so moving those should reduce some of the CI load. The storage and artifact-retention details are the parts I’m most concerned about.