Self-Hosted GitLab, Jira ve DevOps Araçlarını VPS’te Barındırmak: Kaynak Planlama ve Güvenlik Rehberi

Self-hosted DevOps araçlarını neden VPS’te toplamalısınız?

Bir yazılım ekibinin kalbi artık sadece uygulama sunucusunda değil; kaynak kodunun tutulduğu Git sunucusunda, işlerin takip edildiği proje yönetim aracında ve CI/CD boru hatlarında atıyor. GitLab, Jira, Jenkins, SonarQube, container registry, artifact depoları… Tüm bu DevOps ekosistemini dış servislere yaymak yerine, kontrollü bir şekilde kendi VPS altyapınızda toplamak ciddi avantajlar getiriyor: veri egemenliği, KVKK/GDPR uyumu, maliyeti öngörülebilir kılma, şirket içi entegrasyon özgürlüğü ve gelişmiş güvenlik mimarileri.

Bu yazıda DCHost ekibi olarak, GitLab, Jira ve benzeri DevOps araçlarını self-hosted olarak bir veya birden fazla VPS üzerinde barındırırken neleri planlamanız gerektiğini konuşacağız. Odak noktamız iki başlık olacak: kaynak planlama (CPU, RAM, disk, ağ) ve güvenlik (ağ katmanı, erişim kontrolü, yedek ve izleme). Gerçekçi ekip büyüklüklerine göre örnek senaryolar, mimari karar noktaları ve pratik önerilerle ilerleyeceğiz. Amaç, “bir VPS alıp GitLab’ı kurdum, gerisi gelir” seviyesinden, üretim ortamına yakışır bir DevOps platformuna geçmenize yardımcı olmak.

Hangi DevOps araçlarını VPS’te self-host etmek mantıklı?

Önce hangi bileşenleri gerçekten kendi altyapınızda çalıştırmak istediğinizi netleştirelim. Tipik bir ekip için self-host edilen DevOps araçları şöyle görünebilir:

• Kaynak kod yönetimi: GitLab, Gitea, Bitbucket Server vb.
• Proje ve issue takibi: Jira, YouTrack, Redmine vb.
• CI/CD: GitLab CI, Jenkins, GitHub Actions runner’ları, diğer self-host runner’lar.
• Container/artefact: Docker registry, Maven/NPM/Composer repository, artifact depoları.
• Kalite ve güvenlik: SonarQube, SAST/DAST araçları, dependency check platformları.
• Gözlemlenebilirlik: Log ve metrik toplama, dashboard ve alarm sistemleri.

Bu listedeki her aracı aynı VPS’e yığmak zorunda değilsiniz. Örneğin sadece GitLab + GitLab Runner ile başlayıp, Jira’yı ikinci bir VPS’e, monitoring’i üçüncü bir VPS’e taşıyabilirsiniz. Benzer kapasite planlama mantığı, yüksek trafikli web projeleri için de geçerli; örneğin WooCommerce, Laravel ve Node.js’de doğru VPS kaynaklarını seçme rehberinde kullandığımız yaklaşımın aynısını burada DevOps araçları için uygulayacağız.

Kaynak planlama: GitLab, Jira ve arkadaşları kaç vCPU, ne kadar RAM ister?

Self-host DevOps platformlarının en sık yapılan hatası, “nasıl olsa iç ekip kullanıyor” diyerek kısıtlı kaynaklı VPS’te boğmak. Özellikle GitLab ve Jira, veritabanı ve arka plan işçileriyle birlikte hafif uygulamalar değildir. Kabaca üç senaryo üzerinden ilerleyelim.

Senaryo 1: Küçük ürün ekibi (5–10 geliştirici)

Bu senaryoda elinizde şu bileşenler olduğunu düşünelim:

• GitLab (kaynak kod, basic CI)
• 1–2 GitLab Runner (CI işleri)
• Jira (issue ve proje takibi)

Temel ve güvenli bir başlangıç için pratik yaklaşım:

• Uygulama VPS’i: GitLab + Jira
• Runner VPS’i: GitLab Runner (ve gerekirse başka CI ajanları)

Kaba kaynak önerisi:

• Uygulama VPS’i: 4 vCPU, 8–12 GB RAM, en az 200 GB NVMe SSD
• Runner VPS’i: 4 vCPU, 8 GB RAM (eşzamanlı pipeline sayısına göre artar)

Runner’ların CPU kullanımı, CI aşamalarında derleme, test, docker build gibi işlere bağlı olduğundan, burada sabit bir sayıdan çok eşzamanlı job sayısını hesaba katmalısınız. Örneğin aynı anda en fazla 3 pipeline koşuyorsa, her biri için ortalama 1–1.5 vCPU düşecek şekilde hesap yapabilirsiniz.

Senaryo 2: Orta ölçekli ekip (20–50 geliştirici)

Bu seviyede kullanıcı sayısıyla beraber, pipeline yoğunluğu da ciddi şekilde artar. Bileşenleriniz aşağıdaki gibi olabilir:

• GitLab (yoğun kullanım, merge request review süreçleri)
• Jira (çoklu proje, board ve raporlama)
• Container registry (CI çıktılarının saklandığı Docker registry)
• SonarQube veya benzeri kod kalite aracı

Bu noktada hem kaynak hem de güvenlik açısından aşağıdaki ayrım mantıklıdır:

• VPS-1: GitLab ana uygulama
• VPS-2: PostgreSQL (GitLab + Jira veritabanları), Redis vb. ortak servisler
• VPS-3: Jira uygulaması
• VPS-4: CI Runner’lar, Docker registry, SonarQube gibi ağır CI bileşenleri

Kaba kaynak önerisi (gerçek sahadan gördüklerimize dayalı bir başlangıç noktası):

• VPS-1 (GitLab): 6–8 vCPU, 16 GB RAM, 300+ GB NVMe SSD
• VPS-2 (DB + Redis): 4–6 vCPU, 16–24 GB RAM, NVMe + güçlü IOPS
• VPS-3 (Jira): 4–6 vCPU, 12–16 GB RAM, 100–200 GB NVMe
• VPS-4 (CI + registry): 8+ vCPU, 16+ GB RAM, 300+ GB NVMe

Özellikle veritabanı VPS’inin disk IOPS kapasitesi kritik. Yüksek yazma/okuma yoğunluğu, yanlış boyutlandırılmış bir diskte tüm sistemi yavaşlatabilir. NVMe tabanlı VPS paketlerinin farkını detaylıca anlattığımız NVMe VPS hosting rehberinde bu konunun pratik testlerini görebilirsiniz.

Senaryo 3: Büyüyen SaaS ekibi (50+ geliştirici, çoklu proje)

Bu ölçekte artık tek VPS’ler yerine çoklu VPS ve gerektiğinde dedicated sunucular düşünmek mantıklı hale gelir. Burada mantık, “her rol için ayrı kaynak havuzu” yaklaşımıdır:

• GitLab uygulama düğümleri (ölçeklenebilir sayıda)
• Veritabanı replikasyon (PostgreSQL primary-replica veya cluster)
• CI/Runner filosu (çok sayıda göreli küçük VPS, gerektiğinde otomatik scale)
• Monitoring ve loglama (ayrı bir gözlemlenebilirlik kümesi)

DCHost tarafında bu tipi yükler için genellikle NVMe VPS + gerektiğinde dedicated sunucu kombinasyonu öneriyoruz. Karar noktasında, Dedicated sunucu mu VPS mi, hangisi işinize daha uygun? yazısında anlattığımız yaklaşımı DevOps yüklerinize de birebir uygulayabilirsiniz.

Disk kapasitesi ve IOPS hesaplama

GitLab ve Jira için disk planlarken sadece “şu an kaç GB repo var?” sorusunu değil, aşağıdakileri de düşünmelisiniz:

• Ortalama repo boyutu ve büyüme hızı
• Binary dosyalar, attachment’ler (Jira issue ekleri, GitLab LFS dosyaları)
• Container registry ve artefact depolarının büyüme trendi
• Yedeklerin tutulduğu lokal disk alanı (snapshot + full backup)

