Node.js Uygulaması için VDS Yapılandırması: Net Kontrol Listesi

Node.js uygulaması bir VDS sunucuda çalıştırıldığında performans; doğru işletim sistemi, doğru süreç yönetimi ve doğru ters proxy (reverse proxy) kurulumu ile doğrudan belirlenir. Bu yazıda, tek tek “ne kuracağım?” sorusuna cevap vererek Node.js uygulamanız için çalışır bir VDS mimarisi kuracağız. Amaç; uygulama ayağa kalktığında gecikme (latency) ve hata oranını artıran yaygın yanlışları önlemek ve izleme/yedekleme ile yönetimi netleştirmek.

1) Hedefi netleştirin: Uygulama tipi ve trafik modeli

Ön kurulum kararı; uygulamanın türüne göre değişir. Bu yüzden önce aşağıdaki 3 soruyu net yanıtlayın:

• Web mi API mi? (HTTP/HTTPS) Yoksa gerçek zamanlı mı? (WebSocket)
• Trafik dalgalı mı? Gün içi tepe değerler var mı, yoksa sabit mi?
• Durum (state) var mı? Uygulama oturum bilgilerini bellekte mi tutuyor, yoksa Redis gibi harici bir katmanda mı?

Bu netleşmeden “kaç GB RAM almalıyım?” sorusu doğru yanıtlanamaz. Node.js’te tek süreç (single process) ile başlamak çoğu zaman yeterlidir; ancak concurrency arttıkça süreç sayısını (cluster) ve kaynak planını (CPU/RAM) ayarlamak gerekir.

Minimal referans mimari

• Nginx: TLS (HTTPS) sonlandırma + reverse proxy
• PM2: Node.js süreç yönetimi (process manager)
• UFW/iptables: temel güvenlik duvarı
• Log yönetimi: Nginx access/error + PM2 log + sistem logları
• Yedekleme (backup): uygulama dosyaları + config + veri tabanı (veri tabanı ayrıysa)

2) VDS kaynak seçimi: CPU/RAM planı (net eşiklerle)

Aşağıdaki tablo, küçük ve orta ölçekli Node.js kurulumlarında pratik bir başlangıç verir. Rakamlar kesin “tek doğru” değildir; ancak NetKıyas’ta kullanıcıların en çok düştüğü sorun, kaynakların ya fazla pahalı alınması ya da gereğinden düşük seçilmesidir. Bu nedenle her satırda “neden” kısmını da belirttim.

Disk türü ve swap kararı

• NVMe/SSD kullanın. Node.js + Nginx + log yazımı tek disk üzerinde hız farkını hemen hissettirir.
• Swap’i tamamen kapatmak her zaman doğru değildir; ancak “swap’e sürekli düşen” sistem performans kaybeder. PM2 ve Node ayarlarıyla bellek kullanımını kontrol edin.

3) Güvenlik temelini kurun: portlar, kullanıcılar, anahtarlar

Node.js’i internete açtığınız anda en büyük riskler; gereksiz portların açık kalması ve zayıf erişim yönetimidir. Bu bölümü tamamlamadan canlıya geçmeyin.

3.1 SSH erişimi

• Yeni bir kullanıcı oluşturun (root ile giriş kapatılmalı).
• Şifre yerine SSH anahtar (key) kullanın.
• Root login’i devre dışı bırakın.

3.2 Güvenlik duvarı (UFW) — net kural seti

Varsayım: Nginx 80/443 üzerinden hizmet veriyor. - Açık portlar: 22 (SSH), 80, 443 - Kapalı: uygulama portu (örn. 3000/4000) — sadece localhost’tan Nginx’e erişsin

UFW örneği (sunucuda):

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

3.3 Fail2ban ile brute-force azaltma

Fail2ban’ı SSH için etkinleştirin. Bu, 2026’da dahi sıklıkla gerekli olan pratik bir savunmadır.

4) Reverse proxy ve TLS: Nginx’i doğru konumlandırın

Node.js’in 3000 gibi bir portta çalışması; doğrudan internete açmak yerine Nginx üzerinden yönetildiğinde daha güvenli ve daha kontrol edilebilir olur.

4.1 Nginx neden kritik?

• HTTPS (TLS) sonlandırma Nginx’te yapılır.
• İstek limitleri, buffer ayarları ve timeouts daha net yönetilir.
• WebSocket trafiği doğru proxy ayarlarıyla stabil akar.

4.2 Örnek site konfigurasyonu (HTTP → Node)

Aşağıdaki örnekte Node.js uygulaması 127.0.0.1:3000 üzerinde çalışıyor.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }
}

TLS eklemek için aynı siteyi 443’te yayınlayın ve sertifika dosyalarını bağlayın. TLS terminasyonu sonrası redirect (80→443) eklemek performans ve SEO açısından standarttır.

5) Süreç yönetimi: PM2 ile cluster ve log standardı

Node.js uygulamalarında en sık yaşanan sorunlardan biri; “sunucu yeniden başlatıldı, uygulama kalkmadı” veya “hata logları kayboldu” durumlarıdır. PM2 bunu net çözer.

5.1 PM2 ile temel kurulum

