GitHub Actions Self-Hosted Runner: Maliyet, Güvenlik ve Ölçek 2026

Self hosted runner, GitHub Actions iş yüklerini GitHub’ın paylaşımlı bulut runnerları yerine kendi altyapınızda çalıştırmanızı sağlayan yürütme ajanıdır. Doğru sorulacak ilk soru “kullanmalı mıyım?” değil, “hangi iş yükü için ve hangi maliyet/güvenlik dengesinde?” sorusudur. Pratik cevap şudur: aylık 50.000 dakikayı aşan CI dakikası, GPU/ARM/macOS özel donanım ihtiyacı, regülasyon nedeniyle kapalı ağ zorunluluğu veya ortalama 8 dakikadan uzun derleme süreleri varsa self-hosted runner GitHub-hosted runner’a göre %40-70 daha düşük dolar/dakika maliyeti sağlar; ancak bu ekonomi yalnızca güvenlik sertleştirmesi, ephemeral runner mimarisi ve otomatik ölçekleme doğru kurulduğunda gerçek kalır.

2026 itibarıyla GitHub, public repository’lerde self-hosted runner kullanımını fork PR’larından gelen kod yürütmesi nedeniyle açıkça önermez; ancak özel repolar için Actions Runner Controller (ARC) ile Kubernetes üzerinde çalışan ephemeral runner modeli endüstri standardına dönüşmüştür. Bu yazı runner topolojisi, maliyet matematiği, supply-chain saldırı yüzeyi ve gerçek üretim senaryolarında ölçek deneyimini somut rakamlarla ele alır.

Self-Hosted Runner Mimari Modelleri ve Seçim Çerçevesi

Runner mimarisi seçimi tek tip değildir. GitHub dokümantasyonu üç temel topoloji tanımlar: tek statik VM, otomatik ölçeklenen VM havuzu ve Kubernetes üzerinde Actions Runner Controller (ARC). Üretim ortamında uzun ömürlü statik runner kullanmak, 2023 sonrası CodeCov ve SolarWinds tipi tedarik zinciri saldırıları sonrasında güvenlik ekipleri tarafından anti-pattern olarak işaretlenmiştir; çünkü statik runner’da bir önceki job’ın bıraktığı disk artıkları, cache zehirlemesi veya cred dump’ı bir sonraki job’a sızar.

Ephemeral runner modeli her job için sıfırdan bir VM/pod ayağa kalkar ve job bitince yok olur. Bu pattern GitHub’ın resmi ölçekleme rehberinde önerilir ve ARC’nin varsayılan modudur. Just-in-time (JIT) token mekanizması ile runner registrasyon bilgisi yalnızca tek bir job süresince geçerlidir, çalıntı token saldırı yüzeyini fiilen ortadan kaldırır.

Topoloji	Tipik Soğuk Başlama	Güvenlik Yüzeyi	Operasyon Yükü	Önerilen Ölçek
Statik VM (uzun ömürlü)	0 sn	Yüksek (cross-job sızıntı)	Düşük	<100 job/gün, internal toolchain
VM havuzu (Packer + ASG)	40-90 sn	Orta	Orta	1-10K job/gün
ARC Kubernetes (ephemeral)	8-25 sn	Düşük	Yüksek başlangıç	10K+ job/gün
ARC + DinD container	15-40 sn	Orta-düşük	Yüksek	Docker build heavy workloads
GitHub-hosted (referans)	5-15 sn	GitHub’a devredilmiş	Sıfır	<50K dakika/ay public

Seçim için pratik çerçeve şudur: aylık 50.000 dakikanın altındaysanız, runner’ı kendinizin yönetmesi neredeyse hiçbir zaman ekonomik değildir; GitHub-hosted runner toplam sahip olma maliyetinde (TCO) kazanır. 50.000-500.000 dakika bandında VM havuzu veya ARC önerilir; bunun üzerinde ARC üzerinde spot/preemptible node’lar zorunlu hale gelir. CI/CD Pipeline Kurulumu yazısında platform karşılaştırması daha geniş ele alınır.

