Heroku’nun Aylık 3.000 Dolarlık Faturasını Aylık 55 Dolarlık Bir Sunucuyla Değiştirmek

• Kâr amacı gütmeyen iş arama platformu Idealist, Heroku’da ortaya çıkan pahalı staging ortamı maliyeti sorununu çözmek için düşük maliyetli özel bir sunucuya geçti
• Heroku’da ortam başına ücretlendirme yapısı nedeniyle, her staging ortamı ayda 500 dolar seviyesinde maliyet oluşturuyordu
• Bunun yerine Hetzner CCX33 sunucusu (aylık 55 dolar) üzerinde birden fazla ortam kuruldu ve Disco sayesinde Heroku ile aynı git push ve otomasyon deneyimi korundu
• Tek bir sunucuda 6 staging ortamı istikrarlı şekilde çalışıyor; CPU kullanımı %2, bellek kullanımı ise 32GB’ın 14GB’ı seviyesinde ve rahat bir kapasite sunuyor
• Böylece staging ortamları “maliyet yükü” olmaktan çıkıp “özgürce oluşturulabilen bir kaynak” haline geldi; geliştirme ekibinin deney ve dağıtım kültürü büyük ölçüde iyileşti

---

Heroku maliyetlerini düşürmek için pratik bir strateji deneyimi

Sorun: Aylık 500 dolarlık staging ortamı

• Idealist.org, her ay milyonlarca kişinin ziyaret ettiği büyük ölçekli, kâr amacı gütmeyen bir iş arama platformu; bu yüzden gerçek üretim ortamına neredeyse tamamen benzeyen bir staging ortamı zorunlu
• Heroku’da web/worker dyno’ları ve Postgres gibi gerekli eklentileri bir araya getiren tek bir staging ortamının maliyeti yaklaşık 500 dolar/ay düzeyindeydi
• Sadece dev ve main olmak üzere iki ortamı korumak bile 1.000 doların üzerinde sabit gider yaratıyordu
• Heroku’nun fiyatlandırma modeli ortam bazlı bir ücretlendirme modeli; dyno sayısını azaltmak tasarrufu çok sınırlı artırıyor ve uygulama sayısı arttıkça maliyet hızla yükseliyor

Deney: Tek sunucuya geçiş

• Daha ideal bir maliyet düşüşü için tek bir Hetzner CCX33 sunucusu (aylık 55 dolar) kiralanarak deneye başlandı
• Disco çözümü kullanılarak mevcut Heroku’daki git push ile dağıtım yöntemi sunucu üzerinde aynen uygulandı
• Tüm staging ortamları aynı sunucudaki ortak Postgres instance’ını kullanarak, yönetilen veritabanı maliyetleri büyük ölçüde azaltıldı
• Test açısından bu yapı, geliştirici bazında ayrı veritabanlarını kolayca sıfırlamaya imkân verdiği için uygun bulundu

Neden Disco: Docker Compose’dan farkı ne?

• Sunucuda sadece docker-compose up çalıştırmak, geliştirici deneyimi açısından tek başına yeterli değil
• Disco şu avantajları sağlıyor
  • Heroku ile aynı git push dağıtım süreci
  • Tüm dağıtımlar için otomatik kesintisiz dağıtım desteği
  • Branch bazlı URL’ler için otomatik SSL sertifikası oluşturma ve yenileme
  • Log ve ortam yönetimi için sezgisel bir web arayüzü
• Böylece özel dağıtım yönetimi otomasyonu kurup sürdürmeye gerek kalmadan, geliştirme kolaylığı korunabiliyor

Staging ortamlarının patlaması ve sunucu kaynak verimliliği

• Disco sayesinde staging ortamlarını ölçeklendirmek çok kolay hale geldi
• Tek bir sunucuda aynı anda şu ortamlar çalıştırılıyor
  • Ana branch
  • feature-freeze branch’i
  • Geçici PR’ler için throwaway ortamlar
  • Büyük özellik geliştirmeleri için uzun ömürlü ortamlar
