2026'da Gitea Nasıl Self-Host Edilir: Repository'ler, SSH ve Güvenli Yükseltme

Daha önce Gitea'yı self-host etmeyi denediyseniz şu can sıkıcı duruma muhtemelen aşinasınızdır: Arayüz açılır, ancak ROOT_URL localhost clone bağlantıları oluşturur veya SSH portu yönlendirilmez. Container'ı yeniden oluşturmak, URL'ler, state ve bağımlılıklar arasındaki uyumsuzluğu nadiren çözer.

Bu rehberde tek bir somut tamamlanma ölçütü kullanıyoruz: HTTPS ve SSH üzerinden clone etmek, bir commit ve LFS nesnesi push'lamak, bir issue açmak ve ayrı olarak register edilmiş bir Actions runner üzerinde bir job çalıştırmak. Her yapılandırma tercihi, yeşil bir container badge'ine göre değil, bu ölçüte göre değerlendiriliyor.

Gitea'daki tüm kalıcı verileri bulun

İlk gerçek kayıt oluşturulmadan önce state'i listeleyin: repository'ler, LFS nesneleri, ekler, yapılandırma ve veritabanı. Bootstrap işleminden önce /data yolunu mount edin, zararsız örnek veriler yazın ve bu yolun gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Mount işlemini doğrulamak için zararsız veriler yazın, Gitea'yı değiştirin ve verileri yeniden okuyun.

Snapshot'lar hızlı rollback için değerlidir, ancak host veya volume ortadan kalktığında bağımsız bir yedek gerekir. Sabitlenmiş image ile boş bir ortama geri yükleme yapın ve repository'lerin fsck kontrolünden geçtiğini, LFS nesnelerinin indirilebildiğini, issue'ların, release'lerin ve kullanıcı izinlerinin yedekleme öncesindeki state ile eşleştiğini doğrulayın. Bu iki kurtarma mekanizmasını birbirinden ayrı tutmak için kalıcı volume'ler ve snapshot'lar rehberini kullanın.

Değiştirilebilir bir Gitea container'ı oluşturun

Aşağıdaki komut, tüm harici servisleri provision ediyormuş gibi davranmadan container sınırını görünür kılar.

docker run -d \
  --name gitea \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v gitea-data:/data \
  -e GITEA__security__SECRET_KEY=replace-with-a-long-random-value \
  gitea/gitea:latest

Ingress'i açmadan önce çözümlenen environment değerlerini, mount'ları ve listener'ı inceleyin. Daha yoğun bir kurulum için Postgres veya MySQL bağlantı ayarlarını, gerekiyorsa SSH route'unu ekleyin; private servisler için private isimler kullanın. Başarılı bir launch, docker ps çıktısında Up göründüğünde değil, HTTPS ve SSH üzerinden clone edebildiğinizde, bir commit ve LFS nesnesi push'layabildiğinizde, bir issue açabildiğinizde ve ayrı olarak register edilmiş bir Actions runner üzerinde bir job çalıştırabildiğinizde tamamlanır.

Gitea'yı bağımlılıklarından ayırın

Gitea'da process health ile product health birbirinden ayrıdır. Port 3000 yanıt veriyor olabilir, ancak kullanıcıya sunulan transaction hâlâ başarısız olabilir. Gitea'nın network contract'ı, daha yoğun bir kurulum için Postgres veya MySQL ve gerekiyorsa bir SSH route'udur. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Gitea'ya kapsamı sınırlandırılmış bir service credential verin.

Anlamlı yapılandırma değişikliklerinden sonra şu readiness çalışmasını kullanın: HTTPS ve SSH üzerinden clone edin, bir commit ve LFS nesnesi push'layın, bir issue açın ve ayrı olarak register edilmiş bir Actions runner üzerinde bir job çalıştırın. Pahalı external check'leri liveness probe'larının dışında tutun; böylece bir provider kesintisi restart loop'a neden olmaz. Capacity çalışmaları, sıradan sayfa istekleri yerine repository sayısını, Git object packing'i, LFS storage'ı, veritabanı latency'sini ve runner workload'unu izlemelidir; bu, Gitea'nın gerçek yükünü sayfa isteklerinden daha doğru yansıtır.

