Self-hosted Git sunucusu: Forgejo, Gitea veya cgit seçimi

Hangi self-hosted Git sunucusunu çalıştırmalısınız

Self-hosted bir Git sunucusu tek bir üründen ibaret değildir; VPS üzerindeki RAM (rastgele erişimli bellek) miktarı, hangi sürümü kullanabileceğinizi belirler. Git'in kendi başına bir daemon'a ihtiyacı yoktur: çıplak (bare) bir depo ve bir SSH (secure shell) hesabı, kiralayabileceğiniz en küçük sunucuda bile çalışan bir sunucu oluşturur. Bu seviyenin üzerindeki her şey, yanında çalıştırmayı seçtiğiniz bir web uygulamasıdır ve her bir üst seviye, küçük bir VPS'in sahip olamayabileceği kadar bellek tüketir.

Dört aşama mevcuttur. SSH üzerinden çıplak bir depo; halihazırda dinleme yapmayan hiçbir şey dinlenmez. cgit; veritabanı gerektirmeyen, hızlı ve salt okunur bir web arayüzü. Forgejo veya Gitea; hesaplar, issue'lar ve pull request'ler içeren, birkaç yüz megabayt bellek tüketen tam teşekküllü bir platform. GitLab; diğerlerinin boyutunun katbekat fazlasını gerektiren bir sunucu yapısı.

Yapmanız gereken işe göre karar verin, ardından bellek miktarını ödeme yaptığınız planla karşılaştırın.

Her seçeneğin gerçek RAM ihtiyacı

Bu projelerden sadece ikisi donanım gereksinimi yayınlamaktadır. Yayınlanan rakamları bir vaat değil, bir alt sınır olarak kabul edin ve sisteminiz çalışmaya başladığında systemd-cgtop veya ps -o rss= -C forgejo kullanarak kendi ölçümünüzü yapın.

[
  {
    "label": "Gitea, small team",
    "ram_gb": 1
  },
  {
    "label": "GitLab, memory constrained",
    "ram_gb": 8
  },
  {
    "label": "GitLab, single node baseline",
    "ram_gb": 16
  }
]

Gitea, küçük ekipler ve projeler için genellikle 2 CPU çekirdeği ile 1 GB RAM'in yeterli olduğunu belirtmekte ve küçük iş yükleri için Raspberry Pi 3'ü örnek göstermektedir. GitLab, tek düğümlü bir kurulum için temel gereksinim olarak 16 GB RAM belirtirken, kendi sayfasında bellek kısıtlı ortam olarak adlandırdığı durumlar için alt sınırı 8 GB olarak tanımlamaktadır. Forgejo herhangi bir donanım gereksinimi yayınlamamaktadır. Gitea'nın bir çatalı (fork) olduğu ve benzer şekilde çalıştığı için, Gitea için yayınlanan rakamlar elinizdeki en yakın kılavuzdur.

1 GB RAM'e sahip bir VPS üzerinde bu durum şuna karşılık gelir: Çıplak depolar (bare repositories) ve cgit, herhangi bir yerleşik servis çalıştırmadıkları için rahatlıkla çalışır ve boş alan kalır. Forgejo veya Gitea, SQLite üzerinde küçük bir ekibe hizmet verebilir; ancak bellek sınırında olduğunuz için PostgreSQL ve CI (sürekli entegrasyon) çalıştırıcısını bu sunucuda çalıştırmayın. Web arayüzü hata vermeden kaybolursa, sudo dmesg -T | grep -i oom komutunu çalıştırın ve Out of memory: Killed process 1181 (forgejo) gibi bir satır arayın; bu, çekirdeğin bellek yetersizliği nedeniyle süreci sonlandırdığı (OOM killer) anlamına gelir. 1 GB RAM'e sahip bir sunucuda GitLab çalıştırmak bir optimizasyon sorunu değildir; GitLab bu kaynakla çalışmayacaktır.

Tier 0: SSH uzerinden yalın depo