• Toplam 6 bağımsız staging ortamı sorunsuz biçimde çalıştırılıyor
• Bu yapı Heroku’da aylık 3.000 dolara mal olurdu; Hetzner’da ise yalnızca %2 CPU ve 14GB bellek (32GB içinden) kullanarak düşük maliyetli biçimde çalışıyor

Trade-off’lar ve gerçekçi değerlendirmeler

• Bu yaklaşım tam bir alternatif değil; beraberinde bazı operasyonel yükler getiriyor
• Yeni ortamlar için DNS, CDN ayarları gibi altyapı işleri otomatikleştirilmiş değil
• Sunucu izleme, güvenlik güncellemeleri, arıza anında müdahale gibi operasyon sorumlulukları doğuyor
• Hetzner’ın ABD bölgesi seçenekleri sınırlı olduğundan, ABD’deki kullanıcılara yönelik production servisleri için uygun olmayabilir
• Sunucu arızası halinde yeniden kurulum gerekliliğini kabul eden bir erişilebilirlik trade-off’u bulunuyor
• Uygulamayı Docker ağ yapısına uyarlamak için yaklaşık bir günlük mühendislik çalışması gerekti

Elde edilen içgörüler ve değişim

• Altı aydan uzun süredir çalıştırılan bu altyapı artık kalıcı bir yapı haline geldi
• En büyük değişim yalnızca maliyet düşüşü değil; staging ortamlarının artık bol ve özgür bir kaynak olarak görülmeye başlaması oldu
• Geliştiriciler artık onay beklemeden ya da maliyet kaygısı taşımadan, ihtiyaç duyduklarında pull request bazlı ortamları serbestçe oluşturabiliyor
• Ekip içinde çıkarılan ders, yalnızca maliyet yükünün değil, kullanmaktan çekinmenin kendisinin de asıl kayıp olduğu yönünde
  • "Maddi yük, geliştirme hızını ve deney yapmayı kısıtlıyordu"

[GN⁺]

Hacker News yorumu

• htop ekran görüntüsüne bakınca swap olmadığını fark ettim; servis anormal şekilde bellek tüketmeye başladığında tüm sunucunun çökmesini önlemek için earlyoom etkinleştirilmesini öneririm. Linux çekirdeğinin OOM killer'ı genelde çok geç devreye giriyor. zram'ı etkinleştirip RAM'i sıkıştırarak profesyonelce overprovisioning yapmak da mümkün. Uzun süre çalışan yazılımlar sık sık bellek sızıntısı yapıyor ve sıkıştırma bu durumda epey verimli olabiliyor. Bunu Hetzner bare metal sunucularında Ansible ile nasıl uyguladığımı bir gist içinde toparladım; VM'lerde de aynı şekilde çalışıyor.

  • Kesinlikle katılmıyorum; swap'e ulaşıldığında çoğu uygulama ciddi sorunlar yaşamaya başlıyor. Bu fazlasıyla bilinen bir gerçek ve AWS EC2 instance'larında da swap varsayılan olarak kapalı. Elbette AWS daha fazla RAM satmak istiyor, ama bugünün beklentileri için swap uygun değil. 90'larda bir tıklama için 2-3 saniye beklemek normaldi; bugün ise yanıt gelmiyorsa insanlar uygulamanın öldüğünü düşünüp hemen yeniden başlatıyor.

  • Bir başka alternatif de daha fazla bellek eklemek ve uygulama bazında oom_score ayarlayarak önemsiz uygulamalara daha yüksek öldürülme ağırlığı, kritik uygulamalara ise negatif ağırlık vermek. Örneğin OpenSSH için oom_score_adj zaten -1000 olarak ayarlı. staging/production sunucularında overcommit'i fiilen devre dışı bırakmak da çok faydalı. RAM kapasitesine göre min_free ve reserve değerlerini formülle hesaplayıp ayarlıyoruz. 50.000 fiziksel sunucuyu 10 yıldan uzun süredir swap olmadan çalıştırıyoruz ve bunun sahada işe yaradığını gördük. OOM yalnızca kod dağıtımı sırasında bellek ihtiyacı yanlış hesaplandığında yaşandı. Java en iyi uygulamalarına uyulmadığında da ayrı bir hikâye var. cgroup ile uygulama bazında bellek sınırı koymak da mümkün ama detaya girmiyorum. Diske yazma gerektirmeyen tamamen in-memory sunucular için OOM'un hiç yaşanmamasını sağlayıp otomatik self-healing yapmak da tavsiye edilir. DRAC/iLO üzerinden crash mesajlarını yakalamaya zaman tanımak için panic reboot ayarları (kernel.panic, vm.panic_on_oom vb.) da faydalıdır. Bu arada NFS diskless sistemlerde arıza toleransı için bunu kasıtlı olarak tüm farm'ı yeniden başlatma tetikleyicisi olarak da kullanabilirsiniz.

  • Faydalı bilgi için teşekkürler. Şu anda sistem limitlerini systemd ile RAM eşikleri üzerinden yönetiyorum; earlyoom'un, bir prosesin kontrolden çıkıp tüm instance'ı yanıtsız bırakmasını önlemede daha iyi bir seçenek olup olmadığını merak ediyorum.

  • Her ihtimale karşı çok küçük, mesela 1 GB kadar swap bırakmanın iyi bir fikir olduğunu düşünüyorum.

  • 2010'dan beri swap kullanmadım.