• PM2’yi global kurun.
• Uygulamayı ecosystem ile tanımlayın.
• Sistem yeniden başlatıldığında otomatik ayağa kalkmayı (startup) etkinleştirin.

Örnek ecosystem.config.js:

module.exports = {
  apps: [
    {
      name: "node-app",
      script: "server.js",
      instances: 2,
      exec_mode: "cluster",
      env: {
        NODE_ENV: "production",
        PORT: 3000
      },
      max_memory_restart: "500M"
    }
  ]
};

Buradaki instances değeri için net yaklaşım: - 2 vCPU ile genellikle 2–4 process bandı iyi başlar. - 4 vCPU ve üzeri için 4–8 arası denerken RAM’i izleyin.

5.2 Logları standartlaştırın

• PM2 logları diske yazılmalı.
• Nginx access/error logları ayrı tutulmalı.
• Log rotasyonu (rotation) yapılmalı.

PM2 için şu komutlar pratikte iş görür: - pm2 logs - pm2 flush (sık log testi için) - pm2 save (process listesini kalıcı yapma)

6) Performans ayarları: Node, Nginx ve uygulama tarafı

Performans problemleri çoğu zaman “sunucu yetersiz” sanılarak yanlış hedefe yönelir. Aşağıda net bir öncelik sırası var.

6.1 İlk teşhis: Hangi katman yavaş?

• İstek zamanları Nginx access loglarında görülebilir.
• Node uygulamasında response süreleri ve hata kodları izlenir.
• CPU/RAM grafikleri sistem seviyesinde kontrol edilir.

Bu üç katmanın hangisinde gecikme olduğuna göre ayarlarsınız.

6.2 Nginx timeouts ve buffer

• Uzun süren isteklerde proxy_read_timeout ve proxy_send_timeout değerlerini uygulama ihtiyacına göre uzatın.
• Çok büyük payload’lar varsa upload limitlerini de kontrol edin.

6.3 Node ayarları

• NODE_ENV=production kullanın.
• Gereksiz debug modunu kapatın.
• Çok yüksek bellek tüketiminde PM2 max_memory_restart ile kontrol sağlayın.

6.4 Uygulama tarafı en net kazanç alanları

• Senkron CPU ağır işlemleri istek thread’ini kilitler. Ağır işlemleri worker’a taşıyın.
• Veritabanı sorgularında indeks kullanın. Çok sayıda round-trip performansı bozar.
• Cache katmanı (ör. Redis) tekrarlı okumalarda net fark yaratır.

7) İzleme (monitoring) ve hata tespiti: canlıda kör kalmayın

Node.js VDS’te izleme olmadan doğru kapasite planlamak imkansızdır. En azından şu metrikleri toplayın: - CPU (sürekli %80 üstü bandı) - RAM (sürekli swap kullanımı) - Disk (kullanım yüzdesi) - Network (outbound/inbound) - Uygulama metrikleri (request rate, hata oranı)

Net kontrol listesi

• Nginx 4xx/5xx oranı (özellikle 502/504)
• PM2 restart sayısı (sürekli restart varsa kök neden bulunmalı)
• Uygulama exception logları

8) Yedekleme (backup) planı: “dosya mı veri mi?”

Node.js sistemlerinde yedekleme ikiye ayrılır: - Uygulama dosyaları ve konfigürasyon (kod, .env, ecosystem dosyaları) - Veri tabanı (MySQL/PostgreSQL/MongoDB) — ayrı yedeklenir

8.1 En net yedekleme stratejisi

• Uygulama dosyalarını sürüm bazlı yedekleyin (ör. release tag ile).
• .env gibi gizli dosyaları saklarken şifreli/erişim kısıtlı depolama kullanın.
• Veri tabanı için günlük snapshot + belirli saatlerde full backup uygulayın.

9) Canlıya alma (go-live) adımı: testten sonra açın

Sunucuyu hazır hale getirmek tek başına yetmez; canlıya geçmeden önce doğrulama gerekir.

9.1 Uygulama portunu test edin

• 127.0.0.1:3000 (veya kullandığınız port) Nginx’ten yanıt veriyor mu?
• Nginx’ten gelen request’te doğru header’lar geçiyor mu? (X-Forwarded-For vb.)

9.2 Basit yük testi yapın

• Gerçek trafikten daha düşük bir load ile 10–15 dakika test edin.
• CPU/RAM trendini izleyin.
• Hata oranı yükseliyor mu kontrol edin.

Sonuç: VDS kurulumunu “sıralı” yapın

Node.js uygulaması için VDS yapılandırmasını tek hamlede kurmaya çalışmayın. Önce güvenliği (firewall + doğru port açma), sonra reverse proxy ve TLS’yi (Nginx), ardından süreç yönetimini (PM2) ve en son izleme/yedeklemeyi tamamlayın. Şimdi yapmanız gereken net aksiyon: Uygulamanın Nginx üzerinden çalıştığını doğrulayın, PM2’nin yeniden başlatma sonrası ayağa kalktığını test edin ve en az CPU/RAM + Nginx hata oranı izleme kurun. Bu üç maddeyi tamamladığınızda, sonraki kapasite artışları için kararınız ölçülebilir verilere dayanır.