Git, başlatmanız gereken herhangi bir ağ arka plan sürecine (daemon) sahip değildir. SSH uzerinden git push, uzak tarafta sıradan bir Unix süreci olarak git-receive-pack çalıştırır; bu nedenle bir anahtar (key) ile erişebildiğiniz her hesap zaten bir Git uzak sunucusudur (remote). Depolar için tek bir hesap oluşturun ve depoları bu hesabın ev dizininin dışında tutun. Ubuntu 24.04 üzerinde yeni bir ev dizini 0750 modundadır ve daha sonra eklenecek bir web arayüzü bu dizinin içeriğini okuyamaz.

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
sudo install -d -m 0755 -o git -g git /srv/git
sudo -u git git init --bare /srv/git/project.git

--bare, sunucunun barındırdığı türden, çalışma kopyası olmayan bir depo oluşturur. Çalışma kopyası olan bir depoya push işlemi yapmak refusing to update checked out branch: refs/heads/main hatası ile reddedilir; bu, bu seviyede yapılan en yaygın hatadır.

Şimdi hesaba bir anahtar tanımlayın ve depoyu klonlayın.

sudo -u git install -d -m 700 /home/git/.ssh
sudo -u git tee -a /home/git/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop
EOF
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

git remote add origin git@vps.example.com:/srv/git/project.git
git push -u origin main

Başarılı olan ilk push işlemi * [new branch] main -> main ile biter. git@vps.example.com: Permission denied (publickey) ile biten bir işlem kimlik doğrulaması yapılamadığını gösterir; bu durumda sudo journalctl -u ssh -n 20 ile sunucu günlüklerini inceleyin. Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys ifadesini içeren bir satır, dosya izinlerinin yanlış olduğu anlamına gelir; çünkü sshd, diğer kullanıcıların yazabildiği bir anahtar dosyasını yok sayar.

Ardından hesaptan kabuk (shell) erişimini kaldırın.

command -v git-shell | sudo tee -a /etc/shells
sudo chsh -s "$(command -v git-shell)" git

git-shell, yalnızca Git'in SSH üzerinden gönderdiği birkaç komutu kabul eder; bu nedenle etkileşimli bir oturum açma girişimi artık komut satırı yerine bir mesajla sonlanır:

fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

Sunucunun tamamı bundan ibarettir. Herhangi bir veritabanı veya yükseltilmesi gereken bir web süreci yoktur. Bu yapıda bir kod deposu yönetim platformunun (forge) sunduğu özelliklerden vazgeçmiş olursunuz: tarayıcı üzerinden görüntüleme, hata takip sistemi, pull request mekanizması ve kullanıcı bazlı izinler bulunmaz. O dosyadaki her anahtar, git kullanıcısının sahip olduğu her depoyu okuyabilir ve yazabilir.

Seviye 1: cgit, veritabanı olmadan web görünümü sağlar

cgit, C diliyle yazılmış bir CGI (common gateway interface) programıdır. Web sunucusu bu programı her istekte bir kez çalıştırır, depoları doğrudan diskten okur ve kendi durumunu saklamaz. Ubuntu 24.04, bu programı universe bileşeninde sunar.

sudo apt update
sudo apt install -y cgit fcgiwrap nginx
sudo install -d -o www-data -g www-data /var/cache/cgit

Programı /etc/cgitrc içindeki depo dizinine yönlendirin:

root-title=Git on example.com
css=/cgit.css
logo=/cgit.png
cache-size=1000
cache-root=/var/cache/cgit
snapshots=tar.gz zip
scan-path=/srv/git

scan-path bu dizini tarar ve bulduğu her depoyu listeler; böylece yeni bir bare repo, ek yapılandırma gerektirmeden görünür hale gelir. cache-size önbelleğe alınan sayfa sayısıdır ve bu değer sıfır olduğu sürece önbellekleme kapalı kalır. Satır eklemeden önce paketinizin /etc/cgitrc içine halihazırda neleri yerleştirdiğini okuyun, çünkü Debian ve Ubuntu paketleri kendi varsayılan ayarlarıyla gelir.

Her girdi, deponun description dosyasının ilk satırını gösterir; bu nedenle yeni oluşturulan bir bare repo kendini Unnamed repository; edit this file 'description' to name the repository. olarak listeler. Bunu her depo için bir kez düzeltin:

echo 'Project X, internal tooling' | sudo -u git tee /srv/git/project.git/description

