sGTM Hosting Karar Matrisi: Cloud Run, Stape ve Self-host Karşılaştırması

Önceki yazıda sGTM kurulum adımlarını Cloud Run, Stape ve Docker self-host üzerinden anlattım. Bu yazı aynı konunun karar tarafı: hangi senaryoda hangi hosting, self-host için production-ready Caddy pattern’ı, ajans multi-client kurulumu ve Cloudflare Workers’ın gerçek rolü.

Hosting seçimi tool ismiyle değil, üç ekseni birlikte değerlendirerek verilir: bakım kapasitesi, veri egemenliği, trafik öngörülebilirliği. Bu yazı eksenleri önce, tool karşılaştırmasını sonra koyuyor.

sGTM Runtime Gerçeği

Kararın temeli: sGTM bir Docker imajıdır. Google Cloud Container Registry’deki resmi imaj gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable, güncel base gcr.io/distroless/nodejs24-debian13; yani distroless Debian üzerinde Node.js 24. Önceki sürüm Node.js 22 distroless Debian 12 kullanıyordu.¹

Runtime ihtiyacı: Node.js çalıştırabilen bir container orchestrator. Cloud Run setup dokümantasyonunda önerilen kaynak 1 vCPU ve 500 MB RAM; pratikte minimum yükte container ~200 MB RAM tüketir, yüksek trafikte skalada her instance max 1 vCPU alır (fazlası boşa gider).²

Sonuç: sGTM hosting listesi Docker + Node.js koşturabilen platformlarla sınırlı. Bu liste şunları içermez: Cloudflare Workers, Deno Deploy, Vercel Edge Functions, Netlify Edge Functions. Hepsi V8 isolate platformlarıdır; Docker imajı çalıştıramaz, uzun ömürlü Node.js server tutamaz. Cloudflare Workers sGTM’nin önüne konabilir; aşağıda ayrı bölümde ele alıyorum.

Üç Seçenek, Üç Profil

Seçenek	Managed?	Region seçimi	Bakım yükü	Öngörülebilir maliyet
Google Cloud Run	Yarı-managed	30+ region	Düşük	Hayır (kullanıma göre)
Stape	Tam managed	EU, US, Asia, AU	Sıfır	Evet (tier sabit)
Self-host Docker	Hayır	Tamamen esnek	Yüksek	Evet (sabit)
Google App Engine	Yarı-managed	20+ region	Orta	Hayır

App Engine güncel dokümantasyonda Cloud Run lehine geri plana düştüğü için bu yazıda ayrı ele almıyorum; Cloud Run önerisi onu da kapsar. Esas karar Cloud Run, Stape ve self-host arasında.

Cloud Run

Google Cloud Run sGTM için Google’ın resmi önerilen yoludur. Manual setup guide dokümanı doğrudan Cloud Run deployment’ı anlatır.³

Güçlü yönleri:

• GCP servisleriyle native entegrasyon: Secret Manager (container config ve auth token yönetimi), IAM (müşteri proje izolasyonu), Cloud Logging ve Cloud Trace (debug için ek toplama katmanına gerek yok).
• Auto-scaling native. Trafiğe göre instance sayısı ayarlanır; instance başına max 1 vCPU kuralı (fazlası auto-scaling’i bozar) yazılı dokümantasyonda geçer.²
• Region çeşitliliği: Frankfurt, Warsaw veya Milan gibi AB region’ları.
• Dokümantasyon en zengin: Simo Ahava, Mark Edmondson, Square Developer Blog gibi primary kaynaklar Cloud Run odaklı.⁴⁵

Zayıf yönleri:

• Maliyet öngörülemez: trafik arttıkça kullanıma bağlı fatura büyür; kampanya günlerinde sabit tier modellerinin avantajı görünür hale gelir.
• Google Cloud billing kurulumu bir ajansın müşteri hesabında dokümantasyon ve onay süreci gerektirir. Müşterinin GCP project’i yoksa yeni proje açılması ek bir onboarding adımıdır.
• Cold start: min instance 0 tutulursa ilk request’te gecikme olur. Preview mode sağlıklı çalışması için min 1 instance önerilir, bu da sabit bir maliyet oluşturur.
• Preview container ayrı deploy edilmeli. Preview event’lerinin production event akışına karışması raporlarda kirlilik yaratır; bu yüzden ayrı bir Cloud Run service açılır.

Kime uygun: Google ekosisteminde derinleşmiş ajans, GCP-familiar teknik ekip, değişken trafik ve ölçek ihtiyacı, GA4 BigQuery export’u zaten kullanan müşteri hesapları.

Kime değil: Bakım süresine ayıracak kapasitesi olmayan ajans, müşteri tarafında GCP kurulumu uzun süren operasyonlar, sabit aylık maliyet zorunlu senaryolar.

Stape

