Discord Botu İçin Minimum VDS: Net Gereksinim Rehberi

Discord botu çalıştırmak, basit bir “node uygulaması açtım” işinden ibaret değildir. Gateway trafiği, loglama, zamanlayıcılar (cron), veritabanı erişimi ve anti-crash/rollback adımları doğru planlanmadığında hem performans hem de maliyet hızla büyür. Bu rehberde Discord botu için minimum VDS gereksinimini, yük profiline göre netleştiriyoruz; ayrıca hangi ayarların gerçekten etkili olduğunu ve hangi kurulumların boşa kaynak harcadığını açıklıyoruz.

Önce yük profili: 1 bot mu, 10 shard mı?

VDS boyutunu tahmin etmek yerine, botunuzun davranışını 3 ölçüte göre sınıflandırın:

Komut/etkileşim hacmi: Dakikada kaç komut çalışıyor? (Örn. 5 dk’da 20 komut gibi.)
Event yoğunluğu: Sadece komutlara yanıt mı veriyor, yoksa message update, reaction, voice-state gibi eventleri sık mı işliyor?
Durum (state) ve depolama: Kullanıcı/rol/veri saklıyor musunuz? Cache kullanıyor musunuz? Veritabanına kaç kez yazıyor/okuyorsunuz?

Discord botları genelde 3 bileşenden yük alır: 1) Discord API/Gateway bağlantıları (sürekli açık bağlantı) 2) Uygulama CPU/RAM (kodunuzun iş yükü) 3) Storage + ağ (loglar, cache, veritabanı, dış HTTP istekleri)

Bu yüzden “minimum VDS” tek bir sayı değil, net bir başlangıç paketi + büyüme eşiği yaklaşımıdır.

En yaygın senaryo: Tek instance, shard yok

Aşağıdaki şartlar varsa “tek instance” varsayın: - 1 adet Node.js botu çalışıyor - Sharding kullanmıyorsunuz (Discord.js sharding yok) - Komutlar düşük/orta yoğunlukta - Veritabanı kullanıyorsanız küçük ölçek (örn. 10-100 bin kayıt değil)

Discord botu için minimum VDS donanım (net öneriler)

Aşağıdaki tablo, botun tek instance çalıştığını varsayan başlangıç paketlerini listeler. Değerler “çalışır” seviyesinden ziyade, düzenli çalışıp servis çökmeden toparlanabilen minimumları hedefler.

Senaryo	CPU (vCPU)	RAM	Storage (SSD)	Ağ	Başlangıç amacı
A) Düşük trafik (test/erken aşama)	1	1 GB	20 GB	100 Mbps	Basit komut botu, hafif log
B) Orta trafik (aktif sunucular, düzenli event)	2	2 GB	40 GB	100 Mbps	Komut + basit cache + küçük DB
C) Yüksek trafik (çok komut, yoğun event, dış API çağrıları)	2-4	4 GB	60-80 GB	100 Mbps	Olay işleme, loglama ve retry
D) Çoklu shard (yüksek ölçek)	4+	8 GB+	80 GB+	100 Mbps+	Shard başına ölçek planı

Minimum kabul sınırları (neden bu değerler?)

RAM: Discord botları genelde event işleme sırasında kısa ömürlü nesneler üretir. RAM 512 MB seviyesine inince “GC (garbage collection) dalgalanmaları” belirginleşir ve gecikmeler artar.
CPU: Sık event + yoğun JSON işleme veya resim/konwersiyon gibi görevler CPU’yu tüketir. 1 vCPU, hafif iş yükünde yeterlidir; dış API + log + DB aynı anda geldiğinde 2 vCPU daha güvenlidir.
SSD storage: Log dosyaları ve küçük veri kayıtları için SSD, günlük yazmalarda gecikmeyi düşürür.
Ağ: Gateway trafiği sürekli akış gerektirir. 100 Mbps hat, çoğu bot için yeterli bant genişliği sağlar; esas fark packet loss/latency değerleridir.

İşletim sistemi ve çalışma modeli: Ubuntu mu, Debian mı?

VDS için amaç “kurulum kolaylığı” değil “beklenebilirlik”tir. Şunlar Discord botu için net avantaj sağlar:

Ubuntu LTS: Güncel paket ekosistemi ve yaygın dokümantasyon
Debian 12/Bookworm: Stabilite ve uzun servis döngüsü
AlmaLinux/Rocky: Kurumsal uyumluluk isteyenler için

Minimum paketle birlikte önerilen yazılımlar

Botu çalıştırmadan önce kontrol etmeniz gerekenler: - NTP (time sync): Zamanlayıcılar (cron), log sıralaması ve token/exp kontrolü için - Node.js sürüm uyumu: Botunuz hangi sürümü istiyorsa onu kurun - Process manager: PM2 veya systemd ile otomatik yeniden başlatma - Log yönetimi: Dosyaya sınırsız yazma yerine logrotate

Ağ ve bağlantı ayarları: Gateway kopmasını azaltın

Discord Gateway’e düzenli bağlanmak için VDS tarafında “minimum” düzeyde şu kontroller önemlidir:

DNS çözüm gecikmesi: Bot kodunuz DNS lookup yapıyorsa gecikme event gecikmesi üretir.
Firewall: SSH açık, uygulama portları sadece ihtiyaç kadar.
Outband erişim: Konsol/serial erişim varsa bot çökünce loglara erişim hızlanır.

Net kontrol listesi (kurulumdan sonra 10 dakika)