server {
    listen 80;
    server_name git.example.com;
    root /usr/share/cgit;

    try_files $uri @cgit;

    location @cgit {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
        fastcgi_param PATH_INFO $uri;
        fastcgi_param QUERY_STRING $args;
        fastcgi_param HTTP_HOST $server_name;
        fastcgi_pass unix:/run/fcgiwrap.socket;
    }
}

sudo systemctl enable --now fcgiwrap.socket
sudo nginx -t && sudo systemctl reload nginx
systemctl show fcgiwrap.socket -p Listen

Üzerine inşa etmeden önce bilinmesi gereken iki sınır vardır. cgit salt okunurdur ve giriş özelliği yoktur; bu nedenle scan-path altındaki her şey herkese açıktır: özel depoları bu dizinin dışında tutun veya tüm sitenin önüne HTTP temel kimlik doğrulaması (basic authentication) ekleyin. Ayrıca CGI, web sunucusu kullanıcısı yetkileriyle çalışır; bu nedenle ilgili kullanıcının /srv/git dizinine erişebilmesi ve her depoyu okuyabilmesi gerekir. Kullanıcının giremediği bir dizin, hata vermek yerine boş bir dizin olarak görünür.

Seviye 2: Sorun takibi ve pull request işlemleri için Forgejo veya Gitea

Forgejo ve Gitea aynı mantığa dayanır: kullanıcılar, organizasyonlar, sorun takibi, pull request işlemleri, sürümler, paket kayıt defteri ve yerleşik bir CI sistemi sunan tek bir Go binary dosyası. Kurulumun tamamı binary dosyası ve SQLite veritabanından ibarettir; bu nedenle GitLab'in çalışamayacağı donanımlarda dahi sorunsuz çalışırlar. Aşağıdaki Compose dosyası, Forgejo dokümantasyonunda yer alan ve Ağustos 2026 itibarıyla belirtilen image etiketini kullanan sürümdür.

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:3000 | head -1

curl satırı bir HTTP durum satırı döndürmelidir. İlk kurulum tamamlanmadan önce bu çıktı /install adresine bir yönlendirme olabilir; bu durum servisin çalıştığı anlamına gelir. Eğer container doğrudan kapanıyorsa, bunun yaygın nedeni sahiplik sorunudur: ./forgejo dizini, USER_UID içindeki UID (kullanıcı kimliği) değerine ait olmalıdır; aksi takdirde süreç kendi veri dizinine yazamaz. VPS üzerinde Docker Compose rehberi, bu dosya düzenini ve volume sahiplik kuralını tüm detaylarıyla açıklar.

Kurulum sayfasındaki iki yanıt, clone URL'lerinin çalışıp çalışmayacağını belirler. SSH portu 222 olmalıdır; çünkü Compose dosyası ana makine üzerindeki 222 portunu container içindeki 22 numaralı porta yönlendirir. Ayrıca alan adı, kullanıcıların tarayıcıya yazacağı gerçek isim olmalıdır. Bu ayarlardan herhangi biri hatalı olursa, her depo sayfasında sunulan clone komutu, kopyalayan herkes için başarısız olacaktır. Bu ayarlar daha sonra app.ini dosyasının [server] bölümünde SSH_PORT, SSH_DOMAIN ve ROOT_URL olarak yer alır.

Halka açık bir instance için web portunu yalnızca loopback adresi ('127.0.0.1:3000:3000') üzerinden yayınlayın ve TLS (transport layer security) işlemleri için önüne nginx yerleştirin. Gitea da aynı şekilde gitea/gitea image'ı kullanılarak veya tek bir systemd ünitesi ve bir app.ini dosyası ile tek bir binary olarak kurulabilir; Ağustos 2026 itibarıyla güncel kararlı sürümü 1.27.1'dir.

Mümkün olduğu sürece SQLite kullanmaya devam edin. Bu, instance'ın tek bir süreç ve tek bir dosya olarak kalmasını sağlar ve yeniden başlatma sonrasında ek bir servis yönetimine gerek kalmadan çalışmaya devam eder. PostgreSQL, birden fazla kişi aynı anda yazma işlemi yaptığında maliyetini karşılar; çünkü SQLite yazma işlemlerini sıraya koyar ve uzun süren CI süreçleri sürekli yazma işlemi gerçekleştirir. Her iki proje de mevcut bir instance'ı daha sonra PostgreSQL'e taşıyabildiği için bu kalıcı bir karar değildir.

