Forgejo Secondary Git Host untuk File yang Ditolak GitHub
Limit file GitHub bikin bundle 631 MB nyaris gagal push. Jawabannya: self-host Forgejo sebagai secondary git host dengan pola mirror yang benar.
Kemarin, 11 September 2026, saya hampir kehilangan bundel disaster-recovery seberat 631 MB dari repo agen Hermes. Saya pikir tinggal `git push` biasa aja karena repo-nya secara keseluruhan kecil. Ternyata GitHub langsung menolak. GitHub memblokir file tunggal lebih dari 100 MB dalam git normal, dan ukuran push maksimum dipaksa di angka 2 GB [1]. Jangankan push, upload lewat browser aja maksimal 25 MB, dan file di atas 50 MiB langsung dapat peringatan [2]. GitHub juga nyaranin total repo di disk (folder .git) jangan lebih dari 10 GB, karena repo gede bikin operasi fetch dan clone melambat [1]. Di sinilah saya sadar butuh **forgejo secondary git host** yang benar-benar saya kendalikan.
Mitos File Besar di GitHub
Banyak yang bilang file besar nggak bisa masuk GitHub sama sekali. Itu nggak sepenuhnya benar. File besar masih bisa lewat Git LFS atau release assets. Tapi ada jebakannya. Git LFS punya batas per file tergantung paket: Free 2 GB, Pro 2 GB, Team 4 GB, dan Enterprise Cloud 5 GB [5]. Kuota gratis LFS memang terlihat longgar, yaitu 10 GiB bandwidth dan 10 GiB penyimpanan per bulan [7]. Tapi sistem billing-nya metered. Kuota ini masuk model billing metered: bandwidth ke-reset tiap awal bulan, tapi pemakaian storage dihitung terus-menerus sepanjang bulan berdasarkan semua objek LFS yang nempel di repo, dan nggak dihitung ulang walaupun objeknya dihapus di tengah bulan [7]. Kalau budget diset $0, begitu kuota mentok LFS langsung diblokir sisa bulan itu. Model kayak gini gampang banget bikin kaget. Opsi lain adalah release assets, di mana setiap file rilis harus di bawah 2 GiB, tanpa batas total ukuran atau bandwidth [6]. Namun, release assets bukan tempat yang tepat untuk version control harian.
Arsitektur Mirror Forgejo yang Sebenarnya
Saya memutuskan menjalankan server Forgejo sendiri. Konfigurasinya sederhana. Saya aktifkan `LFS_START_SERVER` di app.ini untuk menghidupkan server LFS bawaan. Ukuran upload default di web UI adalah `FILE_MAX_SIZE` 50 MB, tapi attachment `MAX_SIZE` bisa diatur sampai 2048 MB [4]. Di sinilah letak kesalahan umum. Banyak tutorial menyarankan pull mirror otomatis. Padahal, pull mirror di Forgejo hanya bisa diatur saat pembuatan via 'New Migration' dengan mencentang 'This repository will be a mirror', lalu sinkronisasi berkala [3]. Repo hasil pull mirror bersifat read-only, dan ini one-way: repo Forgejo biasa nggak bisa diubah jadi pull mirror kemudian, jadi putuskan statusnya sejak create [3]. Untuk repo sehat yang ukurannya wajar, polanya kebalikan: Forgejo yang narik, lewat pull mirror sebagai backup otomatis yang read-only. Untuk repo dengan file besar, strategi terbaik adalah menjadikannya primary di Forgejo sebagai repo biasa, karena push git biasa ke Forgejo nggak ada limit ukuran file, kuotanya ya disk sendiri. Lalu, buat push mirror kembali ke GitHub dengan filter branch yang dipisahkan koma menggunakan glob seperti `feature/*`. Ingat, push mirror SELALU melakukan force-push dan menimpa perubahan remote [3]. Jadi, pastikan hanya branch yang aman dan di bawah batas ukuran yang di-mirror.
Kendali Penuh di Tangan Sendiri
Untuk skala personal, self-hosting Forgejo jauh lebih masuk akal daripada membayar kelebihan kuota LFS. Disk adalah milik saya sendiri. Tidak ada drama kuota reset atau blokir mendadak. Saya bisa menyimpan bundle 631 MB itu tanpa rasa waswas. GitHub tetap berguna sebagai cadangan publik untuk kode inti yang ringan — sementara Forgejo menangani beban berat. Batas on-disk repo GitHub yang direkomendasikan maksimal 10 GB [1] bukan lagi batas yang mengintai saya. Saya hanya perlu memastikan LFS over SSH push mirror tidak diandalkan karena memang belum diimplementasikan [3]. Mengatur infrastruktur sendiri memang butuh usaha awal, tapi ketenangan pikiran saat menekan tombol push itu harganya jauh lebih mahal.