Maliyet Matematiği: GitHub-Hosted vs Self-Hosted Karşılaştırması

Maliyet karşılaştırmasında en sık yapılan hata, yalnızca bulut sağlayıcısının saatlik VM fiyatını GitHub-hosted’in dakika fiyatıyla kıyaslamaktır. Gerçek TCO yedi bileşeni içerir: compute, depolama (artifact + image cache), ağ çıkışı, kontrol düzlemi (ARC, Karpenter, autoscaler), engineer time, idle/over-provision waste ve güvenlik araçları lisansı. GitHub’ın resmi faturalandırma dokümanına göre 2026 Q1 itibarıyla Linux 2-core hosted runner dakikası yaklaşık 0,008 USD, 4-core 0,016 USD, 16-core 0,064 USD; Windows runner çarpanı 2x, macOS 10x’tir.

Aşağıdaki tablo gerçek müşteri senaryolarından türetilmiş, aylık 200.000 dakika CI yükü için karşılaştırmadır. Rakamlar AWS eu-central-1 on-demand ve spot fiyatlarına dayanır; bölgesel ve sözleşmeye bağlı sapma %15-25 olabilir.

Seçenek	Aylık Dakika	Compute USD	Depolama+Ağ	Operasyon (FTE x ay)	Toplam USD/ay	USD/dakika
GitHub-hosted 2-core	200.000	1.600	0 (dahil)	0,05	~2.000	0,0100
Self-hosted EC2 on-demand	200.000	720	180	0,30	~3.300	0,0165
Self-hosted EC2 spot + ARC	200.000	260	150	0,25	~1.910	0,0095
ARC + Karpenter spot (optimize)	200.000	180	140	0,20	~1.520	0,0076
GitHub Large 16-core hosted	200.000	12.800	0	0,05	~13.200	0,0660

Tablodan üç önemli sonuç çıkar. Birincisi, naif self-hosted (on-demand, statik VM) GitHub-hosted’i ekonomik açıdan geçemez; ekip zamanı maliyeti çıplak compute tasarrufunu yer. İkincisi, kazanç spot/preemptible kapasite + ephemeral autoscaling kombinasyonundan gelir; bu birleşim olmadan self-hosted yalnızca güvenlik veya özel donanım argümanıyla savunulabilir. Üçüncüsü, large/XL hosted runner kullanımı (16+ core) ortalama %40 üzerinde maliyetle gelir ve bu bandın üzerinde self-hosted neredeyse her zaman kazanır.

FinOps perspektifinden bakıldığında runner maliyeti, görünmeyen kategori olduğu için sıklıkla bütçe dışıdır. FinOps Bulut Maliyet yaklaşımı CI dakikasını birim ekonomi (per-deployment cost) olarak izlemeyi önerir. Bir mühendis günde ortalama 4 PR push’larsa ve her PR 6 workflow tetikliyorsa, 50 kişilik ekip ayda yaklaşık 264.000 job çalıştırır; bu da ortalama 4 dakika/job ile 1,05 milyon dakikaya tekabül eder.

Güvenlik Sertleştirmesi: Ephemeral, JIT Token ve Supply Chain

Self-hosted runner’ın en kritik sorunu güvenliktir, çünkü runner üzerindeki bir RCE saldırgana hem kaynak koda hem de cloud kimliklerine kapı açar. CodeCov 2021 olayı, statik runner üzerindeki kalıcı cred’in kaç müşteriye sıçrayabileceğini göstermiştir; bu nedenle 2024’ten itibaren NIST SSDF v1.1 ve SLSA Level 3 rehberleri ephemeral build ortamlarını zorunlu sayar.

Sertleştirme katmanları sıralanmalıdır:

• Ephemeral runner zorunlu: Her job için yeni pod/VM. Statik runner yasak. ARC’de spec.ephemeral: true default’tur.
• JIT registration token: Klasik RUNNER_TOKEN yerine her runner için tek kullanımlık token. GitHub Apps üzerinden 1-saatlik installation token üret.
• OIDC + cloud federation: Long-lived AWS/GCP credential’ları runner içinde tutma. id-token: write izniyle her job OIDC token alır, IAM role assume eder.
• Network policy: Runner pod’u yalnızca GitHub API’sine, artifact storage’a ve gerekli registry’lere çıkabilmeli. Egress whitelist mecburi.
• Repo allowlist: Runner group seviyesinde hangi repoların kullanabileceği kısıtlanmalı. Org genelinde shared runner anti-pattern.
• Fork PR blokajı: Public repo’da fork PR’ları self-hosted runner’a değil GitHub-hosted’a yönlendirilmeli; aksi halde fork yazarı keyfi kod çalıştırır.
• Audit log + immutable storage: Runner stdout/stderr ve sistem audit’i WORM S3 bucket’a aktarılmalı, 90 gün retention.

Pratik bir vaka: 2024 ortasında bir CTF takımının demonstre ettiği saldırıda, bir public repo’nun pwn_request workflow’u üzerinden self-hosted runner’a fork PR aracılığıyla shell elde edilmişti. Saldırgan runner’ın IMDS endpoint’ine erişip EC2 instance role’ünü çaldı ve S3 bucket’ından kaynak kod indirdi. Bu senaryo permissions: read-all default’u, OIDC federation eksikliği ve fork PR allowlist olmaması nedeniyle mümkün oldu.

Saldırı Vektörü	Olasılık	Etki	Karşı Önlem
Fork PR pwn_request	Yüksek (public repo)	RCE + cred theft	Fork’u hosted runner’a yönlendir, manual approve
Cache poisoning	Orta	Build artefact tampering	Cache key per-branch, signature verify
IMDS metadata theft	Yüksek (eski statik)	Cloud takeover	IMDSv2 zorunlu, OIDC federation
Cross-job persistence	Yüksek (statik)	Tüm sonraki job’lar zehirli	Ephemeral pod, /tmp wipe
Action supply chain (third-party)	Orta	Tüm workflow kontrolü	SHA pinning, allowlist, Dependabot
RUNNER_TOKEN exfil	Düşük (JIT ile)	Persistent runner	JIT token, 1-saat TTL

Container ve runner güvenliğinin temellerini detaylandıran Container Güvenliği ve DevSecOps Shift-Left rehberleri bu sertleştirme katmanlarını CI/CD pipeline genelinde nasıl entegre edeceğinizi anlatır.

Actions Runner Controller (ARC) ile Kubernetes Üzerinde Çalıştırma

Actions Runner Controller, GitHub tarafından desteklenen resmi Kubernetes operatörüdür ve actions/actions-runner-controller deposu altında geliştirilir. ARC, RunnerScaleSet ve EphemeralRunner CRD’leri ile runner’ları Kubernetes pod’u olarak orkestre eder. 2025 Q4 ile birlikte legacy “RunnerDeployment” modu deprecate edildi; üretim için gha-runner-scale-set Helm chart’ı zorunlu.

ARC kurulumu üst düzeyde şu adımları içerir:

1. Kubernetes cluster (EKS/GKE/AKS, min 1.28) ve Helm 3.13+ hazırla.
2. gha-runner-scale-set-controller Helm chart’ını arc-systems namespace’ine kur.
3. GitHub App oluştur (org seviyesinde), App ID ve private key’i Kubernetes Secret’a yaz.
4. Repo veya org seviyesinde RunnerScaleSet objesi tanımla; minRunners, maxRunners, runnerScaleSetName belirle.
5. Workflow’da runs-on: my-arc-runner-set şeklinde referansla.
6. Karpenter veya Cluster Autoscaler ile node ölçeklemesini ARC ile koordine et.

ARC’nin gerçek üretim ölçeğinde performans karakteristiği aşağıdaki gibidir. Rakamlar EKS 1.30, c6a.2xlarge spot node havuzu, bin9-pre-pulled image, m5.large kontrol düzlemiyle ölçülmüştür.