Forgejo veya Gitea: temel farklar nelerdir

Kökenleri ortaktır. Gitea, 2016 yılında Gogs projesinden çatallanmıştır (fork). 2022 yılının sonlarında Gitea alan adı ve ticari marka üzerindeki kontrol Gitea Ltd adlı bir şirkete geçmiş, bunun üzerine bazı geliştiriciler Codeberg ile birlikte Forgejo projesini başlatmıştır. Forgejo, Almanya'da kayıtlı kâr amacı gütmeyen bir dernek olan Codeberg e.V. tarafından yayımlanmaktadır ve 2024 yılında MIT lisansından GPLv3 (GNU genel kamu lisansı sürüm 3) lisansına geçiş yapmıştır. Gitea, MIT lisansıyla kalmaya devam etmekte ve ticari destekle geliştirilmektedir.

Günlük kullanımda özellik setleri birbirine yakındır. Ancak aralarındaki geçiş yolu kapalıdır. Ocak 2025 tarihli Forgejo v10.0, doğrudan Gitea veritabanını kabul edebilen son sürümdür ve bu da yalnızca Gitea v1.22 veya daha eski sürümler için geçerlidir. Ağustos 2026 itibarıyla Gitea v1.27.1 sürümündedir; dolayısıyla güncel bir Gitea kurulumunun Forgejo'ya desteklenen bir yerinde geçiş yöntemi bulunmamaktadır. Veri girişi yapmadan önce birini seçin ve daha sonraki bir geçişi dışa aktarma ve yeniden içe aktarma süreci olarak değerlendirin.

Seçim yapmak için kısa bir kural: Yönetişim sizin için önemliyse veya projenin kâr amacı gütmeyen bir yapıda kalmasını istiyorsanız Forgejo kullanın. Daha geniş bir kullanıcı tabanı ve ticari destek seçeneği arıyorsanız Gitea kullanın. Her iki proje de açık kaynaklı olarak sürdürülmekte ve sıkça yeni sürümler yayımlamaktadır: Forgejo her üç ayda bir kararlı sürüm ve her yıl bir LTS (uzun süreli destek) sürümü yayımlar; Ağustos 2026 itibarıyla v16.0.2 güncel sürüm, v15.0.6 ise LTS sürümüdür.

Tier 3: GitLab'in hiçbir işlem yapmadan önceki maliyeti

GitLab CE, farklı bir yazılım sınıfına aittir. Tek bir kurulum, birbirleriyle uyumlu çalışan bir servisler bütünüdür: web uygulaması için Puma, arka plan işleri için Sidekiq, PostgreSQL, Redis, depo erişimi için Gitaly ve ön tarafta nginx. Omnibus paketi bunların tümünü bir arada kurar; bu durum kurulumu basitleştirirken bellek kullanım tabanını yükseltir.

GitLab gereksinimleri sayfası, tek düğümlü bir kurulum için temel değer olarak 16 GB RAM ve 8 vCPU belirtirken, bellek kısıtlı ortamlarda alt sınır olarak 8 GB değerini vermektedir. Aynı sayfa, yük altındayken swap kullanımının sunucu performansını ciddi oranda düşürdüğü gerekçesiyle swap özelliğinin devre dışı bırakılmasını önerir. Bunlar Ağustos 2026 itibarıyla yayınlanan rakamlardır ve yıllar içinde artış göstermiştir; bu nedenle sunucu boyutlandırması yapmadan önce ilgili sayfayı tekrar inceleyin.

Bu bütçe karşılığında şunları elde edersiniz: bir container registry, bir paket registry, detaylı izin yönetimi, uyumluluk ve denetim özellikleri ve büyük ölçeklerde test edilmiş bir CI sistemi. Eğer ekibinizde kimse bu listeden bu çeyrekte ihtiyaç duyduğu bir şeyi tanımlayamıyorsa, hiçbir karşılık almadan daha büyük bir VPS için ödeme yapıyorsunuz demektir.

SSH erişim modeli: tek bir git kullanıcısı ve çok sayıda anahtar

