Discord Botu İçin Minimum VDS: Net CPU/RAM/Disk Rehberi (2026)

Discord botu çalışırken asıl sorun çoğu zaman “yeterince hızlı mı?” sorusundan ziyade gecikme (latency), log/backup yönetimi ve doğru kaynak tahsisi olur. Bu yazıda, Discord botunuzun beklediğiniz komut sayısına göre ihtiyaç duyacağı minimum VDS donanımını netleştiriyoruz. Hedef; gereksiz pahalı kapasiteye çıkmadan, aynı zamanda botun mesaj/komut yanıtlarında takılmamasını sağlayacak eşiği belirlemek.

Discord botu için minimum VDS’i belirleyen 5 faktör

Minimum VDS seçimi, sadece CPU veya RAM saymak değildir. Aşağıdaki 5 bileşen, “botum düşüyor mu?” sorusunun ana yanıtını verir:

1) Botun iş yükü tipi: komut mu, I/O mu?

• Sadece mesaj okuma + basit komutlar: Daha çok CPU hafif, bekleme süreleri (I/O) önemlidir.
• API çağrıları (hava durumu, oyun istatistikleri vb.): Ağ gecikmesi ve outlier (ani yavaşlama) riski öne çıkar.
• Veritabanı kullanan sistemler (üyelik/puan/kupon): Disk ve özellikle disk IOPS kritikleşir.

2) Guild (sunucu) ve kanal sayısı

Guild sayısı büyüdükçe, botun olay (event) trafiği artar. Discord tarafında “her mesaj” botun yakaladığı bir event olabilir.

3) Mesaj başına komut yoğunluğu (QPS değil, komut/interval)

Botun 1 saatte aldığı komut sayısını düşünün: - 0-3.000 komut/ay: Minimum seviye. - 3.000-30.000 komut/ay: Orta seviye. - 30.000+ komut/ay: Yüksek seviye, yedeklilik ve ölçekleme planı gerektirir.

4) Eşzamanlı kullanıcı akışı (aynı anda tetiklenen komutlar)

Özellikle slash command kullanan botlarda, aynı anda yapılan işlemler CPU ve bellek üzerinde pik oluşturur.

5) Çalıştırma yöntemi: Node.js/Python + process modeli

• Tek process: Basit kurulum.
• pm2 gibi process yöneticisi: Yeniden başlatma ve log yönetimi kolaylaşır.
• Docker: Aynı VDS üzerinde tekrarlanabilir kurulum sağlar; ama disk alanı ve imaj boyutu planlanmalı.

Minimum VDS spec tablosu (Net eşiklerle)

Aşağıdaki tablo, Discord botunun tipik iş yüklerine göre minimum ve “güvenli” kapasiteleri gösterir. Değerler, Node.js/Python tabanlı standart botlar için pratik eşiklerdir.

Not: Gerçek ihtiyacınız bot kodunuzun verimsizliğine göre değişir. Yine de doğru başlangıç için bu seviyeler net bir referanstır.

Minimumda “neden 1-2 GB RAM” sıkışır?

Discord gateway olaylarını (events) yönetirken aynı anda: - slash command parse işlemleri, - rate limit kuyruğu, - log buffering, - basit caching yürür. 1 GB RAM seviyesinde, paketler (npm bağımlılıkları), veritabanı bağlantı havuzu ve log dosyası büyümesi birleşince bellek baskısı oluşur.

Bu yüzden “minimum” tablosu, botunuz gerçekten basit değilse pratikte “en az 2 GB” çizgisine yaklaşır.

Ağ (network) ve gecikme: Botun hissedilen performansı burada belirlenir

Discord botlarında kullanıcı deneyimi şunlarla ölçülür: - Komut yanıt süresi (response time) - Gateway olay işleme gecikmesi (latency) - Retry/backoff sıklığı (hızlı tekrar denemeler botu yorar)

Minimum VDS seçerken şu ağ parametrelerine bakın: - Yüksek çıkış hızı (egress): Bot çok sayıda istek üretmez ama yanıtlar hızlı gelmelidir. - Paket kaybı düşük bağlantı: Özellikle API çağrıları yapıyorsanız önemli. - En azından düzenli saatlik bant genişliği: “Bitince hız düşen” planlar komut yanıtlarını dalgalı yapar.

Net pratik: Eğer botunuz bir dış API’ye sık sık gidiyorsa, VDS lokasyonu Discord gateway’e göre değil; API lokasyonuna göre de gecikme etkiler. Bu yüzden kendi kullanım senaryonuza göre bölge seçimi yapın.

Disk ve IOPS: DB’li botta “minimum”u belirleyen asıl şey

Veritabanı (ör. PostgreSQL, MySQL veya hafif DB alternatifleri) kullanan botlarda gecikmenin büyük kısmı disk IO kaynaklı olur.

IOPS neden kritiktir?

• Küçük ama sık yazımlar (loglar, puan güncellemesi)
• Aynı anda çok istek geldiğinde transaction kuyruğu
• Index taraması sırasında artan rastgele okuma

Bu işlerde düşük IOPS, komutlarınızın yanıt süresini sabit değil “kademeli yavaşlama” şeklinde etkiler.