Stape yalnızca sGTM hosting yapan managed bir hizmet. Container’ı onlar tarafında çalışır, kullanıcı yalnızca container config ve tag mapping yapar.⁶

Güçlü yönleri:

• Sıfır ops. Docker, IAM, billing gibi katmanlara temas edilmez.
• Region seçimi: EU (Frankfurt), US, AU, Asia.
• “Power-ups” adıyla hazır template’ler (CAPI, Enhanced Conversions, data enrichment, Cookie Keeper) sunar. Elle kurulduğunda zaman alan konfigürasyonları tek tıkla açar.
• Preview container ayrı yönetilir, konfigürasyon UI üzerinden.
• Custom loader (JS loader’ı kendi CDN’lerinden serve etme) ad blocker dirençliliği için kullanılır.

Zayıf yönleri:

• Pricing tier bazlı; trafik üst limite dayandığında tier yükseltme gerekir.
• Power-ups ek ücretli; birden fazla açık olduğunda toplam fatura managed-only avantajını azaltır.
• Container image düzeyinde değişiklik yapılamaz; custom logic için Cloud Run veya self-host’a göre daha sınırlı esneklik.
• Stack Stape üstüne kurulduğunda taşıma maliyetli.

Kime uygun: Birden fazla müşteri yöneten ajans, bakım yükünü kreatif ve strateji işine kaydırmak isteyen ekip, TR/EU region yeterli hesaplar.

Kime değil: Veri egemenliği kritik müşteriler (finans, kamu, sağlık), custom container logic isteyen ileri kurulumlar, sabit tier’ın trafik sürprizine kapalı kaldığı senaryolar.

Self-host Docker

Kendi sunucunda Docker imajını koşturmak. Paolo Bietolini (Aralık 2025) production-ready pattern’ı paylaştı: Docker Compose ve Caddy reverse proxy.⁷ Pratikte iki katman:

Production pattern: Docker Compose ile iki container (preview + tagging), ikisi de 127.0.0.1 port binding, Caddy reverse proxy ile HTTPS terminasyonu ve subdomain routing (sgtm.site.com → tagging, sgtm-preview.site.com → preview). Kritik Caddy notları: timeout ≥30 saniye (sGTM Preview mode bazı event’lerde 20 saniye bekletir), cache kapalı (Preview cache’lenmiş response’la çalışmaz), X-Real-IP ve X-Forwarded-For header’ları container’a geçirilmeli.

Altyapı: Hetzner Cloud gibi AB bölgelerinde VPS, Caddy (otomatik Let’s Encrypt), Docker. Multi-app yöneten bir ortamsa Coolify veya Dokploy gibi PaaS katmanı eklenebilir; ama sGTM tek servis olduğu için doğrudan docker compose + Caddy genelde yeterli ve daha az attack surface sunar.

Alternatif platformlar:

• AWS ECS Fargate: Cloud Run benzeri serverless container, AWS ekosisteminde olan müşteriler için doğal seçim.
• DigitalOcean App Platform: Basit deployment için hafif alternatif, auto-scaling sınırlı.

Kurulum özü (Paolo Bietolini pattern’ından sadeleştirilmiş):

# docker-compose.yml
services:
  gtm_prod:
    image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
    environment:
      CONTAINER_CONFIG: ${CONTAINER_CONFIG}
      PREVIEW_SERVER_URL: ${PREVIEW_SERVER_URL}
    ports:
      - "127.0.0.1:8081:8080"
    restart: always

  gtm_preview:
    image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
    environment:
      CONTAINER_CONFIG: ${CONTAINER_CONFIG}
      RUN_AS_PREVIEW_SERVER: "true"
    ports:
      - "127.0.0.1:8082:8080"
    restart: always

Container config string sGTM arayüzünde Admin > Container Settings > Manual Provisioning altında bulunur. Caddy konfigürasyonu, SSL ve log rotate detayları için Paolo Bietolini’nin rehberine bakabilirsin.⁷

Lokal debug: sGTM’yi kendi makinende çalıştırmak istiyorsan Simo Ahava’nın docker-compose stack’i Colima (Docker Desktop lisans istemeyen açık kaynak alternatif) ile sorunsuz çalışır. Detay ve adımlara sGTM kurulum rehberinde değindim.⁸

Güçlü yönleri:

• Tam veri egemenliği. Fiziksel server ve veri lokasyonu bilinir.
• Sabit maliyet: VPS aylık ücreti, trafik limiti içinde ek fatura yok.
• Özelleştirme sınırı yok. Docker image’ı fork’lanabilir, custom middleware eklenebilir.
• KVKK ve GDPR audit’te veri aktarımı zinciri kısa.

Zayıf yönleri:

• Patch yönetimi, security update, monitoring, backup, SSL renewal sorumluluk alanına girer (Caddy SSL’i otomatik yeniler; diğer katmanlar manuel).
• Auto-scaling manuel. Trafik patlamasında VPS yetersiz kalırsa downtime.
• Preview ve prod ayrımı, reverse proxy, firewall kurulumu manuel.
• sGTM imaj güncellemeleri manuel takip edilmeli; Node.js major version geçişlerinde (24→25 gelecek) test katmanı gerekir.

Kime uygun: Küçük müşteri portföyü yöneten ajans, DevOps ekibi hazır, veri egemenliği müşteri sözleşmesinde, sabit maliyet zorunlu.

Kime değil: DevOps kapasitesi olmayan ajans, müşteri çeşitliliği yüksek (farklı trafik profilleri farklı boyutlandırma gerektirir), hızlı onboarding gereken senaryolar.

Ek Katman: Cloudflare Workers: Same-Origin Proxy

Cloudflare Workers sGTM ekosisteminde sGTM’nin önüne konan transparent proxy. Google’ın kendi resmi “Google Tag Gateway” konseptiyle aynı prensip.

Ne yapar:

Ziyaretçi tarayıcısı https://site.com/metrics yolunu çağırır. CF Worker bu isteği alır, Cloud Run (veya Stape veya self-host) üzerinde koşan sGTM endpoint’ine iletir. Response geri gelir, Worker tarayıcıya döndürür. Kullanıcı için tüm analytics trafiği site.com domain’inde kalıyor gibi görünür.

Ne kazandırır:

• First-party cookie: Tarayıcı site.com cookie’sini set eder, cross-site kısıtlaması tetiklenmez.
• Safari ITP: First-party cookie olarak server-set edildiğinde Safari’nin JS-set cookie’lere uyguladığı 7 günlük kısıtlamadan muaf olur.
• Edge latency: Worker, Cloudflare’in global edge ağında çalışır, kullanıcıya en yakın noktadan yanıt verir.
• Ad blocker dayanıklılığı (kısmi): Bilinen GA ve Meta endpoint path’leri yerine kendi domain yolun kullanıldığı için basit liste-bazlı blocker’lar tanımayabilir. Agresif blocker’lar ID tabanlı çalıştığı için tam bypass değil.

Kritik: CF default caching kapalı olmalı. sGTM Preview Mode cache’lenmiş response’larla çalışmaz, debug kırılır.⁹

Açık kaynak örnek: simondahla/sgtm-same-origin-proxy-cloudflare-worker hazır Worker kodu sunar.¹⁰ owntag aynı pattern için detaylı yazı yayınladı.¹¹ Stape kendi yönetim panelinden Cloudflare Worker kurulum yönergesi sağlar.¹²

Öneri: Hangi hosting’i seçersen seç, production ortamında CF Worker proxy katmanı değerlendirmeye değer. Gerçek kazanım first-party cookie ve ITP dayanıklılığı.

Ajans Multi-Client Mimari

Birden fazla müşteri yöneten ajans için üç mimari yol:

Yol A — Tam izolasyon: Müşteri başına ayrı Cloud Run project veya ayrı Stape hesabı. En temiz, en yüksek ops yükü.

Yol B — Paylaşımlı altyapı, ayrı container: Tek ajans Cloud Run project altında müşteri başına ayrı service (sgtm-clienta, sgtm-clientb). Self-host senaryoda tek VPS üzerinde ayrı Docker Compose service’leri aynı pattern’ı verir. Stape’de bu model desteklenmez. Ajansın default modeli genellikle budur.

Yol C — Tek container, birden fazla container ID: sGTM aynı instance’ta birden fazla container ID’yi destekler. Trafik düşükse tek instance birden fazla müşteriye hizmet verebilir, ancak izolasyon yok: bir müşterinin event’i debug edilirken diğeri etkilenir. MVP ajans dönemi için geçerli, çok müşterili ajansta izolasyon eksikliği sorun üretir.

Müşteri ayrılma senaryosu:

• Cloud Run: IAM transfer ile project ownership müşteri hesabına.
• Stape: Hesap müşteri adına açılmışsa billing transfer.
• Self-host: Docker compose ve .env müşteri sunucusuna taşınır.

Devir checklist’i ajans kontrat ek’inde olmalı: DNS handoff, IAM transfer, ESP ve Cookie Keeper iptalleri, GA4 property ownership.

Karar Matrisi

Senaryo	Önerilen	Neden
Küçük-orta ajans, DevOps ekibi yok	Stape EU region	Sıfır-ops, hızlı onboarding, tier sabit fiyat
Google ekosisteminde derin müşteri, BigQuery kullanıyor	Cloud Run	GCP servisleriyle native entegrasyon, esnek ölçekleme
Enterprise müşteri, veri egemenliği sözleşmede	Self-host (Hetzner + Caddy)	Tam kontrol, KVKK audit zinciri kısa
Çok müşterili ajans, standardizasyon önceliği	Cloud Run paylaşımlı project	Ortak altyapı, ayrı service, template deploy
Düşük trafikli TR e-ticaret	Cloud Run min 0 instance	Cold start tolere edilebilir, maliyet düşük
Ad blocker sorunu ön planda	Herhangi + CF Worker proxy	First-party cookie ve ITP dayanıklılığı