Buradaki her katman aynı şekilde kimlik doğrulaması yapar. git adında tek bir Unix hesabı bulunur ve her genel anahtar bu hesabın ~/.ssh/authorized_keys dosyasına eklenir. Kimlik doğrulaması anahtar ile yapılır. Yetkilendirme ise anahtarın önündeki aynı satıra yazdığınız seçeneklerle belirlenir.

Sade bir anahtar satırı, anahtar sahibine o hesabın yapabildiği her türlü yetkiyi verir. Zorunlu bir komut (forced command) ise bu yetkiyi Git ile sınırlar:

restrict,command="git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice@laptop

OpenSSH 7.2 sürümünden beri kullanılabilen restrict, port yönlendirme, aracı yönlendirme (agent forwarding), X11 ve PTY (sözde terminal) tahsisini tek bir kelimeyle devre dışı bırakır. command=, istemcinin talep ettiği her şeyi belirttiğiniz komutla değiştirir; Git, isteğini $SSH_ORIGINAL_COMMAND üzerinden gönderdiği için çalışmaya devam eder.

Bir kod deposu yönetim aracı (forge) bu dosyayı sizin yerinize yazar; katman 0 ile katman 2 arasındaki temel fark budur. Forgejo ve Gitea, authorized_keys dosyasını her kayıtlı anahtar için bir satır olacak şekilde yeniden yazar; her satır, anahtarı veritabanı kimliğiyle tanımlayan zorunlu bir komut içerir:

command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-3",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexamplekeyhere alice

Bu zorunlu komut, paylaşılan tek bir Unix hesabının kullanıcı bazlı yetkilendirmeye dönüşmesini sağlar: key-3, hangi kullanıcının bağlandığını yönetim aracına bildirir ve herhangi bir nesne transferi gerçekleşmeden önce kullanıcıyı depo üzerinde denetler. Yönetim aracı tarafından yönetilen bir sunucuda bu dosyayı manuel olarak düzenlemeyin; dosya veritabanından tekrar yazıldığı için eklediğiniz satır silinecektir. Dağıtım anahtarları (deploy keys) aynı mekanizmayı kullanır: dağıtım anahtarı, genellikle salt okunur olan ve denetimi sshd yerine yönetim aracında yapılan, tek bir depoya kayıtlı sıradan bir SSH anahtarıdır.

İki alışkanlık, yukarıdaki tüm yapılandırmalardan daha önemlidir. Kişi veya makine başına bir anahtar oluşturun, asla paylaşımlı anahtar kullanmayın; çünkü paylaşımlı bir anahtarı iptal etmek, herkes için aynı anda anahtar yenilemeyi gerektirir. Birisi ayrıldığı gün anahtarını kaldırın; çünkü o dosyada kalan eski bir anahtar, kimsenin izlemediği kalıcı bir giriş kapısıdır. Sunucuda iyi SSH anahtar yönetimi, anahtar türlerini ve parolaları kapsar; buradaki tüm bilgiler aynı şekilde geçerlidir. Eğer sunucu yeniyse, depoları üzerine yüklemeden önce yeni bir VPS üzerinde ilk on dakika rehberindeki adımları uygulamak doğru olacaktır.

Kendi Git sunucumda GitHub Actions çalıştırabilir miyim?

GitHub Actions söz dizimi ile yazılmış iş akışlarını çalıştırabilirsiniz. GitHub'ı çalıştıramazsınız. Forgejo Actions, Forgejo v1.21 sürümünden itibaren varsayılan olarak etkinleştirilmiştir ve her depodaki .forgejo/workflows dizininden iş akışı dosyalarını okur. Gitea Actions da aynı şekilde çalışır ve .gitea/workflows dizinini okur. Her ikisi de, yönetici ayarlarından alınan bir belirteç (token) ile örneğinize kaydedilmiş ikinci bir program olan "runner"a ihtiyaç duyar. Yayınlanmış birçok eylem (action) üzerinde değişiklik yapılmadan çalışır; ancak GitHub API'sini çağıran veya GitHub tarafından barındırılan bir altyapı bekleyen hiçbir şey çalışmayacaktır.

