Kendi VPS'inizde CI/CD
Derlemeler için ayrı bir sunucu; bulut dakikaları yetmediğinde, derlemeler yavaş olduğunda ya da iç kaynaklara erişim gerektiğinde kendini amorti eder. Ancak çalıştırıcı depodaki her kodu çalıştırır; ayarlarındaki bir hata canlı sunucuya ve tüm gizli bilgilere erişim açar. GitLab ve GitHub çalıştırıcılarının nasıl işlediğini, ne kadar kaynak gerektirdiklerini, SSH ile nasıl dağıtım yapılacağını ve anahtarların nerede saklanacağını ele alıyoruz.
CI/CD, her değişiklikten sonra kodun otomatik olarak derlenmesi, test edilmesi ve yayına alınmasıdır. İş hattının tanımı depoda durur (.gitlab-ci.yml ya da .github/workflows/ içindeki dosyalar), onu ise çalıştırıcı (runner) yürütür: GitLab'den veya GitHub'dan işleri alıp başlatan bir program. Çalıştırıcıyı hizmetin kendisinden kullanabilir ya da kendi VPS'inize kurabilirsiniz.
Kendi çalıştırıcılarınız: GitLab ve GitHub
GitLab Runner resmi depodan kurulur (kurulum kılavuzu) ve CI/CD ayarlarındaki bir token ile projeye ya da gruba kaydedilir. Kayıt sırasındaki asıl seçim yürütücüdür (executor). shell komutları doğrudan sunucunun sisteminde, docker ise her iş için yeni bir konteynerde çalıştırır. GitLab belgelerine göre shell'de her derleme için temiz bir ortam yoktur ve işler, çalıştırıcının token'ı ve başkalarının önbelleği dahil tüm dosya sistemini görür. Projelerin çoğu için docker yürütücüsü uygundur.
Kendi GitHub Actions çalıştırıcınız depo ya da organizasyon ayarlarından eklenir (GitHub belgeleri). Kullanımı ücretsizdir, yalnızca sunucu için ödeme yaparsınız. Çalıştırıcı GitHub'a kendisi 443 numaralı porttan HTTPS ile bağlanır; sunucuda gelen bağlantılar için port açmanız gerekmez. Çalıştırıcı 30 gün boyunca güncellenmezse GitHub ona iş vermeyi bırakır (kendi çalıştırıcılarınız için başvuru belgesi).
Açık kaynak projeler için önemli bir kısıtlama var. GitHub, kendi çalıştırıcılarınızın herkese açık depolarla neredeyse hiçbir zaman kullanılmaması gerektiğini yazıyor: herkes bir pull request açıp sunucuda kendi kodunu çalıştırabilir. Herkese açık kod için bulut çalıştırıcılarında kalın, kendi sunucunuzu ise özel depolara bağlayın.
Derleme ve canlı sunucu neden ayrı olmalı?
- Yük. Ön yüz derlemesi ya da derleme işlemi tüm çekirdekleri dakikalarca meşgul eder. Çalıştırıcı sitenin sunucusundaysa site bu sırada daha yavaş yanıt verir.
- Güvenlik. Çalıştırıcı, bir yüklenicinin gönderdiği dal dahil her daldan gelen kodu çalıştırır. GitLab belgelerine göre shell yürütücüsü sunucu ve ağ için yüksek risk taşır, privileged moddaki bir konteyner ise işe sunucuda tam root yetkisi verir. Aynı sunucuda müşteri veritabanlı bir site çalışıyorsa bu veritabanı her işe açıktır.
- Disk alanı. Docker imajları, bağımlılık önbelleği ve yapıtlar (artifacts) onlarca gigabayt yer kaplar. Disk dolduğunda yalnızca derleme değil, site de durur.
Küçük bir ekip için düzen: çalıştırıcı için bir VPS, canlı site için ayrı bir VPS ve gerekirse test ortamı için üçüncüsü (bununla ilgili Geliştirici için VPS: test ortamları yazısı). Çalıştırıcı canlı sunucuya yalnızca hazır çıktıyı teslim eder.
Derleme için ne kadar kaynak gerekir?
Ölçüt olarak GitHub'ın bulut çalıştırıcılarını alın. Başvuru belgesine göre özel depolar için standart Linux çalıştırıcısı 2 çekirdek, 8 GB bellek ve 14 GB SSD'ye, herkese açık depolar için 4 çekirdek ve 16 GB belleğe sahip. Derlemeleriniz bu kaynaklara sığıyorsa aynı özellikte bir VPS en az onun kadar iyi iş görür; hızlı disk ve saklanan önbellekle genellikle daha hızlıdır.
- Çekirdekler. Paralel derleme ve testler tüm çekirdekleri kullanır. Derlemeler art arda geliyorsa 4 çekirdek, ikiye göre kuyruğu belirgin biçimde kısaltır.
- Bellek. Ön yüz derlemesi, Java veya Go derlemesi ve konteynerde veritabanıyla çalışan testler iş başına 4–8 GB ister. Eşzamanlı iş sayısı GitLab Runner'ın
config.tomldosyasındakiconcurrentparametresiyle belirlenir (parametrelerin açıklaması); bir işin belleğini bu sayıyla çarpın. - Disk. Bağımlılıkların kurulumu binlerce küçük dosya demektir ve NVMe'de daha hızlı ilerler. En az 50 GB alın ve Docker önbelleğini zamanlanmış olarak temizleyin:
docker builder prunevedocker image prune. Diskin neden önemli olduğu NVMe mi SSD mi: web sitesi için fark var mı? yazısında ele alınıyor. - Sanallaştırma. docker yürütücüsü için KVM gerekir: OpenVZ'de Docker kısıtlamalarla çalışır ya da hiç çalışmaz (KVM mi OpenVZ mi: hangisini seçmeli?).
accsly.io kataloğuna göre Kasım 2026 itibarıyla 2 çekirdekli ve 4 GB bellekli bir VPS paketinin ortanca fiyatı ayda yaklaşık 21 dolar, bu paketlerin dörtte biri 12,5 dolardan ucuz. 4 çekirdek ve 8 GB için ortanca 40 dolar, dörtte biri 22 dolardan ucuz. 8 çekirdek ve 16 GB için 80 dolar. Fiyatlar katalogda rubleyle tutulur ve 7 Kasım 2026 kuruyla (1 dolar = 82,14 ruble) çevrilip yuvarlanmıştır. Uygun paketler CI/CD çalıştırıcıları için VPS seçkisinde, GitLab'in kendisini de kuruyorsanız GitLab için VPS seçkisinde toplanmış.
Saatlik ücretli derleme sunucusu
Çalıştırıcıya yalnızca derlemeler sürerken, genellikle iş gününün birkaç saatinde ihtiyaç duyulur. accsly.io kataloğuna göre Kasım 2026 itibarıyla VPS paketi olan 2.248 sağlayıcıdan 173'ü saatlik ücretlendirme, 298'i sunucu oluşturup silmek için API, 96'sı ise ikisini birden sunuyor. Saatlik ücretlendirme sunan sağlayıcılarda 4 çekirdek ve 8 GB'lık paketin ortanca fiyatı ayda yaklaşık 51 dolar, yani saatte yaklaşık 0,07 dolar. 22 iş gününün her birinde 3 saat çalışan bir sunucu, aylık fiyat yerine yaklaşık 4,6 dolara mal olur.
Bunun elle müdahale gerektirmeden işlemesi için sunucu derlemeden önce API ile oluşturulur, sonra silinir. GitLab Runner bulut eklentileriyle bu şekilde ölçeklenebilir; GitHub ise tek bir iş alıp silinen tek kullanımlık (ephemeral) çalıştırıcıları öneriyor. Güvenlik açısından ek bir kazanç: sonraki iş öncekinin izlerini görmez. Saatlik ücretlendirmenin aylık ödemeden ne zaman daha kârlı olduğu Saatlik ücretlendirme ne zaman kârlı? yazısında ele alınıyor; paketler Saatlik ücretli VPS ve API'li VPS seçkilerinde.
Kısıtlı anahtarla SSH üzerinden dağıtım
Derlemeyi canlı sunucuya taşımanın en basit yolu SSH'tir: dosyaların rsync ile kopyalanması ya da yeni sürümü çekip hizmeti yeniden başlatan bir komut. CI'daki anahtarın tüm sunucunun anahtarı haline gelmemesi için:
- Ayrı bir kullanıcı. sudo yetkisi olmayan ve yalnızca site dizinine hakkı bulunan bir
deploykullanıcısı oluşturun. Bir hizmetin yeniden başlatılması gerekiyorsa sudoers'ta yalnızca o tek komuta izin verin. - Ayrı bir anahtar. Yalnızca CI için bir anahtar çifti oluşturun ve onu başka hiçbir yerde kullanmayın.
- authorized_keys içinde kısıtlamalar. Anahtarın önüne
restrict(port yönlendirme ve terminal yasağı) ve anahtarın yalnızca derleme sunucusundan çalışması içinfrom="çalıştırıcının adresi"ekleyin.command="…"parametresi anahtarın yalnızca tek bir dağıtım betiğini çalıştırmasına izin verir (man authorized_keys). - Sunucunun doğrulanması. Canlı sunucunun anahtar parmak izini bir CI değişkeninde saklayın ve bağlanmadan önce
known_hostsdosyasına yazın. DoğrulamayıStrictHostKeyChecking=noile kapatmayın: bu durumda çalıştırıcı, kendini sizin sunucunuz gibi gösteren herhangi bir sunucuya bağlanır.
Dağıtım sırasında sitenin kesintiye uğramaması için yeni sürüm eskisinin yanında başlatılır ve sağlık kontrolünü geçtiğinde trafik ona aktarılır; önceki sürüm geri dönüş için yerinde kalır. Bunun tek bir sunucuda nasıl kurulacağı Sunucuyu kesintisiz güncelleme yazısında anlatılıyor.
Canlı sunucunun temel korumasının (yalnızca anahtarla giriş, güvenlik duvarı, fail2ban) nasıl yapılacağı VPS satın aldıktan sonra ilk 10 adım: güvenlik yazısında anlatılıyor. Dağıtım anahtarıyla yapılan girişlerin kayıtları bir şeyler ters gittiğinde işinize yarar; bunları nerede arayacağınızı Sunucuda loglar ve giriş denetimi yazısında bulabilirsiniz.
Gizli bilgiler nerede saklanmalı?
- Depoda değil. Veritabanı parolaları, API token'ları ve dağıtım anahtarları CI değişkenlerinde saklanır. GitLab'de bir değişken korumalı yapılabilir (yalnızca korumalı dalların ve etiketlerin iş hatlarında kullanılabilir) ve maskelenebilir (değeri iş logunda
[MASKED]ile değiştirilir). Maskelenen değer, boşluk içermeyen tek bir satır olmalı ve en az 8 karakter uzunluğunda olmalıdır (GitLab belgeleri). - Her gizli bilgi için tek bir değer. GitHub, JSON veya YAML biçimindeki bir gizli bilginin loglarda daha kötü gizlendiği konusunda uyarıyor; her değeri ayrı saklayın ve gizli bilgileri derleme loguna yazdırmayın.
- Test ortamı ve canlı sunucu için ayrı gizli bilgiler. Canlı sunucunun dağıtım anahtarı herhangi bir geliştirici dalından değil, yalnızca korumalı daldan erişilebilir olmalıdır.
- Kalıcı token'lar yerine kısa ömürlü token'lar. Bulut hizmetleri için GitHub OpenID Connect'i öneriyor: iş, derleme süresince geçerli bir token alır ve kalıcı bir anahtar saklamak gerekmez.
- Rotasyon. CI ayarlarına erişimi olan biri ekipten ayrıldığında ve derleme logunun her sızıntısından sonra anahtarları değiştirin.
Canlı sunucunun ayarlarını içeren .env dosyası sunucuda bir kez, 600 izinleriyle oluşturulur ve dağıtım onun üzerine yazmaz. Böylece deponun tam bir kopyası bile canlı veritabanının parolalarını içermez.