Pratik bir başlangıç formülü: bugünkü toplam depolama ihtiyacınızı 3 ile çarpın. 1x canlı veri, 1x yedek, 1x büyüme payı. Uzun vadede object storage gibi çözümlere geçerken, medya ve artefact verisini dışarı taşımak da mümkün; bu yaklaşımı object storage ile medya offload stratejisi yazımızda detaylı anlattık, aynı mantığı container image ve artefact’lar için de uyarlayabilirsiniz.

Mimari tasarım: Hepsi tek VPS’te mi, yoksa mikro mimari mi?

İş sadece “kaç vCPU, kaç GB RAM” meselesi değil; bu kaynakları nasıl böldüğünüz de en az o kadar önemli. İki temel yaklaşım var:

• Monolit VPS: Tüm DevOps araçları tek güçlü VPS’te.
• Rollere göre ayrılmış VPS’ler: Uygulama, veritabanı, CI runner, registry ve monitoring için ayrı sunucular.

Monolit VPS: Ne zaman mantıklı?

Aşağıdaki koşullar sağlanıyorsa monolit bir VPS ile başlayabilirsiniz:

• 10 kişiden küçük ekip
• CI yükü sınırlı (günde birkaç pipeline, ağır docker build yok)
• Jira kullanımı hafif, raporlama yoğun değil

Böyle bir durumda 8 vCPU, 16 GB RAM, 300–400 GB NVMe SSD’li güçlü bir VPS, tüm yükü bir süre taşıyabilir. Ama tasarımınızı daha sonra bileşenleri ayırabileceğiniz şekilde yapmak önemli: örneğin veritabanını Docker içinde değil, doğrudan ayrı bir diskte, dizin yapısı ve yedekleme senaryoları belli olacak biçimde planlamak.

Rollere göre ayrılmış mimari: Neden daha sağlıklı?

Gerçek hayatta tıkanma noktaları genellikle:

• CI runner’lar CPU ve disk I/O’yu sömürürken GitLab arayüzünün yavaşlaması
• Jira raporlarının veritabanını kilitleyip GitLab performansını etkilemesi
• Container registry disk tüketiminin kontrolsüz büyümesi

Bunları önlemenin en pratik yolu, en azından şu üç rolü ayırmaktır:

• Uygulama VPS’i: GitLab ve/veya Jira
• Veritabanı VPS’i: PostgreSQL (ve gerekirse Redis, RabbitMQ vb.)
• CI/Runner VPS’i: GitLab Runner, Jenkins ajanları, docker builder’lar

Böylece CI yükü arttığında sadece runner VPS’lerini büyütür veya sayısını artırırsınız; GitLab ve Jira kullanıcı deneyimi daha öngörülebilir kalır.

Container ve Docker kullanımı

GitLab, Jira ve benzeri araçları Docker ile izole etmek, güncelleme ve rollback süreçlerini çok kolaylaştırır. Tek VPS üzerinde bile container kullanarak her servisi izole etmek, güvenlik ve yönetilebilirlik açısından büyük kazanç sağlar. Bu konuyu adım adım anlattığımız Docker ile VPS’te izole uygulama barındırma rehberinde anlattığımız prensipleri, DevOps araçlarınıza birebir uygulayabilirsiniz.

Güvenlik mimarisi: DevOps altyapısını kale gibi yapmak

Self-host DevOps platformu, firmanızın en kritik sırlarının durduğu yer: kaynak kod, erişim anahtarları, CI pipeline’larında kullanılan API token’ları… Dolayısıyla buraya yapılacak bir sızıntı, çoğu zaman ana uygulama sunucunuzdan bile daha riskli.

Ağ katmanı: Firewall, sadece gerekli portlar ve yönetim ağı

İlk kural basit: Gereksiz her port kapalı olacak. En temel açılımlar:

• GitLab/Jira HTTP(S): 80/443 (mümkünse sadece 443)
• SSH yönetimi: 22 (veya farklı port) – sadece yönetici IP’lerine kısıtlama
• Veritabanı portları (5432 vb.): Sadece ilgili uygulama VPS’lerinin erişebileceği özel ağ segmentinde açık

Güvenlik duvarını doğru kurgulamak için ufw, firewalld veya doğrudan iptables/nftables kullanabilirsiniz. Detaylı kurulum ve iyi pratikler için VPS sunucularda güvenlik duvarı yapılandırma rehberine göz atmanızı öneririm.

SSH erişimi ve yetki yönetimi