İki sonucu göz önünde bulundurun. Runner, her iş için bir container başlatır; bu nedenle bir container motoruna ve kendine ait bir bellek bütçesine ihtiyaç duyar. Bu yüzden, forge ile aynı 1 GB kapasiteli sunucuda barındırılmamalıdır. Ayrıca runner, iş akışı dosyasında ne yazıyorsa onu yürütür; Forgejo belgelerinde açıkça belirtildiği üzere, runner uzaktan kod yürütme (remote code execution) gerçekleştirir. Mümkünse ona ayrı bir ana makine tahsis edin veya en azından yetkisiz bir kullanıcı hesabı ile tek bir depo ile sınırlandırılmış bir kayıt belirteci kullanın.

Depolarınız GitHub üzerinde kalacaksa ve yalnızca hesaplama işlemlerini kendi kontrolünüzdeki donanımda yapmak istiyorsanız, bu farklı adımlar gerektiren farklı bir kurulumdur: kendi kendine barındırılan bir GitHub Actions runner, bir GitHub deposuna bağlanır ve burada anlatılanların hiçbirine ihtiyaç duymaz. Eğer ayrılmanın maliyetini hala değerlendiriyorsanız, GitHub'ın size gerçekte neler sunduğu konusu, Git barındırma hizmetini çevresindeki ağdan ayırarak incelemenizi sağlar.

Yedekleme: depolar durumun yalnızca yarısıdır

Bare bir depo bir dizindir, bu nedenle onu kopyalamak içindeki her şeyi kopyalar. Başka bir makineden alınan mirror clone gerçek bir yedektir ve yerinde güncellenir:

git clone --mirror git@vps.example.com:/srv/git/project.git
cd project.git && git remote update

Bu komut her referansı ve her nesneyi çeker. Sunucu tarafı kancalarını (hooks) veya description dosyasını çekmez, bu nedenle kanca kullanıyorsanız dizinin dosya düzeyinde bir kopyasını da alın.

Bir kod platformu (forge); sorunları, pull request'leri, kullanıcıları, anahtarları ve izinleri veritabanında tutar; yalnızca depoların kopyasını almak tüm bu verileri kaybetmenize neden olur. Her iki proje de veritabanını, depoları, yapılandırmayı ve ekleri tek bir arşiv dosyasına yazan bir dump komutu sunar:

sudo -u git forgejo dump -c /etc/forgejo/app.ini -f /var/backups/forgejo-dump.zip

Docker altında aynı komut container içinde çalıştırılır ve yapılandırma yolu kullanılan imaja bağlıdır, bu yüzden komutu girmeden önce kontrol edin:

docker compose exec server ls /data/gitea/conf
docker compose exec -u git server forgejo dump -c /data/gitea/conf/app.ini

Komutu verilerin sahibi olan kullanıcı ile çalıştırın ve arşivi bu kullanıcının yazma yetkisi olan bir dizine kaydedin. Ardından arşivi sunucudan başka bir yere kopyalayın; çünkü yalnızca yedeklenen makinede bulunan bir yedek, yedek sayılmaz. Geri yükleme, insanların atladığı bir adımdır: şimdi yedek bir makine üzerinde bir dump dosyasını açın; böylece prosedürü bir kesinti anında değil, sakin bir zamanda öğrenmiş olursunuz.

Senaryoya göre seçim

Dizüstü bilgisayarı ve bir VPS'i olan, tarayıcı üzerinden erişime ihtiyaç duymayan tek bir kullanıcı için: SSH üzerinden bare repository kullanımı. Ek bir servis çalışmaz ve yükseltilmesi gereken bir bileşen yoktur.

Aynı senaryo, ancak kodları tarayıcıda okumak ve bağlantı paylaşmak istiyorsanız: cgit ekleyin. Veritabanı gereksinimi yoktur ve arka planda sürekli çalışan bir servis bulunmaz.

Birbirinin kodunu inceleyen ve sorun takibi yapan bir ekip için: 2 GB veya daha fazla RAM ile Forgejo veya Gitea. İş yükü arttığında CI runner'ı ikinci bir sunucuya taşıyın.

Container registry ve denetim izlerine ihtiyaç duyan, sunucu için 16 GB RAM bütçesi olan bir organizasyon için: GitLab. Bu bütçenin altındaysanız kurulum yapmayın.

