Python/Django hosting rehberi: VDS mi, managed mı?

Python ve özellikle Django tabanlı projeler, doğru altyapı seçilmediğinde performans düşüşü, güvenlik zafiyetleri ve sürüm güncelleme sorunları üretir. Bu rehberde; Django için gereken bileşenleri (WSGI, reverse proxy, veri tabanı, statik dosyalar, loglama) netleştirip VDS/VPS ile managed yaklaşımları karşılaştıracağız. Son bölümde, proje türüne göre (küçük site, büyüyen uygulama, yoğun trafik) uygulanabilir seçim kontrol listesi ve kaynak planlaması bulacaksınız.

Django için hostingte “zorunlu” bileşenler

Django tek başına bir uygulama değildir; servis katmanları bir arada çalışmadığında “çalışıyor ama üretime hazır değil” durumu oluşur. Hosting seçmeden önce şu bileşenlerin kimde olacağını belirleyin: sağlayıcı mı siz mi?

1) Uygulama çalıştırma: WSGI sunucusu (Gunicorn/uWSGI)

Django üretimde genellikle bir WSGI sunucusu ile servis edilir: - Gunicorn (en yaygın) - uWSGI (gereken senaryolarda)

Önemli olan hostingin şu konularda ne kadar destek verdiğidir: - Python sürümü (ör. 3.10/3.11/3.12) - Bağımlılık yönetimi (requirements.txt, venv) - Süreç yönetimi (systemd ile yeniden başlatma gibi)

2) Reverse proxy: Nginx

Klasik mimari şu şekildedir: - Kullanıcı → Nginx → Gunicorn → Django

Bu kurulumun amacı: - TLS/SSL sonlandırma (HTTPS) - G/Ç (I/O) verimini artırma - Statik dosyaları (CSS/JS) hızla servis etme

3) Statik ve media dosyaları

Django “static” ile “media”yı ayırır. Üretimde en net çözüm: - static dosyalar: Nginx üzerinden servis veya objeye dayalı depolama - media: kontrollü bir depolama (sunucu diski veya dış depolama)

Bunun hosting tarafındaki sonucu şudur: - Dosya sistemi dolarsa uygulama etkilenir - Çok kullanıcı varsa (upload, avatar, dosya ekleme) disk planı kritiktir

4) Veri tabanı (DB)

Django tipik olarak PostgreSQL veya MySQL kullanır. Seçim netleşmeli: - DB aynı makinede mi? (tek sunucu yaklaşımı) - DB ayrı yönetilen servis mi? (managed database)

Tek makinede DB, küçük projelerde maliyeti düşürür; ancak trafik büyürken disk/IO kilitleri ve yedekleme yönetimi zorlaşır.

5) Yedekleme ve kurtarma

Django projelerinde “yedekleme” sadece kod değildir: - Veritabanı dump/backup - dosyalar (media ve upload) - ortam (env) ve gizli anahtarlar

Burada kriteriniz şudur: Yedekleme sıklığı + geri dönüş (restore) süresi + yedeklerin test edilip edilmediği.

VDS/VPS mi managed hosting mi? Net karar çerçevesi

Django için en sık yapılan hata, “hosting aldım, Django kurdum” ile “üretime aldım”ı aynı şey sanmaktır. Aşağıdaki karşılaştırma kararınızı hızlandırır.

Managed hosting neyi üstlenir?

Managed yaklaşımda sağlayıcı genellikle şunların bir kısmını devralır: - Sunucu güncellemeleri ve güvenlik yamaları - Process/restart yönetimi - Logların toparlanması (örn. panel veya otomatik iletim) - Backup politikası - Ölçekleme için yönlendirme

VDS/VPS ne zaman daha mantıklı?

VDS/VPS, uygulamanın mimarisini ve süreç yönetimini tamamen siz kontrol edersiniz. Bu şu durumlarda daha avantajlıdır: - Özel Nginx/worker ayarları gerekiyorsa - Uygulama farklı servislerle (Redis, Celery, özel queue) ayrışıyorsa - CI/CD, altyapı kodu (Terraform/Ansible) gibi süreçler kuruyorsanız