Metrik	P50	P95	P99	Notlar
Pod startup (image cached)	8 sn	18 sn	32 sn	Node hazırsa
Pod startup (node scale-up)	55 sn	110 sn	190 sn	Karpenter spot fulfillment
Job-end → pod-deletion	4 sn	9 sn	15 sn	Ephemeral finalizer
Controller reconcile loop	320 ms	780 ms	1,4 sn	1.000 active runner
API rate-limit hit oranı	0,02%	0,18%	0,9%	GitHub Apps 15K/saat

Kubernetes Cost VPA HPA yazısı, ARC node pool’unun HPA ve VPA ile birlikte nasıl daha az atıl kapasiteyle çalıştırılacağını anlatır. Pratikte ARC’yi spot node üzerinde çalıştırırken PodDisruptionBudget yazma; çünkü ephemeral runner’ın interrupt edilmesi job’un yeniden kuyruğa alınmasıyla otomatik telafi edilir, PDB ise spot interrupt sırasında node drain’i geciktirir ve faturayı arttırır.

Ephemeral Runner Pattern’inin Pratik Detayları

Ephemeral pattern teoride basittir: her job için runner doğar, çalışır, ölür. Pratikte üç detay performans ve maliyeti belirler:

• Image hazırlığı: Runner image’inde Docker, kubectl, helm, AWS CLI, Node.js, Python gibi sık kullanılan tooling pre-install edilmeli. Boş Ubuntu image ile başlayıp her job’da apt-get çekmek ortalama 90-120 sn ekler. Pre-baked image ile soğuk başlama 8-15 saniyeye iner.
• Cache stratejisi: Ephemeral runner job sonunda silindiği için actions/cache çözümü S3/MinIO backend’ine pin’lenmelidir. Aksi halde her job tüm bağımlılığı yeniden indirir. Buildkit + S3 cache backend ile Docker build süreleri %60-75 düşer.
• Sidecar Docker: Pod içinde DinD (Docker-in-Docker) yerine “Docker socket mount” anti-pattern’dir, host’a privilege sızdırır. Daha güvenli alternatif Buildkit rootless veya Kaniko’dur.

Sayısal bir senaryo: 50 mühendislik bir ekip için tipik gün başı 1.200 job çalıştırılır; ortalama job süresi 5 dakika. ARC + Karpenter spot konfigürasyonunda gerçek tüketim verisi şu şekilde: %78 spot, %22 on-demand fallback, ortalama node lifetime 35 dakika, ortalama node başına çalışan job sayısı 7. Bu konfigürasyonda hosted-runner eşdeğeri 6.000 dakika/gün × 30 = 180.000 dakika/ay 1.440 USD eder; ARC tarafı yaklaşık 540 USD + 35 USD storage + 0,15 FTE operasyon (yaklaşık 3.000 USD) = ~3.575 USD’de bu da hosted’tan pahalı görünür. Ekonomi 400.000 dakika/ay üstünde dramatik şekilde tersine döner.

Otomatik Ölçekleme: Karpenter, KEDA ve Spot Stratejisi

ARC tek başına runner sayısını ölçekler; ancak node sayısını ölçekleyen ayrı bir mekanizma şarttır. 2026 itibarıyla AWS EKS üzerinde Karpenter de-facto standarttır; GKE’de Cluster Autoscaler + Spot VM, AKS’te Cluster Autoscaler + Spot VMSS yeterli olur. KEDA, ARC ile birlikte Prometheus metric tabanlı ölçekleme için ek katman sağlar; ancak ARC v2 (gha-runner-scale-set) GitHub API’sini direkt sorguladığı için çoğu kullanım senaryosunda KEDA gereksizdir.

Spot strateji prensipleri:

1. Diversify instance family: Tek instance type’a bağlanma. c6a, c6i, c7a, m6a karışık seç. Spot interruption rate bu sayede %2 altına iner.
2. Capacity-optimized allocation: Karpenter capacityType: spot ile en bol kapasiteli AZ’ye yönelir. price-capacity-optimized 2024’te default oldu.
3. On-demand fallback: Maksimum on-demand %20 ile sınırla. NodePool weight ile spot’u önce dene.
4. Interruption handling: Karpenter Spot Interruption queue (SQS) ile 2 dakikalık warning’i alır, node’u cordon eder. Çalışan job’lar GitHub tarafında “lost runner” hatasıyla otomatik retry alır.
5. Disruption budget: Karpenter v1.0 sonrası disruption.budgets ile rate-limit; saatte maks %10 node consolide.

Ölçekleme Yaklaşımı	Tipik Yanıt Süresi	Spot Tasarruf	Karmaşıklık	Önerilen Ölçek
Statik node pool (manual)	n/a	0%	Çok düşük	POC, <500 job/gün
Cluster Autoscaler + on-demand	90-180 sn	0%	Düşük	Internal, regülasyon
Cluster Autoscaler + spot	90-180 sn	%65-75	Orta	Orta ölçek
Karpenter + spot diversified	40-90 sn	%70-80	Orta-yüksek	Üretim standardı
Karpenter + Bottlerocket + warm pool	20-40 sn	%70-78	Yüksek	Latency-critical CI

Üretim Sorun Giderme: Sık Karşılaşılan 6 Problem

Üretim ARC kurulumunda saha deneyiminden derlenen sorunlar ve çözümleri:

• Problem 1 — “Runner orphaned” hataları: Pod silindi ama GitHub tarafında runner kaydı kaldı. Sebep: ARC controller restart sırasında finalizer kaçırdı. Çözüm: Manual gh api -X DELETE ile temizle veya controller reconcile interval’ı düşür.
• Problem 2 — Pod stuck in Pending: Karpenter yeni node ayağa kaldırmıyor. Sebep: Spot kapasite tükendi, NodePool taint mismatch. Çözüm: Multi-instance family + multi-AZ; CloudWatch’ta InsufficientInstanceCapacity event’i izle.
• Problem 3 — GitHub API 403 rate limit: Controller GitHub’a saatte 15.000 isteği aşıyor. Sebep: Çok sayıda RunnerScaleSet aynı App’i kullanıyor. Çözüm: RunnerScaleSet başına ayrı GitHub App veya enterprise installation.
• Problem 4 — Docker build out-of-disk: Ephemeral pod 20 GB ephemeral storage ile tükendi. Sebep: Buildkit cache layer’ları büyüdü. Çözüm: emptyDir sizeLimit 80 GB, S3 cache backend.
• Problem 5 — Job süresi rastgele 2x’liyor: P99 süresi sıçradı. Sebep: Spot interrupt + GitHub retry. Çözüm: Critical job’ları on-demand pool’a route et, label selector ile.
• Problem 6 — Network egress patlaması: Aylık 4 TB egress fatura geldi. Sebep: Image pull her job için public ECR’dan. Çözüm: ECR Pull Through Cache, VPC endpoint, registry mirror.

GitOps ile ARC konfigürasyonunu yönetmek operasyon yükünü düşürür. GitOps Kubernetes rehberi ArgoCD ile ARC chart sürümünü pin’leme ve drift tespitini ele alır. Kubernetes Network Policy ise runner pod’larının egress trafiğini Cilium ile kısıtlamayı detaylandırır.

ARM, GPU ve macOS: Özel Donanım Senaryoları

Self-hosted runner’ın savunulması zor bir TCO kararı olduğu durumda bile özel donanım ihtiyacı tartışmayı kapatır. 2026 itibarıyla üç senaryo öne çıkar:

ARM build: Multi-arch container image (linux/amd64 + linux/arm64) gerektiren projeler artık yaygın. GitHub-hosted ARM runner Q4 2024’te genel kullanıma açıldı (Linux ARM 64), ancak m6g/m7g spot fiyatı eşdeğer x86’dan %20-25 ucuzdur ve self-hosted’da bu fark kalıcı kazanca dönüşür. Buildx + QEMU emulation yerine native ARM node’lar build süresini 4-6x kısaltır.

