Hazırlayan: Can Demiray · Bilgisayar Programcısı | Hostturka
22 Ekim 2026 · SaaS geliştiricileri için karar rehberi
Supabase’i kendi VPS, VDS veya fiziksel sunucunuzda çalıştırmak; altyapı, veri yerleşimi ve kaynak planlamasında daha fazla kontrol sağlayabilir. Ancak sunucu kiralamak, yönetilen bir backend hizmeti satın almakla aynı şey değildir. Yedekleme, güvenlik güncellemeleri, izleme ve arıza sonrası geri dönüş için de bir planınız olmalıdır.
Bir SaaS ekibi için doğru soru yalnızca “Supabase’i kurabilir miyiz?” değildir. “Ürün büyürken bu altyapıyı kim işletecek ve kesinti olduğunda kim müdahale edecek?” soruları da kararın parçasıdır. Bu yazı, kurulum komutlarından önce verilmesi gereken bu kararı ele alır.
Geliştirici bilgisayarında Supabase CLI ile açılan yerel ortam, geliştirme ve test içindir. Supabase, bu ortamın üretim için güvenli hâle getirilmediğini ve dış trafiğe açılmaması gerektiğini belirtir. Müşterilere hizmet verecek bir kurulum için resmî self-hosting yaklaşımı değerlendirilmelidir. [1]
Bu makalede “kendi sunucusunda Supabase”, sizin seçtiğiniz sunucuda işletilen self-hosted dağıtımı ifade eder. Sunucu bir veri merkezinde olabilir; geliştiricinin bilgisayarında bulunması gerekmez. Bu ayrım, deneme ortamını yanlışlıkla canlı müşteri altyapısına dönüştürmemek açısından önemlidir.
Uygulama sunucunuz, veritabanınız ve dosya depolamanız arasındaki ağı tasarlayabilirsiniz. Aynı özel ağda çalışan bileşenler, gereksiz internet geçişlerini azaltabilir. Ancak düşük gecikme veya yüksek performans kendiliğinden oluşmaz: sorgular, disk erişimi, bağlantı sayısı ve uygulama mimarisi birlikte ölçülmelidir.
Sunucu konumunu, erişim kurallarını, bakım saatlerini ve yedeklerin nerede tutulacağını seçebilirsiniz. Buradaki avantaj karar yetkisidir. Bu yetkiyi bir erişim politikası, yetki listesi ve düzenli bakım takvimiyle desteklemediğinizde, yalnızca daha fazla ayarı yönetmek zorunda kalırsınız.
Öngörülebilir yükü olan projelerde sunucu kaynaklarını uygulamanızın ihtiyaçlarına göre planlamak yararlı olabilir. Buna rağmen “self-hosted her zaman ucuzdur” sonucu çıkarılamaz. Az kullanılan bir üründe sunucu boşta kalabilir; yoğun bir üründe ise yedekleme, depolama ve operasyon maliyeti artabilir.
Gerçek maliyet hesabı: Sunucu + yedek depolama + ağ trafiği + izleme + e-posta/SMS gibi dış servisler + yönetim zamanı + kesinti riskinin işletmeye etkisi. Yönetilen platformla karşılaştırırken aynı kapsamı değerlendirin.
Self-hosted dağıtımda işletim sistemi ve servis bakımı, PostgreSQL yönetimi, güvenlik, ölçekleme ve erişilebilirlik sizin sorumluluğunuzdadır. Yönetilen platformdaki branching, yönetilen yedek/PITR ve Management API gibi özelliklerin self-hosted dağıtımda aynı biçimde sunulduğunu varsaymayın; güncel özellik farklarını kontrol edin. [1]
Teknik ekip küçükse altyapıya ayrılan her saat, ürün geliştirmeden ayrılan zamandır. Gece meydana gelen bir disk doluluğu veya başarısız güncelleme için sorumlu kişi belli değilse, düşük sunucu faturası doğru karar verdiğinizi göstermez.
| Seçenek | Ne zaman değerlendirilir? | Satın almadan önce sorun |
|---|---|---|
| VPS / sanal sunucu | Kaynak ihtiyacı ölçülerek büyütülecek başlangıç projelerinde | CPU paylaşımı, RAM garantisi, disk I/O sınırı ve büyütme koşulları nedir? |
| VDS | Daha belirgin kaynak tahsisi beklenen iş yüklerinde | “VDS” adı altında tam olarak hangi kaynaklar tahsis ediliyor? |
| Fiziksel / dedicated sunucu | Donanım kontrolü veya sürekli yüksek kaynak ihtiyacı olduğunda | Disk arızası, donanım değişimi ve başka makineye dönüş planı nedir? |
İş yükünüze uygun kaynakları karşılaştırmak için bulut sunucu seçeneklerini; donanımın tamamına ihtiyaç duyduğunuz projelerde ise kiralık fiziksel sunucu seçeneklerini inceleyebilirsiniz. Paket seçerken yalnız CPU ve RAM miktarını değil, disk yapısını, kaynak tahsisini ve yönetim kapsamını birlikte değerlendirin.
VPS ve VDS adları sağlayıcıya göre farklı kullanılabilir. Paket adına bakarak izolasyon veya performans garantisi çıkarmayın. CPU modeli ve tahsisi, depolama gecikmesi, yedekleme kapsamı ve destek sorumluluklarını yazılı olarak öğrenin. Fiziksel sunucu da tek başına yüksek erişilebilirlik sağlamaz; tek makinedeki bir arıza tüm servislerinizi etkileyebilir.
22 Ekim 2026 tarihinde kontrol edilen resmî Docker rehberi, tüm bileşenler için minimum 2 CPU çekirdeği, 4 GB RAM ve 40 GB SSD; önerilen başlangıç olarak 4+ çekirdek, 8+ GB RAM ve 80+ GB SSD belirtir. Bunlar projenize verilmiş kapasite garantileri değildir. [2]
“Kaç kullanıcı kaldırır?” sorusunu yalnız RAM miktarıyla yanıtlamayın. Eşzamanlı aktif kullanıcı, sorgu başına iş, Realtime bağlantıları, dosya yüklemeleri ve arka plan işleri farklı yükler oluşturur. Önce temsilî veriyle test yapın; sonra RAM, CPU, disk gecikmesi ve yanıt sürelerine göre paket seçin. Bağlantı havuzu ayarlarını da uygulamanın bağlantı modeliyle eşleştirin. [3]
Birden fazla müşterinin aynı uygulamayı kullandığı yapıda kimlik doğrulama ile veri erişim yetkisini ayırın. Kullanıcının giriş yapabilmesi, başka bir müşterinin kayıtlarını okuyabilmesi anlamına gelmemelidir. RLS politikalarını ilgili tablolarda etkinleştirip müşteriler arası erişimi test edin. Gizli/service-role anahtarlarını tarayıcıya veya mobil uygulamaya koymayın. [4]
Örnek kontrol: A müşterisinin kullanıcısıyla oturum açın ve B müşterisine ait bir kaydı kimliğini değiştirerek okumayı veya güncellemeyi deneyin. Beklenen sonuç yalnız arayüzde gizlenmesi değil, sunucu tarafında erişimin reddedilmesidir. Bunu otomatik testlerinize ekleyin.
Supabase veritabanı yedeği, Storage üzerinden yüklenen dosyaların içeriğini kapsamaz. Dosyaları ayrıca koruyun; self-hosted Storage yapılandırmasında yerel dosya sistemi veya S3 gibi bir arka uç kullanılması planınızı etkiler. [5] [6]
Yedeklerin aynı makinede bulunmasıyla yetinmeyin. Ayrı bir konuma kopyalama, şifreleme ve geri yükleme denemesi planlayın. Ne kadar veri kaybını ve ne kadar kesintiyi kabul ettiğinizi önceden belirleyin. Yedek alınmış olmasıyla sistemin geri döndürülebildiğinin test edilmiş olması farklı şeylerdir.
Güncelleme aracı da tam yedek çözümü değildir: Supabase’in update.sh aracı yapılandırma dosyalarını yedekler, PostgreSQL ve Storage verilerini yedeklemez. Güncellemeden önce veri yedeklerini ve geri dönüş adımlarını ayrıca hazırlayın. [7]
Sunucu dışındaki kopyalar için Yedekleme Merkezi çözümlerini değerlendirebilirsiniz. PostgreSQL tutarlılığı, Storage dosyaları, saklama süresi ve geri yükleme yönteminin Supabase kurulumunuzla uyumu teklif öncesinde ayrıca doğrulanmalıdır.
Kendi sunucusunda barındırma; altyapı kontrolüne ihtiyacı olan, iş yükünü ölçebilen ve operasyonu üstlenecek ekibi bulunan SaaS projeleri için değerlendirilebilir. Ekibin önceliği ürün doğrulamaksa ve sunucu işletme kapasitesi yoksa, yönetilen hizmetle başlamak daha uygun olabilir. Kararı bir aylık faturadan önce toplam sorumluluk üzerinden verin.
Hostturka ile altyapınızı planlayın: Sanal/bulut sunucu ve fiziksel sunucu seçeneklerini; veritabanı büyüklüğünüz, eşzamanlı yükünüz, dosya depolamanız ve yedekleme hedeflerinizle birlikte değerlendirebiliriz. Supabase kurulumu, uygulama yönetimi ve yedeklemenin hizmet kapsamına dahil olup olmadığını teklif aşamasında netleştirin. Projenizi bize anlatın.
Can Demiray
Bilgisayar Programcısı | Hostturka
Bu yazı bir kapasite testi veya kurulum hizmeti taahhüdü değildir. Kaynaklar 22 Ekim 2026 tarihinde kontrol edilmiştir; teknik gereksinimler ve ürün özellikleri değişebilir. Kapak görseli temsili, yapay zekâ ile oluşturulmuş bir illüstrasyondur.
Türkiye (Türkçe)
Worldwide (English)