Karşılaştırma tablosu: Django için maliyet ve operasyon

Aşağıdaki tablo “toplam sahip olma maliyeti” mantığıyla hazırlanmıştır. Fiyat tek başına belirleyici değildir; arıza anında kaç saat harcayacağınız ve yedekleme/ops yükü fark yaratır.

Kaynak ihtiyacı nasıl hesaplanır? (Net yöntem)

Django için doğru “RAM/CPU/Disk” tahmini, gereksiz maliyeti engeller. Burada basit ve uygulanabilir bir yöntem var.

1) Trafik ve iş türünü ayırın: Web vs async işler

• Web istekleri: Gunicorn worker’ları ile yanıt
• Async işler: Celery gibi queue sistemleri (redis/rabbitmq)

Eğer uygulamanızda yoğun arka plan işi varsa, tek CPU ile hem web hem worker aynı anda yüklenir. Bu yüzden planlamada worker ayrımını düşünün.

2) Worker sayısı için pratik kural

Gunicorn worker sayısını “CPU çekirdeği” ve “eş zamanlılık” ile ilişkilendirin. Net bir sayı yok; ancak doğru aralıkla başlayabilirsiniz: - Önce 2-4 worker ile test edin - 4XX/5XX artıyorsa veya response süresi yükseliyorsa worker’ı 1-2 adım artırın - CPU sürekli %80+ doluyorsa worker sayısını değil, instance kapasitesini veya kod/DB performansını gözden geçirin

3) Disk ve IO: media/upload varsa kritik

Diskte şu kalemler büyür: - media (upload) - log dosyaları (uygun rotasyon yoksa) - geçici dosyalar

Basit kontrol: - Log rotasyonu yoksa günlük büyümeyi ölçün - Media büyümesini (ör. kullanıcı başına ortalama MB) tahmin edin

4) Redis kullanımı planı

Birçok Django kurulumunda Redis şu amaçla kullanılır: - cache - session backend - Celery broker

Redis ayrı kurulum gerektirip gerektirmediği hosting modeline bağlıdır: - Managed Redis sunulursa operasyon azalır - Redis’i aynı VDS’ye koyarsanız maliyet düşer ama IO/CPU paylaşımı risk olabilir

Sunucu lokasyonu ve gecikme (latency) etkisi

Django uygulamasında lokasyon, özellikle kullanıcılar farklı bölgelerden erişiyorsa fark yaratır. Net yaklaşım: - Uygulama kullanıcıya yakın lokasyonda olsun - DB/Redis aynı bölgede olsun (cross-region gecikme DB performansını etkiler)

DNS ve HTTPS gecikmesi

HTTPS’te TLS kurulumu ve HTTP/2/HTTP/3 davranışı gecikmeyi etkiler. Hosting seçiminde şu kontrolü yapın: - Sitede otomatik SSL (Let’s Encrypt veya sağlayıcı sertifika sistemi) var mı? - HTTP/2 aktif mi? - Nginx reverse proxy hazır mı?

Hangi Django projesi hangi hosting türüyle daha hızlı oturur?

Aşağıdaki seçim listesi, “proje türüne göre” net öneri verir.

Küçük veya tek-tenant projeler (ör. 1-2 app, düşük upload)

• Tercih: VDS/VPS (küçük instance) veya hafif managed
• Gerekçe: maliyet verimliliği
• Minimum hedefler:
• Nginx + Gunicorn çalışıyor olsun
• DB için yedekleme otomatik olsun
• log rotasyonu ayarlı olsun

Büyüyen uygulama (aboneler, sık istek, raporlama)

• Tercih: VDS/VPS + yapılandırmayı sizin yönetmeniz veya “managed ama esnek” yaklaşım
• Gerekçe: queue/worker tuning ve DB performansı kritik olur
• Yapılacaklar:
• Celery/queue ayrımını planlayın
• DB için bağlantı havuzu (ör. uygun ayarlar) uygulayın
• Nginx timeout ve worker ayarlarını trafikle test edin

Yoğun trafik veya kurumsal ihtiyaçlar (SLA beklentisi, ekip büyüklüğü)