Her seçeneğin üstüne CF Worker same-origin proxy eklenmesi default düşünülmeli; tek başına bir hosting değil, her stack’in doğal katmanı.

Son Not

sGTM hosting kararı “Cloud Run mu Stape mi” ikilemine sıkıştırılamaz. Karar üç eksende başlar (bakım kapasitesi, veri egemenliği, trafik öngörülebilirliği), ajans ve müşteri profiline göre dallanır. Tool isimleri değişir, eksenler kalır.

Kurulum detayları için sGTM Kurulum Rehberi. Ajans marketing stack’inin geri kalan katmanları (consent, analytics, attribution, governance) için: Ajanslar için Marketing Stack 2026.

Footnotes

1. Manual setup guide. Google Tag Manager ↩
2. Cloud Run Setup Guide. Google Tag Manager ↩ ↩²
3. Manual setup guide. Google Tag Manager ↩
4. Deploying Server-Side Google Tag Manager on Cloud Run. Square Developer Blog ↩
5. Google Tag Manager Server Side on Cloud Run - Pros and Cons. Mark Edmondson ↩
6. Google Tag Manager Server-Side Tagging with Stape. Analytics Mania ↩
7. Implementing Server-Side GTM with Docker: On-Premise Solution Guide. Paolo Bietolini ↩ ↩²
8. Run Server-side Google Tag Manager On Localhost. Simo Ahava ↩
9. Same-origin Deployment With Server-side Google Tag Manager. Simmer ↩
10. sgtm-same-origin-proxy-cloudflare-worker. simondahla (GitHub) ↩
11. How to Make Your Server-Side GTM Accessible for Free via Cloudflare on Your Main Domain and Bypass ITP. owntag ↩
12. How to Use Same Origin Through Cloudflare. Stape ↩

Önemli Noktalar

• 01 sGTM Docker + Node.js container olduğundan Cloudflare Workers gibi V8 isolate platformlarında koşmaz
• 02 Cloud Run en iyi dokümante edilen yol, Stape sıfır-ops alternatif, self-host veri egemenliği için
• 03 CF Workers sGTM'nin önünde same-origin proxy olarak çalışır; ITP ve first-party cookie kazanımı sağlar
• 04 Ajans multi-client kurulumunda her müşteri için ayrı container + paylaşımlı altyapı modeli maliyet-etkin
• 05 Hosting kararı maliyet değil bakım yükü ve veri egemenliği ekseninde verilir

Sık Sorulan Sorular (FAQ)

+ sGTM'yi Cloudflare Workers'da koşturabilir miyim?

Hayır. sGTM bir Docker imajı (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable) ve Node.js runtime ister. Cloudflare Workers V8 isolate platformudur, Docker ve Node.js server'ı çalıştıramaz. CF Workers yalnızca sGTM'nin önünde same-origin proxy olarak kullanılır.

+ Cloud Run mu Stape mi daha ucuz?

Trafik profiline ve bakım zamanına göre değişir. Düşük-orta trafikte Cloud Run kullanıma göre fatura tutar, yüksek trafikte Stape'in sabit tier'ı öngörülebilir kalır. Ajans tarafında saat bazlı bakım maliyetini de hesaba kat.

+ Preview container ayrı mı host edilmeli?

Evet. Google tagging server dokümantasyonu preview container'ın ayrı instance'ta çalıştırılmasını önerir; aksi halde preview event'leri production event akışını kirletir ve raporlarda karışıklığa yol açar.

+ Stape kullanırken veri Türkiye'den çıkıyor mu?

Stape EU region seçimi sunar ancak trafiğin tamamen Türkiye'de kalmasını garanti etmez. KVKK'da veri yurt dışına aktarım gerektiren durumlar varsa self-host tercih edilir.

+ sGTM instance'ı kaç müşteriye hizmet verebilir?

Aynı container'da birden fazla container ID tanımlanabilir. Ajans pratiğinde izolasyon için müşteri başına ayrı container tercih edilir; paylaşımlı Cloud Run project'i altında her müşteri ayrı service olarak deploy edilir.

+ CAPI ve Enhanced Conversions gibi özellikler hosting seçimine bağlı mı?

Hayır. CAPI ve Enhanced Conversions sGTM container konfigürasyonunda kurulur, hosting'den bağımsızdır. Cloud Run, Stape ve self-host aynı işlevsellikleri sunar.