DevOps araçlarını yöneten ekip genellikle sistem yöneticileri ve lead geliştiricilerden oluşur. Bu kişilere SSH erişimi verilirken:

• Parola ile giriş tamamen kapatılmalı
• Yalnızca SSH anahtarı (public key) ile girişe izin verilmeli
• Her kullanıcı için ayrı sistem hesabı tanımlanmalı
• sudo yetkileri hassas şekilde sınırlandırılmalı

Çoklu proje ve ekipler için kullanıcı, grup ve sudo mimarisini nasıl tasarlayacağınızı, Linux VPS’te kullanıcı, grup ve sudo mimarisi yazımızda ayrıntılı anlattık. DevOps VPS’leriniz için de birebir aynı yaklaşımı kullanabilirsiniz.

HTTPS, TLS ve güvenlik başlıkları

GitLab ve Jira, varsayılan olarak HTTPS destekler; ancak sertifika yönetimi ve modern TLS ayarlarını doğru yapmak sizin sorumluluğunuzdadır. Önerimiz:

• Let’s Encrypt veya kurumsal SSL sertifikası ile tüm trafiği 443 üzerinden zorunlu hale getirin
• Nginx veya Caddy gibi bir reverse proxy ile SSL terminasyonu ve HSTS/CSP gibi HTTP güvenlik başlıklarını yönetin
• Eski ve güvensiz TLS sürümlerini kapatın, TLS 1.2+ ve mümkünse TLS 1.3 kullanın

HTTP güvenlik başlıklarını (HSTS, CSP, X-Frame-Options vb.) nasıl kurmanız gerektiğini ayrıntılı biçimde anlattığımız HTTP güvenlik başlıkları rehberi, GitLab ve Jira gibi panelleri internete açarken elinizin altında olması gereken bir kontrol listesi sunuyor.

Secrets ve erişim anahtarları yönetimi

En sık yapılan hata, CI pipeline’larında kullanılan access token, SSH private key, API anahtarları gibi bilgileri .env dosyalarında veya Git repo içinde tutmak. DevOps altyapınızda mutlaka şunları düşünmelisiniz:

• Secrets’ları şifreli bir kasa veya secrets manager içinde saklamak
• CI runner’lara environment variable ile geçerken minimum yetki prensibine uymak
• Düzenli anahtar rotasyonu yapmak ve eski anahtarları iptal etmek

Bu konuda daha ileri seviyede bir yaklaşımı VPS’te secrets yönetimi rehberinde anlattık; orada anlattığımız prensipleri GitLab, Jira ve CI boru hatlarınıza uyarlamak, güvenlik seviyenizi bir anda yukarı çeker.

Yedekleme ve felaket kurtarma

DevOps altyapısında kaybetmeyi göze alamayacağınız iki temel veri tipi var:

• Git reposu ve issue’lar (GitLab + Jira verileri)
• CI/CD konfigürasyonları, pipeline tanımları, secrets referansları

Yedek planınızı kurgularken şu başlıkları netleştirin:

• Günlük veritabanı dump + haftalık tam snapshot
• Repo ve dosya sisteminin periyodik rsync/backup arşivleri
• Yedeklerin farklı bir DCHost veri merkezinde veya object storage üzerinde saklanması
• 3-2-1 kuralı (3 kopya, 2 farklı ortam, 1 kopya farklı lokasyon) ve periyodik geri yükleme testleri

Bu konuyu uygulamaya dökmek için, 3-2-1 yedekleme stratejisi yazımızı DevOps ortamınıza uyarlayabilirsiniz.

Operasyon tarafı: Otomasyon, CI/CD ve izleme

Self-host DevOps platformunun en büyük avantajlarından biri, tam kontrol. Bu kontrolü her adımı elle yaparak değil, olabildiğince otomasyonla kullanmak gerekiyor.

Altyapıyı kodla yönetmek: Terraform ve Ansible

GitLab ve Jira gibi kritik sistemlerde, aynı ortamı tekrar kurabilmek (disaster anında veya staging ortamı için) çok değerlidir. Bunun için:

• VPS oluşturma, ağ ve güvenlik kurallarını Terraform benzeri araçlarla tanımlayın
• Sunucu içi konfigürasyonları (Nginx, PostgreSQL, GitLab/Jira config) Ansible playbook’larıyla yönetin

Bu yaklaşımı pratik örneklerle anlattığımız Terraform ve Ansible ile VPS otomasyonu yazımız, DevOps altyapınızı da “tek tuşla tekrar üretilebilir” hale getirmenin güzel bir referansı.

CI/CD’den VPS’e dağıtım: Otomatik ve sıfır kesintiye yakın

GitLab Runner veya başka CI araçlarıyla build ettiğiniz uygulamaları, yine self-host VPS’lerinize otomatik şekilde dağıtmak istiyorsunuz. Burada:

• Blue-Green veya canary deployment gibi stratejilerle sıfıra yakın kesinti hedefleyebilirsiniz
• rsync, sembolik sürümler ve systemd servisleriyle basit ama sağlam bir dağıtım boru hattı kurabilirsiniz

Bu konuda pratik bir yol haritasını, GitHub Actions ile VPS’e otomatik deploy yazımızda anlattık; GitHub Actions yerine GitLab CI veya başka bir CI aracı kullansanız bile yaklaşım aynı.

İzleme, log ve alarm: Sorunları kullanıcıdan önce görmek

GitLab ve Jira gibi araçlar yavaşladığında, geliştirici ekibin verimliliği anında düşer. Bu yüzden:

• CPU, RAM, disk I/O ve ağ kullanımını metrik bazlı izleyin
• Uygulama loglarını merkezi bir yerde toplayın (ör. Loki, ELK, benzeri çözümler)
• Uptime ve response time için harici bir izleme aracıyla endpoint’leri takip edin

Temel metrikleri ve araçları tanıttığımız VPS kaynak kullanımı izleme rehberi, DevOps VPS’leriniz için hangi sinyallere bakmanız gerektiğini netleştirmenize yardımcı olacaktır.

DCHost üzerinde self-hosted DevOps için pratik yol haritası

Toparlayalım; GitLab, Jira ve diğer DevOps araçlarını DCHost VPS altyapısında self-host etmek istiyorsanız, adım adım şöyle ilerleyebilirsiniz:

1. Ekip profilini çıkarın: Geliştirici sayısı, günlük commit/pipeline sayısı, repo boyutları.
2. Mimariyi seçin: Küçük ekipler için monolit güçlü VPS, orta ve üst ölçek için rol bazlı çoklu VPS.
3. Kaynakları boyutlandırın: GitLab/Jira için CPU/RAM’i, veritabanı için IOPS’i ciddiye alın; NVMe diskleri tercih edin.
4. Güvenlik temelini kurun: Firewall, SSH anahtarları, TLS/SSL, kullanıcı ve sudo mimarisi.
5. Yedek ve DR planı oluşturun: 3-2-1 kuralı, periyodik restore testleri, farklı lokasyonda saklanan yedekler.
6. Otomasyon ve izleme ekleyin: Terraform/Ansible ile tekrar üretilebilir altyapı, Prometheus/Grafana veya benzeri ile metrik ve alarm.

DCHost olarak, ister NVMe VPS, ister dedicated sunucu, isterseniz de colocation üzerinden kendi fiziksel sunucularınızı barındırın; DevOps altyapınızı planlarken doğru kaynak ve mimariyi seçmeniz için teknik ekibimizle birlikte çalışabilirsiniz. İsterseniz küçük bir pilot ortamla başlayıp, gerçek kullanım metriklerine göre büyüyen bir mimariye doğru evrimleştirmek de mümkün. Önemli olan, ilk günden “nasıl olsa iç kullanım” diye bakmayıp, kritik bir üretim altyapısı kurduğunuz gerçeğini gözden kaçırmamanız.

Bir sonraki adımda, mevcut ekip büyüklüğünüzü ve araç listenizi çıkarın; bu yazıdaki senaryoları temel alarak kabaca CPU, RAM ve disk ihtiyacınızı hesaplayın. Sonrasında bunu DCHost VPS veya dedicated seçenekleriyle eşleştirerek, yıllarca güvenle üzerinde çalışabileceğiniz, sürdürülebilir bir self-hosted DevOps platformu inşa edebilirsiniz.