• Dün Nate Berkopec'in rails performansı hakkında benzer konuda yazdığını gördüm; Heroku'nun performans bazında 25-50 kat daha pahalı olduğunu söylüyordu. Gerçekten fiyat rekabeti diye bir niyetleri yokmuş gibi duruyor ve bence Sidekiq benzeri şekilde tüm stack'i makul fiyatla sadece lisanslasalar, donanım ayrı olsa bile çok daha iyi olurdu. 2025'te 1 GB RAM dyno'nun 50 dolar olması resmen soygun. Özellikle standart bir rails uygulaması eskisine göre daha büyük kaynak dalgalanmaları yaratmıyorken, hatta daha verimliyken, fiyatlar artmış ve kalite düşmüş durumda. Bir sürü geliştiricinin uygulamalarını aylık yüzlerce dolara Heroku'da çalıştırırken fiilen kendi geliştirme amaçlı MacBook'larından daha yavaş makineler kullanıyor olması neredeyse komik. Sonuçta bu da günümüz dünyasının genel eğiliminden çok farklı değil: iyi bir ürünü makul fiyata kitlelere sunmak yerine en çok para ödeyen üst segment müşterilere odaklanıp fiyat artırmak.

  • Mesele sadece fiyat artışı değil. Bence Heroku ve bulut sağlayıcıları psikolojik fiyat çıpası etkisinden faydalanıyor. Kullanıcılar hizmeti ilk kullanmaya başladıklarında bir fiyat referansı oluşturuyor ve sonrasında beklentileri sadece doğrusal biçimde değişiyor. Oysa gerçek hesaplama donanımının performansı geometrik olarak artıyor; kullanıcı bunu ancak doğrusal şekilde hissediyor. Heroku fiyatları en az 7 yıldır değişmedi ama donanım inanılmaz gelişti. Bu yüzden bunun dolandırıcılık gibi gelmesinin sebebi, aslında 2025'in referans noktasını 2010'ların ortasındaki fiyatlarla karşılaştırıyor olmanız. Büyük bulut sağlayıcıları da yeni donanım performansını açmak için engeller koyuyor; yeni SKU'lar, yükseltmeler vs. Heroku'nun ise bu konuda rekabet baskısı yoktu, bu yüzden fiyatı sabit tuttu. Bu tarz yazılar da yeni bir mühendis donanım performansındaki sıçramayı fark ettikçe tekrar tekrar ortaya çıkıyor.

  • 50 dolara 1 GB RAM dyno'nun soygun olduğunu söyledin ama AWS de çok farklı değil. Aylık 50 dolara m7a.medium alıyorsun; 1 vCPU ve 4 GB RAM veriyor. RAM daha fazla ama AWS'nin neden bu kadar para bastığını anlamak zor değil.

  • Yazılım stack'inin tamamını Sidekiq benzeri şekilde uygun fiyata lisanslayan bir model olsa keşke fikrine katıldığım için canine.sh'i open source yaptık. PaaS sağlayıcılarının, zaten marjlı bulut hizmetlerinin üstüne bir de aşırı marj koymasının bir sebebi olmadığını düşündük.

  • Bu, mahalledeki bir tamircide yağ değişiminin ya da restoranda yediğin bifteğin, evde kendin yaparsan daha ucuza gelir demeye benziyor.