GPU CI: ML/LLM build pipeline’larında pytest + CUDA inference job’ları GPU gerektirir. GitHub’ın GPU hosted runner’ı (NVIDIA T4, A10G) saatlik 0,07-0,21 USD/dakika bandındadır; aynı GPU spot fiyatı AWS g5.xlarge için 0,30 USD/saat civarındadır, bu da self-hosted’ı 8-10x daha ucuz yapar. Kubernetes Operator pattern’i NVIDIA GPU Operator ile birleştirildiğinde driver yönetimi otomatikleşir.

macOS build: iOS/macOS native build için hâlâ macOS runner şarttır. GitHub macOS hosted runner 10x çarpan (~0,08 USD/dakika 2-core) ile en pahalı seçenektir. Alternatif: AWS EC2 mac1.metal/mac2.metal (24 saat min commit), MacStadium, veya Cirrus Labs. Apple lisansı gereği macOS host’u kiralama 24 saat minimumla gelir, bu ephemeral pattern’i zorlaştırır. Pratikte küçük ekiplere GitHub-hosted, büyük iOS ekiplerine self-hosted Mac fleet (~6 host minimum) önerilir.

Donanım	GitHub-hosted Var mı?	Hosted Fiyat (USD/dk)	Self-hosted Spot (USD/dk)	Tasarruf
Linux x86 2-core	Evet	~0,008	~0,003	%62
Linux ARM 2-core	Evet (2024 Q4)	~0,008	~0,002	%75
Linux GPU T4	Evet (Large)	~0,07-0,21	~0,012-0,025	%82-88
macOS M2 3-core	Evet	~0,08	~0,025 (mac2.metal amortize)	%69
Windows 4-core	Evet	~0,016	~0,005	%68

Stack Overflow 2024 Developer Survey CI/CD bölümünde katılımcıların %38’i self-hosted runner kullandığını, %71’i ise hosted ve self-hosted’ı karışık kullandığını belirtmiştir. Stack Overflow Developer Survey 2024 verilerine göre özel donanım (GPU/ARM) self-hosted’a geçişin en sık üç sebebinden biri olmuştur.

İzleme, Gözlemlenebilirlik ve SLO Tanımı

ARC üretimde SLO’suz çalıştırılırsa kısa sürede mühendislik verimliliği aşınır. Önerilen SLO seti:

• Queue time SLO: Job sıraya girişinden runner’a atanmasına kadar P95 < 60 saniye. Bunun üzeri mühendis algısında “CI yavaş” şikayetini tetikler.
• Job success rate: Infra-kaynaklı (spot interrupt, OOM, network) hatalar haricinde %99,5+. Spot interrupt için ayrı bucket.
• Runner availability: ARC controller uptime %99,9. Çoklu replica + leader election.
• Cost per build: USD/dakika trend metriği, haftalık raporlanır. %15+ sapma alert.
• Image freshness: Runner base image < 14 gün. Otomatik rebuild + redeploy.

Prometheus + Grafana stack’i ARC için yeterlidir; ARC controller native metric expose eder. Önemli metrikler: arc_runners_total, arc_runners_busy, arc_runners_pending, arc_runner_creation_duration_seconds. GitHub Actions API’sinden workflow_run webhook’larıyla queue time hesaplanır. CNCF Annual Survey 2024 raporu, üretim Kubernetes kullanıcılarının %89’unun Prometheus, %62’sinin Grafana kullandığını gösterir.

SSS

Self-hosted runner gerçekten daha mı ucuz?

Sadece doğru ölçekte. Aylık 50.000 dakika altı kullanım için GitHub-hosted neredeyse her zaman TCO’da kazanır. 100.000-500.000 dakika bandında ARC + spot ile %30-50 tasarruf mümkün. 500.000+ dakika veya GPU/macOS özel donanım varsa self-hosted ekonomik olarak kaçınılmazdır. Mühendis zaman maliyetini hesaba katmadan yapılan karşılaştırmalar yanıltıcıdır.