İlk üç seviye arasında geçiş yapmak kolaydır; çünkü hepsinde repository'ler disk üzerinde standart Git dizinleridir. İhtiyacınızı karşılayan en düşük seviyeden başlayın. Aynı sunucuda başka nelerin yer alabileceğini değerlendiriyorsanız, self-hosting için değerli olan kısa liste, bir Git sunucusunu RAM için yarışan diğer servislerin yanına yerleştirir.

FAQ

1 GB RAM kapasiteli bir VPS, Forgejo veya Gitea çalıştırmak için yeterli mi?

Evet, küçük bir ekip için, SQLite kullanıldığında ve sunucuda başka ağır bir servis bulunmadığında yeterlidir. Gitea belgeleri, küçük ekipler ve projeler için 1 GB RAM ve 2 CPU çekirdeğini genellikle yeterli görmektedir; Forgejo ise Gitea tabanlı bir çatal (fork) olduğu için benzer kaynak gereksinimlerine sahiptir. Bu makineye PostgreSQL veya bir CI runner eklemeyin. Servis kendi günlük kayıtlarında bir hata vermeden kapanıyorsa sudo dmesg -T | grep -i oom komutunu çalıştırın: Çıktıda öldürülen süreci belirten bir satır varsa, bu durum çekirdeğin bellek yetersizliği nedeniyle süreci sonlandırdığını (OOM killer) gösterir. Bu durumda çözüm bir ayar bayrağı değil, daha yüksek kaynaklı bir plana geçmektir.

Forgejo ve Gitea arasındaki fark nedir?

Her iki proje de aynı kod geçmişini ve özelliklerin çoğunu paylaşır. Gitea, 2016 yılında Gogs projesinden çatallanmıştır; Forgejo ise Gitea ticari markasının bir şirkete geçmesinin ardından 2022 yılı sonunda Gitea'dan çatallanmıştır. Forgejo, Almanya merkezli kâr amacı gütmeyen Codeberg e.V. tarafından GPLv3 lisansıyla yayımlanırken, Gitea MIT lisansıyla ve ticari destekle varlığını sürdürmektedir. Pratik fark, geçiş sürecindedir. Ocak 2025 tarihli Forgejo v10.0, doğrudan Gitea veritabanını kabul edebilen son sürümdür ve bu işlem yalnızca Gitea v1.22 veya daha eski sürümler için desteklenmektedir; dolayısıyla güncel bir Gitea kurulumunun doğrudan Forgejo'ya geçişi için desteklenen bir yöntem bulunmamaktadır.

Kendi barındırdığım Git sunucumda GitHub Actions iş akışlarını çalıştırabilir miyim?

Forgejo Actions ve Gitea Actions, .forgejo/workflows ve .gitea/workflows dosyalarından okunan, GitHub Actions YAML sözdizimiyle yazılmış iş akışlarını çalıştırır. Ayrı bir runner programı kurup bunu sunucunuza kaydetmeniz gerekir. Yayımlanmış birçok eylem (action) değişiklik yapılmadan çalışsa da, GitHub API'sini çağıranlar çalışmayacaktır. Runner, depolarınızdaki rastgele kodları çalıştırır ve her iş için ayrı bir container başlatır; bu nedenle runner için ayrı bir sunucu veya en azından ayrı ve yetkisiz bir kullanıcı tanımlayın. Runner'ı, halihazırda Git sunucusunu çalıştıran 1 GB RAM kapasiteli bir sunucuda çalıştırmayın.

Kendi barındırdığım Git sunucusunu nasıl yedeklerim?

Çıplak (bare) depolar için, başka bir makineden git clone --mirror komutu tüm referansları ve nesneleri kopyalar, git remote update komutu ise bu yansımayı günceller. Forgejo veya Gitea için depolar durumun yalnızca bir parçasıdır; çünkü sorunlar (issues), çekme istekleri (pull requests), kullanıcılar ve anahtarlar veritabanında tutulur. Yerleşik yedekleme aracı olan sudo -u git forgejo dump -c /etc/forgejo/app.ini komutunu veya Docker kurulumları için aynı komutu container içinde kullanın. Oluşturulan arşivi sunucudan başka bir yere kopyalayın ve prosedürün çalıştığından emin olmak için yedek dosyasını bir kez yedek bir makinede geri yükleyerek test edin.