“Vercel’e son.” “Netlify’a gerek yok.” “Hetzner’a bir VPS kur, Coolify yükle, ayda $5’a her şeyi çalıştır.”
YouTube’da, blog’larda, Reddit thread’lerinde bu söylemi çok gördüm. Ben zaten VPS kullanıyordum, Coolify’ı merak etmiştim. 4 farklı projeyi Hetzner VPS üzerinde Coolify ile deploy ettim. Django backend’ler, Node.js API’lar, React SPA’lar, background job worker’ları. Hepsi tek sunucuda, Hetzner CX22 liste fiyatıyla ~€4.5/ay (2026-02 kuruyla ~$7) + snapshot ve backup.
Para olarak harika. Zaman olarak? Farklı bir hikaye.
| Hızlı Referans | |
|---|---|
| Test süresi | ~3 ay, 4 proje (Şubat 2026) |
| Stack çeşitliliği | Django, Node.js, React, Celery, Inngest |
| Aylık maliyet | Hetzner CX22 |
| Managed alternatif tahmini | Vercel Pro $20 + Neon Scale ~$19 + Inngest ~$25 ≈ $64-100/ay (Şubat 2026; profile göre değişir) |
| Yaşanan kritik sorun | 7 |
| Zorunlu göç | 2 (PostgreSQL, reverse proxy) |
| İlişkili | Hardening Checklist |
Ne Çalıştı
Öncelikle söylemeliyim: Coolify kötü bir araç değil.
Maliyet gerçekten düşük. Hetzner’ın CX22 (2 vCPU, 4GB RAM) sunucusuyla 4 projeyi rahatça çalıştırdım. Liste fiyatı ~€4.5/ay (Şubat 2026), 2026-02 kuruyla ~$7 + snapshot ve backup. Aynı stack’i managed servislerle kursam benim workload profilim için en az 10 katı bandında çıkardı.
UI kullanışlı. Git repo bağlama, environment variable yönetimi, log izleme, one-click deploy. Vercel’in deployment deneyimine yakın. SSH’a girip Docker komutları yazmak zorunda kalmadığım günler oldu.
Esneklik. Vercel dokümantasyonuna göre (Şubat 2026 erişimi) Hobby planda function timeout 10 saniye, Pro planda 60 saniye; planlar zamanla güncellenebilir. Webhook-heavy bir uygulamada bu yetmiyor. Self-hosted Inngest ile timeout sınırı yok, cold start yok.
Docker Compose desteği. Backend, worker, beat scheduler gibi birden fazla servisi tek compose dosyasıyla yönetmek kolay. Coolify network’ü otomatik yönetiyor, servisler arasındaki iletişim sorunsuz.
Ne Çalışmadı
Asıl hikaye burada başlıyor. Kronolojik sırada yaşadığım sorunlar:
1. Docker Host-Level Firewall’ları Bypass Ediyor
Bu, self-hosting’in en büyük ve en az konuşulan sorunu (en azından test ettiğim setup’ta).
Docker’ın port publishing mekanizması (-p 5432:5432), test ettiğim Ubuntu 24.04 + nftables backend kurulumunda host üzerinde denediğim firewall katmanlarını bypass etti:
- Hetzner Cloud Firewall (kurallar doğru, “Applied” durumunda, ama bu setup’ta etkisiz)
- UFW (Docker kendi iptables kurallarını UFW’den önce yazıyor)
- iptables/nftables kuralları (DOCKER-USER chain, INPUT chain, raw table)
Muhtemel kök neden: Docker hem DNAT (nat PREROUTING) hem docker-proxy (0.0.0.0’da dinleyen userland proxy) kullanıyor. Docker’ın packet filtering dokümantasyonu Ubuntu 24.04’ün nftables backend’inde kendi tablolarını ayrı yönettiğini tarif ediyor; bu da host seviyesindeki kuralların paket yakalamamasını açıklıyor görünüyor.
Bunu teorik olarak değil, pratik olarak öğrendim. Veritabanı portunu kapatmak için 5 farklı yöntem denedim (Şubat 2026, Ubuntu 24.04 + Docker; tablodaki sonuçlar o konfigürasyona ait):
| Denenen Yöntem | Sonuç |
|---|---|
| Hetzner Cloud Firewall (sadece 22, 80, 443 izin) | Docker bypass etti |
| iptables DOCKER-USER chain DROP | 0 paket eşleşti |
| iptables INPUT chain + custom DOCKER-BLOCK | 0 paket eşleşti |
iptables raw PREROUTING (-i eth0) | 0 paket eşleşti |
| iptables raw PREROUTING (interface filtresi olmadan) | 0 paket eşleşti |
Beş deneme. Sıfır başarı. O konfigürasyonda denediğim “standart” Linux firewall çözümlerinin hiçbiri Docker’ın port publishing’ini engelleyemedi. Tunnel/VPN gibi başka mimari yaklaşımlar denenebilirdi ama o anki kurulumda fiili çözüm migration oldu.
2. Devlet Kurumundan Güvenlik Uyarısı
Veritabanı portu açık kaldığı için bir gün hosting sağlayıcım üzerinden resmi bir güvenlik uyarısı aldım. Alman Federal Bilgi Güvenliği Ofisi (BSI), rutin internet taramalarında sunucumdaki açık PostgreSQL portunu tespit etmiş.
Port neden açıktı? İki dış servis doğrudan TCP bağlantısı gerektiriyordu: hosting platformundaki uygulama (ORM üzerinden) ve bir connection pooler servisi. Docker’ın port publishing’i o setup’ta host firewall’larını bypass ettiği için kapatamıyordum.
Çözüm? Self-hosted veritabanını bırakıp managed bir servise göç etmek. Kod değişikliği sıfır, sadece environment variable değişimi. Ama bu bir tercih değil, zorunluluktu.
3. SSL Sertifika Sorunları
Coolify’ın “Make it publicly available” toggle’ı beklenmedik yan etkilere sahip. Bir veritabanı container’ında bu ayarı değiştirdikten sonra SSL sertifika mount’ları bozuldu. Container restart döngüsüne girdi: server.crt ve server.key bekleniyor, sadece server.pem mount edilmiş. Restart döngüsünün doğrudan sebebi bu dosya adı mismatch’iydi.
Veritabanından dump almak için geçici bir container’ı farklı parametrelerle çalıştırmam gerekti. Standart yöntemler çalışmadı çünkü Coolify’ın kullandığı container UID’leri (70) standart PostgreSQL UID’leriyle (999) uyuşmuyordu; UID farkı dump alma adımında ayrıca sorun çıkardı.
4. Port Çakışmaları
Projelerden birinde Caddy reverse proxy kullanıyordum. Coolify’ın kendi proxy’si (Traefik) zaten port 80’i kullanıyor. İkisi çakıştı. Caddy’yi compose dosyasından kaldırmam, Docker port mapping’i ports: yerine expose: olarak değiştirmem ve Coolify’ın network yönetimine bırakmam gerekti.
Dokümantasyonda bu açıkça belirtilmiyor. Deneme-yanılmayla öğrendim.
5. Cloudflare Workers Same-Zone DNS Bypass
Cloudflare Workers, aynı DNS zone’undaki hostname’leri çözümlerken DNS’e sorgu göndermez, doğrudan bypass eder. Aynı domain altında bir Worker ve bir tunnel-backed servis çalıştırıyorsanız, Worker tunnel’a ulaşamaz.
Çözüm: Farklı bir Cloudflare zone’unda (workers.dev) proxy Worker oluşturmak ve Service Binding kullanmak. Bunu keşfetmek saatlerimi aldı.
6. Build Cache Kırılması
Kasım 2025’te Coolify, Docker build sırasında otomatik olarak değişen build argument’leri (SOURCE_COMMIT, COOLIFY_CONTAINER_NAME, COOLIFY_BUILD_SECRETS_HASH) inject etmeye başladı. Docker her build argument’ı layer cache key’inin parçası olarak ele aldığı için, her deployment’ta tüm cache geçersiz oluyordu.
Benim Django + Node.js projemde build süresi yaklaşık 1dk’dan 5dk’ya çıktı; Loopwerk yazısı aynı pattern’i raporluyor. Aralık 2025’te Coolify tarafından düzeltildi ama o bir ay boyunca her deploy gereksiz yere yavaş çalıştı.
Ocak 2026: 11 Kritik Güvenlik Açığı
Self-hosting’in belki de en önemli görünmeyen maliyeti: güvenlik sorumluluğu tamamen size ait.
Ocak 2026’da Coolify’da 11 kritik güvenlik açığı açıklandı. 3 tanesi CVSS 10.0, yani en yüksek skor:
- CVE-2025-64420: Düşük yetkili kullanıcılar root kullanıcısının private key’ini görebiliyordu
- CVE-2025-66209: Veritabanı backup işleminde command injection, root olarak komut çalıştırma
- CVE-2025-66210/66211: Docker Compose build parametrelerinden authentication bypass
Censys’in açıklama anındaki taramasına göre yaklaşık 52,890 açık Coolify instance gözlemlendi; sayı tarama anına özgü. Yaklaşık 15,000’i Almanya’da.
Managed bir serviste bu sizin sorununuz değil. Self-host ediyorsanız, her CVE açıklamasını takip etmek, patch uygulamak ve arada kalan süreçte “acaba benim sunucum da etkilendi mi?” diye düşünmek zorundasınız.
Gerçek Maliyet Matrisi
Self-hosting’in maliyetini sadece sunucu faturası olarak düşünmek yanıltıcı.
| Maliyet Kalemi | Self-Host (Hetzner + Coolify) | Managed (Vercel + Neon + Inngest) |
|---|---|---|
| Aylık fatura | $64-100+ (profil bağımlı) | |
| İlk kurulum süresi | 2-3 gün | 30 dakika |
| Güvenlik bakımı | Sürekli (CVE takibi, patch, firewall) | Platform sorumlu |
| Incident müdahale | Siz (BSI maili, SSL sorunu, port çakışması) | Destek ekibi |
| Zorunlu göçler | Yaşanabilir (PG -> managed) | Nadir |
| Stres faktörü | ”Her security update acil hissettiriyor” | Düşük |
| Toplam zaman maliyeti (3 ay) | Geriye dönük kaba tahminim ~40-60 saat (debug + research + migration); zaman takibi tutmadım | ~2-3 saat config |
Solo developer için o 40-60 saatlik fark (tahmin), ürün geliştirmeye harcanabilecek zamandan çalıyor.
Ne Zaman Self-Host, Ne Zaman Managed?
Self-hosting her durum için yanlış değil. Ama her durum için de doğru değil.
Self-host mantıklı hissettiren koşullar (benim deneyimim):
- Managed servis faturanız ayda $50-100 bandını geçti (eşik iş yüküne göre kayar)
- DevOps/Linux deneyiminiz var
- Timeout, cold start veya kaynak sınırlamaları iş akışınızı engelliyor
- EU data residency gerekliliği var
- Ekibinizde operasyon sorumlusu var
Managed servis daha mantıklı hissettiren koşullar:
- Solo developer veya küçük ekipsiniz
- Ürün geliştirmeye odaklanmanız gerekiyor
- Henüz gelir modeli oturmadı (pre-revenue)
- Güvenlik ve compliance konusunda özel bilginiz yok
Solo developer profili için bana en sağlıklı gelen yaklaşım hybrid. App container’larını self-host edin (ucuz, esnek). Veritabanını managed serviste tutun (Neon, Supabase). DNS ve CDN’i Cloudflare’e bırakın. Background job’ları ihtiyaca göre self-host veya cloud. Ekipte operasyon sorumlusu varsa tablo değişir.
Bu yaklaşımda Hetzner’ın maliyet avantajını korursunuz, ama en kritik bileşeni (veri) profesyonel ellere bırakmışsınız.
Sonuç
Coolify kötü bir araç değil. Hetzner kötü bir sağlayıcı değil. Self-hosting kötü bir fikir değil.
Ama “kolay” değil.
YouTube videoları ve blog yazıları genellikle ilk 30 dakikayı gösteriyor: Coolify’ı kurun, repo’yu bağlayın, deploy edin, bitti. Sonraki 3 ayı göstermiyorlar: Docker’ın host firewall’larını bypass ettiğini keşfetmek, devlet kurumundan güvenlik uyarısı almak, SSL sertifikalarını debug etmek, zorunlu göçler yapmak.
Bu deneyimden çıkardığım best practice’leri ayrı bir yazıda derledim: Hetzner + Coolify Hardening Checklist.
Self-hosting’i değerlendiriyorsanız, önce o checklist’e bir göz atın. Sonra kararı verin.
Kaynaklar
- Coolify Discloses 11 Critical Flaws (TheHackerNews, Ocak 2026)
- Seven CVEs in Coolify Identified Through AI Pentesting (Aikido)
- How Coolify Accidentally Broke Docker Layer Caching (Loopwerk)
- Coolify Firewall Documentation
- How I Made Coolify on Hetzner Inaccessible from Public Internet (Medium)
- The True Cost of Self-Hosting (MassiveGRID)
- Vercel vs Self-Hosted Coolify Cost Comparison (MassiveGRID)
- Docker Packet Filtering and Firewalls (Docker Docs)
- 01 Test ettiğim Ubuntu 24.04 + nftables + Docker konfigürasyonunda port publishing, denediğim host-level firewall kurallarının (Hetzner Cloud Firewall, UFW, iptables) hiçbiriyle engellenmedi; farklı dağıtım/sürüm kombinasyonlarında davranış değişebilir
- 02 Self-hosted PostgreSQL'de güvenlik açığı kapatmak için 5 farklı yöntem denedim (Şubat 2026, o konfigürasyona özgü); hiçbiri çalışmadı
- 03 Coolify'da Ocak 2026'da 11 kritik güvenlik açığı (3'ü CVSS 10.0) açıklandı; Censys taramasına göre o ankine ait yaklaşık 52,890 internete açık instance gözlemlendi
- 04 Para maliyeti görece düşük (Hetzner CX22 ~€4.5/ay, 2026-02 kuruyla ~$7 + snapshot/backup) ama zaman maliyeti yüksek
- 05 Solo developer profili için bana en sağlıklı gelen yaklaşım hybrid: app container'ları self-host, veritabanını managed serviste tut; ekipte operasyon sorumlusu varsa tablo değişir
+ Coolify ile self-hosting gerçekten ucuz mu?
Para olarak evet. Hetzner CX22 liste fiyatı ~€4.5/ay (Şubat 2026), 2026-02 kuruyla ~$7 civarında; snapshot $0.013/GB/ay, backup sunucu planının %20'si. Bu maliyetle 4 proje çalıştırdım. Ancak zaman maliyetini hesaba katınca tablo değişiyor. Güvenlik sorunları, SSL hataları, zorunlu göçler ve debug süreci solo developer için ciddi zaman tüketiyor.
+ Docker neden firewall'ları bypass ediyor?
Docker port publishing hem DNAT (nat PREROUTING) hem docker-proxy (userland proxy on 0.0.0.0) kullanıyor. Muhtemelen sebebi Docker'ın packet filtering davranışı: Docker'ın dokümantasyonu kendi tablolarını ayrı yönettiğini tarif ediyor. Test ettiğim Ubuntu 24.04 + nftables backend kurulumunda denediğim host-level kuralların (Hetzner Cloud Firewall, UFW, iptables, nftables) hiçbiri etkili olmadı; farklı dağıtım/sürüm kombinasyonlarında davranış değişebilir.
+ Coolify güvenli mi?
Ocak 2026'da 11 kritik güvenlik açığı açıklandı. 3 tanesi CVSS 10.0 (en yüksek skor). Authentication bypass, remote code execution ve private key disclosure içeriyordu. Censys'in açıklama anındaki taramasına göre yaklaşık 52,890 açık Coolify instance gözlemlendi; sayı tarama anına özgü. Güncellemeleri takip etmek zorunlu.
+ Self-hosting ne zaman mantıklı?
Benim deneyimimde Vercel/Railway faturası ayda $50-100 bandını geçtiğinde ve DevOps bilginiz varsa mantıklı hissettiriyor; iş yüküne ve DevOps kapasitesine göre eşik kayar. Ama solo developer için hybrid yaklaşım daha sağlam: app container'larını self-host edin, veritabanını managed serviste (Neon, Supabase) tutun, DNS ve CDN'i Cloudflare'e bırakın.
+ Hetzner Cloud Firewall Docker portlarını engelliyor mu?
Hayır. Hetzner Cloud Firewall belgelerinde çalışıyor gibi görünse de test ettiğim setup'ta (Ubuntu 24.04 + Docker, Şubat 2026) port publishing mekanizması onu bypass etti. Bunu 5 farklı yöntemle test ettim, o konfigürasyonda hiçbiri çalışmadı. Bu setup'ta tek güvenilir yöntem Docker seviyesinde localhost binding veya port mapping kaldırma oldu.