• Bulut, tek bir sunucuyla ne kadar çok şey yapılabildiğini unutturuyor. Sadece staging ortamı için bile pahalı bulut hizmeti kullanmak bana mantıklı gelmiyor ama günümüzde bulutun birçok parçası birbirine karmaşık şekilde bağlı olduğu için neden tercih edildiğini anlayabiliyorum.

  • Birden fazla geliştiriciye bulutun temellerini öğretmek ve birkaç bulut uzmanı bulundurmak uzun süre boyunca maliyet açısından mantıklı olabilir. staging/prod ortamlarını birbirine benzetirseniz hatalar da daha hızlı yakalanır. Sonrasında bir noktada bulut faturaları personel maliyetini aşmaya başlar ve işte o zaman buluttan çıkmak gerçekten kazanç sağlar. Sonunda kendi sunucularınıza geçtiğinizde, ekip ve donanım maliyetini aşan bir eşik mutlaka geliyor diye düşünüyorum.

  • Bulut yüzünden geliştiriciler Linux sunucuların kendisinden korkar hale gelmiş gibi. Bence marjın büyük kısmı geliştirici kaygısından geliyor. Oysa self-hosting aslında kolay ve eğlenceli. Heroku ya da Vercel gibi şeyler bana hiç çekici gelmedi; en baştan kendi sunucunu ayağa kaldırmaktan daha iyi bir deneyim olmadığını düşünüyorum. Her geliştiricinin bunu en az bir kez denemesini tavsiye ederim.

  • Prod ortamını, gerçek işletimle olabildiğince benzer olacak şekilde tamamen kopyalamak çok faydalı. Dağıtım süreci benzer olduğu için zaman da kazandırıyor ve gerçek prod'a daha yakın test yapmanızı sağlıyor.

  • Bunun üzerine kurulu bir altyapı öğrenme sitesi yapmak eğlenceli olabilir. Bulutta X kadar kaynak verilir, belirli bir yükü karşılayacak şekilde yapılandırman gerekir ve sonra insanlar performans puanlarıyla yarışır.

  • 2006 civarında AWS'nin en küçük makinesi iyi bir geliştirme masaüstü bilgisayarı boyutlarındaydı ve iki yıldan fazla kiralamadan maliyetini çıkarmıyordu. Bugünün AWS makineleri ise cep telefonu ya da ucuz dizüstü seviyesinde; 3-6 ay kiralamak bile donanımı satın almaktan daha pahalıya geliyor. %75 indirim almıyorsan, bulut yerine on-prem hem personel hem maliyet açısından daha avantajlı.

• Merhaba, Disco adlı open source bir PaaS'ı arkadaşım Antoine Leclair ile birlikte geliştiriyorum. Son zamanlarda self-hosting ve buluttan çıkış hakkında çok fazla tartışma dönüyor. Sorularınız varsa memnuniyetle konuşuruz.

  • "Sunucu kaynak kullanımının çok düşük olduğu" ifadenin yanına şunu da eklemek gerekir: htop'taki load average CPU çekirdeği başınadır. Mesela 8 çekirdekte load average 0.1, toplam CPU kapasitesinin yaklaşık %1,25'i demektir. Blog yazısını keyifle okudum; bu tür kalıplardan ben de iyi dersler çıkarıyorum.

  • Coolify gibi araçlarla kıyaslandığında Disco'nun özellikle neyi daha iyi sunduğunu merak ediyorum. Servislerimin çoğunu Hetzner VPS üzerinde barındırıyorum; Disco'ya özgü güçlü yanlar varsa duymak isterim.