Sunucuda date çıktısı doğru zamanla uyumlu mu?
Bot process’i restart sonrası ayağa kalkıyor mu?
Loglar büyüyünce diski dolduruyor mu? (logrotate var mı?)
Dış API çağrılarında timeout ve retry ayarları var mı?

Bu maddeler doğru değilse “donanım artırmak” tek başına çözüm olmaz.

Storage ve veri: Minimum VDS’de hangi yaklaşım maliyeti düşürür?

Discord botlarının çoğunda “veri” ikiye ayrılır: 1) Kalıcı veri: Kullanıcı tercihleri, ekonomi bakiyesi, kayıtlar 2) Geçici veri: Cache, kısa süreli durum, oran limiti bilgisi

Minimum için net öneri

Geçici cache: Uygulama içinde TTL (Time To Live) ile tutun.
Kalıcı veri: Küçük ölçekte disk/SSD üzerinde çalışıyorsanız bile, DB işlemlerinin yavaşlamasını izleyin.

Minimum VDS’de sık yapılan hata şudur: Her event’te DB yazmak. - Her message için kayıt tutmak yerine, gerçekten gereken alanı yazın. - Okuma/yazma oranını ölçün; yazmayı batch veya gecikmeli kuyruğa alın.

Güvenlik: Minimum VDS’in “asıl” maliyeti savunmadır

VDS boyutu büyütmekten önce, botunuzun saldırı yüzeyini azaltın.

Net yapılacaklar

SSH key ile erişim: Şifre girişini devre dışı bırakın.
Fail2ban: Brute-force denemelerinde otomatik engelleme
Uygulama portunu kapalı tutun: Bot gerekiyorsa inbound açmayın; yönetim için SSH yeterlidir.
Yedekleme (backup): Bot kodu + konfig dosyaları + veri tabanı export/backup

Yedekleme planı minimumda bile olmalıdır. “Önemli veri yok” varsayımı çoğu botta 2 ay sonra kırılır.

İzleme ve otomatik toparlama: Minimum VDS’te farkı bu yaratır

Minimum VDS seçmek, “hiç sorun yaşamazsınız” anlamına gelmez. Önemli olan, sorun çıktığında servis saatlerini kaybetmemektir.

Uygulanabilir minimum izleme

Şunları kurarsanız botun performans problemi büyümeden görünür olur: - CPU/RAM kullanımı: Sürekli %80 üstü mü? O gün boyut artırma ihtimali artar. - Process restart sayısı: Gün içinde çok restart oluyorsa hata var demektir. - Gateway bağlı kalma durumu: Disconnect/reconnect sayısını loglayın. - Disk doluluk: loglar ve temporary dosyalar için alarm.

Otomatik restart için net tercih

PM2 veya systemd kullanın.
Crash sonrası “hemen yeniden dene” yerine, kısa backoff (geri çekilme) ekleyin.

Net karar rehberi: Kaç vCPU/RAM seçmelisiniz?

Aşağıdaki akış, bot türünüze göre net karar verir.

1) Bot sadece komutlara yanıt veriyor, event yoğunluğu düşükse: B seçin (2 vCPU / 2 GB). A (1 GB) kısa vadede yeterli olur ama büyümede sıkıntı çıkarır. 2) Birden fazla dış API çağrısı (HTTP) ve yoğun loglama varsa: C seçin (2-4 vCPU / 4 GB). 3) Sharding planlıyorsanız: D’ye yaklaşın ve shard başına kaynak ayırın. Tek büyük VPS yerine, shard’ları servis mantığıyla ölçeklemek daha yönetilebilir olur.

En kritik eşik: Disk ve RAM büyümesi

Şu iki belirti, minimum paketin yetersizliğini net işaret eder: - Bot RAM kullanımı uzun süre istikrarlı değil, sürekli artıyor (memory leak belirtisi) - Loglar/DB dosyaları disk doluluk sınırına yaklaşıyor

Bu durumda çözüm “daha büyük VDS” değil, önce log/DB/queue stratejisini düzeltmek, sonra boyutu revize etmektir.

Maliyet optimizasyonu: Minimumu doğru kurmak nasıl tasarruf sağlar?

Minimum VDS seçmenin maliyeti azaltması için şu teknik adımlar gerekir:

Log seviyesini prod’da düşürün (debug yerine info)
Retry politikası ekleyin: Dış API timeout + sınırlı deneme
Cache TTL kullanın: Gereksiz DB sorgularını azaltın
Event handler’ları asenkron (async) yapın, bloklayan işlemleri ayrı iş akışına taşıyın

Bu adımlar CPU/RAM ihtiyacını düşürür; sonuç olarak daha küçük VDS ile stabilite sağlanır.

Sonuç: Bugün hangi “minimum VDS”i temel alın?

25.09.2026 koşullarında Discord botu için en pratik minimum başlangıç, tek instance için 2 vCPU / 2 GB RAM / 40 GB SSD paketidir. Düşük trafik test botlarında 1 GB RAM ile başlanabilir; ancak ilk büyüme hedefiniz varsa başlangıçtan B planına geçmek restart ve gecikme riskini azaltır. Çoklu shard ve yoğun event için 4 vCPU / 8 GB RAM yaklaşımı net bir güvenlik sınırı oluşturur.

Aksiyon önerisi: VDS’i kurduktan sonraki ilk 72 saatte CPU/RAM, process restart sayısı, disk doluluk ve gateway disconnect loglarını izleyin; bu ölçümlere göre bir sonraki adımda RAM veya CPU artırın ya da DB/yazma stratejinizi düzeltin.