• Tercih: managed dedicated/manged platform veya daha güçlü managed altyapı
• Gerekçe: güvenlik güncellemeleri, backup, izleme ve arıza yönetimi hız ister
• Yapılacaklar:
• yedek (backup) restore testini planlayın
• izleme ve alarm (CPU, memory, DB bağlantıları, 5xx) kurun

VDS/VPS seçerken net kontrol listesi

Aşağıdaki maddeler, “aynı fiyata farklı performans” yaşanmasını engeller.

1) Sanallaştırma ve performans

• Bilinen bir KVM/benzeri sanallaştırma tercih edin
• VM başına CPU tahsisini inceleyin (oversell / paylaşım var mı)

2) Depolama türü: SSD-NVMe etkisi

Django’da en çok IO etkisi şu durumlarda görülür: - yoğun DB yazma - çok sayıda log - media upload

Bu yüzden disk türünü “NVMe SSD” lehine tercih edin; en azından DB ve loglar için. (Not: Sadece disk türü tek başına her şeyi çözmez; DB index ve sorgu da belirleyicidir.)

3) Ağ kalitesi

• DDoS koruması varsa aktif edin
• Bant genişliği limitleri ve “burst” politikalarını okuyun

4) İşletim sistemi ve paket güncellemeleri

• Ubuntu/Debian tabanlı dağıtımlar güncelleme ekosistemi açısından daha kolay yönetilir
• Otomatik security update süreci net olmalı

Managed hosting seçerken net kontrol listesi

Managed hizmette “her şey hazır” beklentisi doğru; ancak sınırlamalar mutlaka vardır.

1) Python ve dependency yönetimi

• Hangi Python sürümleri destekleniyor?
• requirements/pyproject süreçleri nasıl deploy ediliyor?

2) Worker ve queue yönetimi

• Gunicorn worker sayısını ve timeout ayarlarını değiştirebiliyor musunuz?
• Celery/queue desteği var mı?

3) Loglar ve hata ayıklama

• Uygulama logları (Django), web sunucusu logları (Nginx) ve sistem logları ayrıştırılıyor mu?
• Hata durumunda hangi metrikleri görebiliyorsunuz?

4) Yedekleme politikası ve restore süresi

• Yedekler hangi sıklıkla alınır (ör. günlük + belirli saatler)?
• restore test edilmeden “var” demeyin; süreyi ve geri dönüşün pratikte nasıl yapıldığını sorun.

Uygulama tarafında (hostingden bağımsız) kesin yapılacaklar

Hosting seçiminden bağımsız, Django performansını belirleyen temel ayarlar vardır. Bu adımlar doğru değilse, en pahalı sunucu bile yetersiz kalır.

Nginx + statik dosya stratejisi

• static dosyaları doğrudan Nginx üzerinden servis edin
• Gzip/Brotli (uygunsa) ile sıkıştırmayı kontrol edin

Veritabanı sorgularını iyileştirin

• N+1 sorgu problemlerini giderin (Django ORM optimizasyonları)
• index eklerini ihtiyaç durumuna göre planlayın

Cache’i doğru yere koyun

• sayfa/fragment cache mantığı
• Redis varsa cache layer’ı kullanın

Sonuç: Hızlı karar için aksiyon planı

Django için hosting seçimini netleştirmek adına tek bir sprint planı uygulayın: Önce mevcut trafik senaryonuzu web istekleri + async işler olarak ayırın, ardından VDS/VPS ile managed arasındaki farkı “yedekleme, güvenlik yamaları ve worker/queue kontrolü” üzerinden değerlendirin. Küçük projede kurulum süresi ve maliyeti önceliklendirin; büyüyen projede DB/queue tuning kapasitesini, yoğun projede ise log-izleme ve restore süreçlerinin hazır olmasını esas alın.

Kararınız net olsun diye bir sonraki adım şudur: Seçtiğiniz hosting modelinde Nginx + Gunicorn + SSL + yedekleme planını kurduktan sonra 1-2 saat yük testi yapın ve 5xx oranı, ortalama response süresi ve CPU/RAM piklerini kaydedin. Sonuçlar, hangi modeli “gerçek performans” tarafında desteklediğini tek seferde gösterecektir.