• Hack Club'da benzer bir deneyim yaşadık. Bizim kâr amacı gütmeyen kuruluşumuz lise öğrencilerinin kodlama ve elektroniğe giriş yapmasına odaklanıyor. Eskiden Heroku kullanıyorduk ama mesele yalnızca maliyet değildi; bu küçük yardımcı uygulama gerçekten ayda 15 dolar edecek kadar değerli mi diye düşünmeye başlamıştık. Bu yıl Coolify ile self-hosting'e geçip Hetzner'da aylık 300 dolarlık tek bir sunucuda 300 servis çalıştırıyoruz. Sonuç olarak çok daha fazla kod dağıtabildik. En büyük farkındalığımız şu oldu: eğer %99,99 değil de %99 uptime sizin için yeterliyse, önünüzde çok daha geniş bir dünya açılıyor. Çoğu geliştirici aracı %99,99'a takıntılı ama %99 yeterliyse işler çok daha verimli yürütülebiliyor. Disco da ilgimi çekti; kesinlikle denemeyi planlıyorum.

  • Teşekkürler, Disco servisleri hakkında merak ettiğin bir şey olursa Discord üzerinden her zaman soru sorabilirsin. Buna benzer iki örnek var: Porto Riko'daki bir bootcamp/geliştirici okulu öğrencilerin final projelerinin tamamını tek bir VPS'e dağıttı ve Recurse Center'da tek bir Raspberry Pi ile 75 web projesi barındırılıyor (link).

  • Ayrıca gerçekten %99,99 gerekiyorsa hyperscaler'lardan kaçınmak gerektiğini düşünüyorum; AWS'nin yakın zamanda yaşadığı saatler süren kesinti bunun bir örneği.

  • 300 tane mi? Her bir servisin ne yaptığını merak ettim.

• Duruma bakınca self-hosting gerçekten çekici bir çözüm gibi görünüyor ama yazının kendisi hakkında da bir şey söylemek istiyorum. Bu yazı bana yoğun şekilde AI tarafından editlenmiş gibi geldi ve gerçekten de "Bridging the Gap: Why Not Just Docker Compose?" bölümü, Disco ürün açılış sayfasındaki "Powerful simplicity" kısmının bire bir kopyası. Bu blog yazısı zaten ana sayfalarında gösterdikleri tek vaka çalışması gibi duruyor.

  • Kesinlikle haklısın; bunu destekleyecek üç neden sayabilirim ama şaka yapıyorum. Kütüphanemiz open source ve Idealist'in para tasarruf etmesine katkı sağlamış olmaktan gurur duyuyoruz. Bununla övünmek reklam sayılıyorsa, evet, bundan gurur duyuyorum.

  • Bunun bir pazarlama yazısı olmasının neden sorun olduğunu düşündüğünü merak ediyorum. Hacker News yönergelerinde yasak olduğu için mi, yoksa her pazarlama içeriğinin açıkça etiketlenmesi gerektiğini mi düşünüyorsun? Dünyada pazarlama olmayan yazı neredeyse yok.

  • Fiyat rekabeti üzerine bir pazarlama blog yazısı yazıp kendi sitelerinde fiyatı açıklamayıp sadece toplantı rezervasyonu almaları, benim için fiyat konusunda en büyük red flag.

  • Ben de gelir modelini hemen merak edip araştırdım ama yalnızca yakında açıklanacakmış gibi bir izlenim edindim.

  • Pazarlama unsuru taşıyan ilk yazı bu değil; vaka temelli bir yazıyla pazarlama yapılmasında neyin sorun olduğunu anlamıyorum. Oldukça yumuşak bir örnek ve pazarlama yönü olsa da ilginç ve faydalı buldum.

• Heroku fiyatları gerçekten delirmiş durumda. Yaklaşık 10 yıl önce çalıştığım bir startup'ta, sadece HTML tablolarıyla QR kod üretip e-postada göstermek için çalışan bir servise ayda 10.000 dolardan fazla harcandığını görünce şok olmuştum. Kod başına yaklaşık 0,15 dolar ediyordu. Geliştirme lideri daha önce hiç profil çıkarma yapmadığı için bunu kod başına 0,01 dolara indirdi ama yine de saçma.

  • Aslında kayda değer bir şey değil; tek bir QR kod üretmenin neden o kadar pahalı olduğunu anlayamıyorum. Sadece edge cloud hosting kullansan bile bunu bedavaya yapabilirsin.