TLS kolaydır; oluşturulan URL'ler o kadar kolay değildir

Gitea için tek bir HTTPS hostname yayınlayın; ham 3000 portunu private tutun. ROOT_URL ve SSH_DOMAIN değerlerini, kullanıcıların gerçekten clone ettiği adreslere ayarlayın. Bu sayede browser'ların ve API client'larının birbiriyle yarışan iki farklı adres öğrenmesi engellenir.

Temiz bir client'tan, çalıştığı bilinen transaction'ı çalıştırın ve başarısız olan ilk request'i inceleyin. DNS veya TLS hatalıysa custom-domain rehberini kullanın. Route'un çalıştığı kanıtlandıktan sonra “ROOT_URL localhost clone bağlantıları oluşturuyor veya SSH portu yönlendirilmiyor” durumunu ayrı bir application diagnosis olarak ele alın.

Gitea deployment'ını uçtan uca doğrulayın

Gitea için ilk kullanıcı trafiğini acceptance test olarak kullanmayın. Zararsız örnek state hazırlayın ve “HTTPS ve SSH üzerinden clone et, bir commit ve LFS nesnesi push'la, bir issue aç ve ayrı olarak register edilmiş bir Actions runner üzerinde bir job çalıştır” işleminin tamamını yürütün. Çalıştırmayla ilişkili tam public URL'yi, sonucu, image referansını ve log aralığını not edin.

Container'ı değiştirin ve verileri yeniden oluşturmadan işlemi tekrarlayın. Ardından boş bir host üzerinde kurtarma yapın; kurtarma koşulu, repository'lerin fsck kontrolünden geçmesi, LFS nesnelerinin indirilebilmesi ve issue'ların, release'lerin ve kullanıcı izinlerinin yedekleme öncesindeki state ile eşleşmesidir. Her geçişte sıradan sayfa istekleri yerine repository sayısını, Git object packing'i, LFS storage'ı, veritabanı latency'sini ve runner workload'unu gözlemleyin; idle container metrikleri yerine transaction'ın kötüleşmesini temel alan bir alert tanımlayın.

Son bir kontrol kasıtlı olarak başarısız olmalıdır: Test identity'sinin daha yoğun bir kurulum için Postgres veya MySQL'e ve gerekiyorsa SSH route'una erişimini geçici olarak engelleyin. Ortaya çıkan Gitea mesajının, veri silmeyi veya sonsuz bir restart'ı tetiklemek yerine ilgili sınırı belirlediğini doğrulayın. Geçerli koşulu geri yükleyin ve aynı örnek transaction'ın başarıyla tamamlandığını doğrulayın. Bu kısa çalışmayı release checklist'inde tutun.

Riskli Gitea değişikliğini prova edin

Gitea için bir process yerine transaction'ı izleyin: HTTPS ve SSH üzerinden clone edin, bir commit ve LFS nesnesi push'layın, bir issue açın ve ayrı olarak register edilmiş bir Actions runner üzerinde bir job çalıştırın. Alert'in kısıtlanan bileşeni belirlemesi için latency ve error rate'i, sıradan sayfa istekleri yerine repository sayısı, Git object packing'i, LFS storage'ı, veritabanı latency'si ve runner workload'u ile birlikte değerlendirin.

Upgrade provası; schema migration'larının, repository hook'larının, package'ların ve üçüncü taraf runner'larının aşamalı bir Gitea upgrade'i gerektirdiğini kapsamalıdır. Production replacement işleminden önce geri yükleme, migration ve transaction'ı çalıştırın. ROOT_URL localhost clone bağlantıları oluşturuyorsa veya SSH portu yönlendirilmiyorsa startup'ı yeşile çevirmek için verileri silmeyin; version, variable'lar, mount'lar ve dependency erişilebilirliğini bu sırayla karşılaştırın.

Gitea'nın değerli kısmını koruyun