Hangi disk yaklaşımı daha mantıklı?

• DB yoksa: SSD tek başına çoğu zaman yeterli.
• DB varsa: NVMe SSD tercih edin, en azından “hızlı SSD” kategorisi seçin.
• Yedekleme (backup) için disk planlayın: Basit bir cron ile yaptığınız export dosyaları bile 20-30 GB seviyesinde hızlı birikir.

Çalıştırma mimarisi: Minimum VDS’i boşa harcatmayan ayarlar

Minimum VDS seçseniz bile yanlış mimari kaynakları tüketebilir. Discord botu için pratik mimari önerileri:

Node.js botlarda pm2 ve bellek limiti

• pm2 ile yeniden başlatma: Crash döngüsünü kontrol altına alır.
• Logları dosyada biriktirmeyi kontrol edin (logrotate veya pm2 log rotation).
• Kod tarafında gereksiz global cache birikimini kapatın.

Örnek (konsept): pm2 start index.js --max-memory-restart 300M

Python botlarda worker yaklaşımı

• İhtiyaca göre tek process + asenkron (async) kullanın.
• Yoğun CPU işini ayrı worker sürecine alın; tek process hem bot event hem ağır işi birlikte taşırsa gecikme artar.

Reverse proxy şart mı?

Discord botlar genelde HTTP sunmaz. Webhook kullanmıyorsanız Nginx gibi ek katman şart değildir. Sadece botunuzun durum sayfası veya ek API’si varsa düşünün.

Yedekleme ve log yönetimi: Minimum VDS’te “en sık yapılan hata”

Minimum VDS’te en çok sorun çıkaran şey disk dolmasıdır. Bu yüzden yedekleme stratejisini baştan kurgulayın.

Minimum yedekleme planı (net kural)

• Konfigürasyon (env/secret hariç) yedekleyin.
• Veritabanı varsa: günlük yedek + 7 günlük retention (saklama).
• Logları: dosya boyutunu sınırlandırın (logrotasyon).

Örnek akış: - cron ile DB dump - dump dosyasını dış depolamaya gönderme (S3 uyumlu storage gibi) - VDS’te sadece son 24-48 saati tutma

Bu yaklaşım, minimum diskinizi “yedek yüzünden” doldurmayı engeller.

“Minimum”u doğrulama testi: Kurulumdan sonra 60 dakikalık net kontrol

VDS’i satın aldıktan sonra kapasiteyi varsayım ile değil test ile doğrulayın.

Kontrol listesi (60 dakika)

• Botun normal komut akışında CPU kullanımı: 15-40% bandında tutun.
• RAM: Sürekli artmıyorsa (leak yoksa) hedef %60 altı.
• Event işleme süresi: Slash command response süreleri düzenli ve dalgalı değil.
• DB kullanımı varsa: slow query yok, transaction queue birikmiyor.
• Log boyutu: Saatteki büyüme öngörülebilir.

Hızlı teşhis sinyali

• CPU %70+ sürekli: Kod içinde senkron blok veya gereksiz hesaplama var.
• RAM sürekli yükseliyor: bellek kaçağı veya sınırsız cache.
• Response gecikmeli ama CPU/RAM düşük: disk/IOPS veya DB index sorunu.

Minimum VDS seçerken sağlayıcıda bakılacak 8 teknik madde

Aşağıdaki maddeler, “aynı RAM/CPU yazsa da neden fark olur?” sorusunu kapatır:

1. vCPU modeli: Paylaşımlı mı, tahsisli mi?
2. RAM garantisi: Burst/limit politikası.
3. Disk türü: SSD mi NVMe mi? IO performans yaklaşımı.
4. Günlük/aylık I/O limiti var mı?
5. Ağ performansı: bant genişliği ve hız düşüşü politikası.
6. Bölge/konum: Discord gateway + kullandığınız API’ler.
7. Snapshot/backup imkanı: kendi backup planınıza engel mi?
8. Güncelleme politikası: çekirdek/host güncellemeleri sırasında kesinti riski.

Önerilen net başlangıç senaryoları

Botunuzun profiline göre en risksiz başlangıç şu şekilde özetlenebilir:

• Basit komut botu: 1 vCPU / 2 GB RAM / 30 GB SSD
• API çağrılı ve küçük DB: 2 vCPU / 4 GB RAM / 50 GB SSD
• DB’li ve kullanıcı/premier gibi değer güncelleyen bot: 4 vCPU / 8 GB RAM / 80 GB NVMe

Bu seviyeler, “iş yükü artınca hemen kaynak bulamama” riskini azaltır.

Sonuç: Harekete geçmek için 3 adım

Önce botunuzun komut/olay yükünü (günlük komut ve event yoğunluğu) ölçün, ardından yukarıdaki tabloya göre en düşük RAM ve disk seviyesini seçin. Kurulumdan sonra 60 dakikalık CPU/RAM/disk/log kontrolü yapın; DB varsa özellikle IOPS kaynaklı gecikmeleri gözleyin. Bu üç adımı uyguladığınızda minimum VDS seçimi “tahmin” olmaktan çıkar, ölçüme dayalı karar haline gelir.