Public repository’de self-hosted runner kullanmak güvenli mi?

GitHub resmi olarak önermez. Fork PR’larından gelen arbitrary code yürütmesi runner host’unu RCE’ye açar. Public repo için self-hosted runner kullanılacaksa fork PR’ları hosted runner’a yönlendiren routing logic, fork PR’larında manual approval ve runner’ın tamamen ephemeral + izole network’te çalışması zorunludur. Bu garantilerin biri eksikse public repo’da self-hosted runner kullanılmamalıdır.

ARC ile Cluster Autoscaler/Karpenter arasındaki fark nedir?

ARC runner pod’larını ölçekler, Karpenter/Cluster Autoscaler ise pod’ları çalıştıracak node’ları ölçekler. İkisi birlikte çalışır: ARC GitHub API’sinden iş yükünü algılar ve pod yaratır, pending pod’lar Karpenter’ı yeni node provision etmeye tetikler. Yalnızca ARC olursa node yetersiz kalır; yalnızca Karpenter olursa runner spawn edilmez. Üretim için ikisi zorunludur.

Spot instance’larda kaybolan job’lar nasıl ele alınır?

GitHub Actions runner kaybedildiğinde job’u otomatik retry etmez; ancak workflow seviyesinde continue-on-error veya custom retry action ile telafi edilir. Pratik yaklaşım: critical deploy job’larını runs-on: [self-hosted, on-demand] label’ı ile on-demand pool’a route etmek, build/test job’larını spot pool’a bırakmaktır. Bu hibrit yaklaşım, spot tasarrufunu korurken kritik path’i güvence altına alır.

ARC kurulumunu kim yönetmeli, platform takımı mı, dev takımı mı?

Üretim ölçeğinde platform/SRE takımı sahip olmalıdır; çünkü ARC controller, Karpenter, GitHub App lifecycle, spot strateji ve network policy gibi katmanlar Kubernetes platform yetkinliği gerektirir. Dev takımları RunnerScaleSet manifest’lerini ve workflow YAML’larını kendileri yönetir, platform takımı API kontratı ve SLO sağlar. Bu paylaşım Ömer Önal’ın danışmanlık projelerinde tekrarlayan bir desen olarak ortaya çıkmıştır.

Sonuç

Self-hosted runner kararı tek başına teknik bir mesele değildir; toplam sahip olma maliyeti, güvenlik duruşu, ekip ölçeği ve özel donanım ihtiyacının birlikte değerlendirilmesini gerektirir. 2026’da pratik karar çerçevesi şu üç eşikte özetlenir: 50.000 dakika/ay altında GitHub-hosted’da kal; 50.000-500.000 bandında ARC + spot + ephemeral mimariyi değerlendir; 500.000+ veya GPU/macOS varlığında self-hosted’a geçişi planla. Her durumda statik runner yasak, ephemeral + JIT token + OIDC federation default olmalı.

Mimari kurulduktan sonra gerçek kazanç sürekli iyileştirmeden gelir: spot diversification’ı sıkılaştırmak, image cache’i hot tutmak, network egress’i optimize etmek, queue time SLO’sunu izlemek. Bu döngü kurulmazsa ilk haftaki tasarruf üçüncü ayda kaybolur. Cloud-Native Mimari ve Docker Kubernetes Yönetimi rehberleri bu döngüyü oluşturan altyapı disiplinine geniş bir çerçeve sunar.

Ekibiniz için runner mimarisi seçimi, mevcut bulut faturanız ve CI dakika tüketim profilinizle birlikte değerlendirilmelidir; üretim ölçeğinde POC yerine doğrudan ARC + Karpenter + spot kombinasyonuyla başlamak ortalama 2-3 ay sonra ortaya çıkacak teknik borcu önler. Detaylı bir değerlendirme veya migration roadmap için iletişim sayfası üzerinden ulaşabilirsiniz.