İlk login'den sonra anonim bir ziyaretçinin, sıradan bir kullanıcının ve bir administrator'ın neler yapabildiğini ayrı ayrı inceleyin. Gitea'da kaçınılması gereken hata, installer'ı veya ilk admin hesabını gerekenden uzun süre erişilebilir bırakmaktır. Hedeflenen policy; bootstrap sonrasında installer'ı kapatmak, site administration'ı kısıtlamak ve runner registration token'larını kısa ömürlü tutmaktır.

GITEA__security__SECRET_KEY değerini Gitea'daki rolüne uygun şekilde ele alın: hassas değerleri Git dışında tutun, rotation etkilerini dokümante edin ve production'da hiçbir zaman public bir örneği kullanmayın. Dependency hesaplarını insan hesaplarından ayrı tutun, mümkün olduğunda kullanılmayan egress'i engelleyin ve etkilenen işi sıradan sayfa istekleri yerine repository sayısı, Git object packing'i, LFS storage'ı, veritabanı latency'si ve runner workload'u ile sınırlayın.

Dockup Gitea için neleri otomatikleştirmeli?

Gitea için Dockup route'u ve TLS certificate'ını oluşturabilir, mount'ları koruyabilir, secret'ları iletebilir ve daha yoğun bir kurulum için Postgres veya MySQL'i ve gerekiyorsa SSH route'unu private networking üzerinde konumlandırırken deployment'ı Dockup'a veya bağlı sunuculara yapabilir.

Release gate yine somut Gitea transaction'ıdır: HTTPS ve SSH üzerinden clone etmek, bir commit ve LFS nesnesi push'lamak, bir issue açmak ve ayrı olarak register edilmiş bir Actions runner üzerinde bir job çalıştırmak. Ayrıca restore koşulunu da doğrulayın: repository'ler fsck kontrolünden geçmeli, LFS nesneleri indirilebilmeli ve issue'lar, release'ler ile kullanıcı izinleri yedekleme öncesindeki state ile eşleşmelidir. Bu iki kontrol, deployment'ın çalışıp çalışmadığını ve kurtarılıp kurtarılamayacağını gösterir.

Sık sorulan sorular

Production deployment'ı için Gitea'nın nelere ihtiyacı vardır?

Gitea container'ını tek bir HTTPS origin üzerinden 3000 portuna route edin. Destekleyici network gereksinimi, daha yoğun bir kurulum için Postgres veya MySQL ve gerekiyorsa bir SSH route'udur. HTTPS ve SSH üzerinden clone edemediğiniz, bir commit ve LFS nesnesi push'layamadığınız, bir issue açamadığınız ve ayrı olarak register edilmiş bir Actions runner üzerinde bir job çalıştıramadığınız sürece Gitea'yı hazır kabul etmeyin.

Gitea'daki hangi veriler yedeklemeye dahil edilmelidir?

/data yolunu kalıcı hâle getirin ve repository'leri, LFS nesnelerini, ekleri, yapılandırmayı ve veritabanını aynı recovery manifest'ine dahil edin. Temiz bir Gitea restore işlemi yalnızca repository'ler fsck kontrolünden geçtiğinde, LFS nesneleri indirilebildiğinde ve issue'lar, release'ler ile kullanıcı izinleri yedekleme öncesindeki state ile eşleştiğinde başarılıdır.

Reverse proxy arkasında Gitea için HTTPS gerekir mi?

Public Gitea origin'i için HTTPS kullanın ve 3000 portunu internal route üzerinde tutun. Gitea ayarını doğru uygulayın: ROOT_URL ve SSH_DOMAIN değerlerini, kullanıcıların gerçekten clone ettiği adreslere ayarlayın. Gitea için HTTPS, credentials'ı veya kullanıcı içeriğini aktarım sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Gitea upgrade'i nasıl test edilmelidir?

Mevcut Gitea state'ini izole bir deployment'a restore edin, aday version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Schema migration'ları, repository hook'ları, package'lar ve üçüncü taraf runner'ları aşamalı bir Gitea upgrade'i gerektirdiği için bu noktalara özellikle dikkat edin. Data migration ve rollback sınırı anlaşılana kadar önceki Gitea image'ını koruyun.