• Neden 6 tane staging sunucusuna ihtiyaç olduğunu pek anlamadım (her biri 500 dolar). Eğer sebep büyük ekipse, aylık 3.000 dolarlık sunucu maliyeti yılda 100 bin doların üzerindeki çalışan maliyetine kıyasla çok küçük kalmıyor mu? idealist.org'a baktım; sonuçta sadece bir iş ilanı panosu gibi duruyor, bana fazla abartılı geldi.

  • 6 staging sunucusu; main, dev ve geliştirici olmayan QA çalışanlarının çeşitli branch'leri doğrudan kontrol edebilmesi içindi. Her staging dağıtımında Performance-M dyno, birkaç Standard dyno, RabbitMQ, veritabanı vs. derken maliyet hızla büyüyordu. Idealist'in servisi günde 100.000 kullanıcıya ulaşıyor; güvenilirlik ve hızın arkasında ciddi teknik iş var.

  • Okuduğum kadarıyla her geliştirici için birden fazla servisi aynı anda ayağa kaldıran dev ortamları oluşturmak amacıyla staging sunucuları kurmuşlar; bu yüzden sayıları fazla olmuş gibi görünüyor.

  • Gerçek maliyet hesabında insan gücü maliyetinin (man-day) çoğu zaman göz ardı edildiğini düşünüyorum.

• Heroku'dan çıkarken Django sitesini ve veritabanını sadece dump alıp bırakmak istiyorum; sistemi kendim yönetmeden kullanabileceğim en iyi seçenek ne olur merak ediyorum.

  • Render.com büyük ihtimalle en yakın seçenek ve kullanmaktan gerçekten memnunum. İş akışı da Heroku ile neredeyse aynı, daha ucuz ve gece yeniden başlatmaları ya da Python'ın yeni sürümlerine destek gibi konularda da memnunum.

  • Docker Swarm öğrenmeni de öneririm. Dağıtım, container'ı bir kez push edip tek komut çalıştırmak kadar kolay. Ayrıca dağıtım ve servis diff işlevlerini bir arada sunan ücretsiz bir CLI aracı olan rove.dev'i de kendim yaptım. Ya da VM tabanlı bir PaaS de tercih edilebilir; Semaphore, Dokku, Dokploy gibi seçeneklere bak.

  • İstediğin VPS'i fiyat/performans/konum/destek dengesine göre seçip üstüne Coolify, Dokploy gibi istediğin dağıtım aracını bağlayabilirsin. Yakın zamanda Coolify ve Mythic Beasts ile Django/Postgres'i Google App Engine'den taşıdım; bilgilerim epey paslanmış olmasına rağmen geçiş gerçekten çok kolaydı.

  • Bence Hetzner'da tek bir sunucu açıp sadece nginx ve systemctl servisleri ayarlaman yeterli olur.

  • PythonAnywhere (link) de iyi bir seçenek.

• Harika bir proje. Dokümanlara baktım; GitHub entegrasyonu Disco için zorunlu gibi görünüyor, doğru mu? Bir de ayrı bir build süreci olmadan kendi registry'mdeki mevcut Docker image'larını doğrudan deploy edip edemeyeceğimi merak ediyorum (Kamal içindeki --skip-push --version latest benzeri).

  • Evet, şu an için GitHub entegrasyonu gerekiyor. Ama Disco mevcut Docker image'larını doğrudan çekip deploy edebiliyor da (RabbitMQ'yu bu şekilde self-host ediyoruz). Örnek olarak Meilisearch image'ının nasıl deploy edildiğine buradan ve bu eğitimden bakabilirsin. Genelde build alıp registry'ye push eden bir akış mı kullanıyorsun? Kendi dağıtım sürecini daha ayrıntılı duymak isterim.