Skip to content

Forgejo as a Secondary Git Host for Files GitHub Rejects

Adityo Guni Waluyo

GitHub's 100 MB file block nearly ate a 631 MB backup bundle. The fix I picked: a self-hosted Forgejo secondary with proper mirror patterns.

Yesterday, September 11, 2026, I almost lost a 631 MB disaster-recovery bundle from the Hermes agent repo. I figured a simple git push would do the trick since the repo as a whole was tiny. Turns out, GitHub flat-out rejected it. GitHub blocks single files larger than 100 MB in normal Git, and the maximum push size is strictly capped at 2 GB [1]. Forget pushing. Even browser uploads max out at 25 MB, and files over 50 MiB instantly trigger a warning [2]. GitHub also recommends keeping the total on-disk repo size under 10 GB because massive repos slow down fetch and clone operations [1]. That’s exactly when I realized I needed a **forgejo secondary git host** that I actually controlled.

The Myth of Large Files on GitHub

Many claim large files simply can’t go into GitHub at all. That’s not entirely true. You can still sneak them in via Git LFS or release assets. But there’s a catch. Git LFS has per-file limits depending on your plan: Free 2 GB, Pro 2 GB, Team 4 GB, and Enterprise Cloud 5 GB [5]. The free LFS quota might look generous at first glance, offering 10 GiB of bandwidth and 10 GiB of storage per month [7]. However, the billing system is metered. This quota falls under a metered billing model: bandwidth resets at the start of each month, but storage usage is calculated continuously throughout the month based on all LFS objects attached to the repo, and it doesn’t recalculate even if you delete those objects mid-month [7]. If your budget is set to $0, the moment you hit the limit, LFS gets blocked for the rest of the month. This kind of model is a recipe for billing shock. The other option is release assets, where each release file must stay under 2 GiB, with no total size or bandwidth limits [6]. Still, release assets are hardly the right place for daily version control.

The Real Architecture of a Forgejo Mirror

I decided to run my own Forgejo server. The configuration is straightforward. I enabled LFS_START_SERVER in app.ini to fire up the built-in LFS server. The default web UI upload size is FILE_MAX_SIZE at 50 MB, but attachment MAX_SIZE can be bumped up to 2048 MB [4]. This is where a common mistake happens. Plenty of tutorials blindly recommend automatic pull mirrors. In reality, a pull mirror in Forgejo can only be configured during creation via 'New Migration' by checking 'This repository will be a mirror', followed by periodic synchronization [3]. The resulting pull mirror repo is strictly read-only, and this is a one-way street: a regular Forgejo repo cannot be converted into a pull mirror later, so you have to decide its status right at creation [3]. For healthy, reasonably sized repos, the pattern is the opposite. Forgejo pulls, acting as an automatic read-only backup via pull mirror. But for repos with massive files, the best strategy is to make Forgejo the primary host as a regular repo. Standard Git pushes to Forgejo have no file size limits — your quota is just your own disk space. Then, set up a push mirror back to GitHub with branch filters separated by commas using globs like feature/*. Remember, a push mirror ALWAYS performs a force-push and overwrites remote changes [3]. So, ensure you only mirror safe branches that stay well under size limits.

Full Control in My Own Hands

For personal scale, self-hosting Forgejo makes way more sense than paying for LFS quota overages. The disk is mine — no drama about quota resets or sudden blocks. I can stash that 631 MB bundle without breaking a sweat. GitHub remains useful as a public fallback for lightweight core code, while Forgejo handles the heavy lifting. GitHub’s recommended maximum on-disk repo limit of 10 GB is no longer a looming threat over my head [1]. I just need to make sure I don’t rely on LFS over SSH push mirrors, since that feature isn’t implemented yet [3]. Setting up your own infrastructure takes some initial effort, but the peace of mind you get when hitting that push button is worth far more.

Sources

  1. GitHub Docs: Repository limits
  2. GitHub Docs: About large files on GitHub
  3. Forgejo Docs: Repository Mirrors
  4. Forgejo Docs: Configuration Cheat Sheet
  5. GitHub Docs: About Git Large File Storage
  6. GitHub Docs: About releases
  7. GitHub Docs: Git LFS billing

Related articles