Node.js VDS Yapılandırması: Performans, güvenlik ve yedekleme

Node.js tabanlı bir uygulamanın başarısı; sadece kodun doğruluğuna değil, VDS üzerindeki çalışma modeline de bağlıdır. Yanlış süreç yönetimi, yetersiz ters proxy ayarları, kontrolsüz log birikimi ve zayıf TLS/erişim kuralları hem performansı düşürür hem de kesinti maliyetini artırır. Bu rehberde Node.js uygulaması için VDS üzerinde uygulanabilir, ölçülebilir ve tekrar edilebilir bir yapı kuracaksınız: ters proxy (Nginx), süreç yöneticisi (PM2), güvenlik (firewall, least-privilege), izleme ve yedekleme (backup) planı.

Aşağıdaki kurulum yaklaşımı, tek sunucuda production benzeri çalışmayı hedefler. Kubernetes gibi orkestrasyonlara geçmeden önce sağlam bir temel kurmanız için tasarlandı.

1) Doğru VDS temelini kurun: CPU, RAM, disk ve ağ

Node.js uygulamalarında darboğaz çoğu zaman CPU veya RAM’den çıkar; ikinci sırada disk I/O ve ağ gecikmesi gelir. Bu nedenle ilk adım, VDS spec’lerini “tahmin” değil “beklenen yük” üzerinden belirlemektir.

Önerilen VDS senaryoları (pratik eşleştirme)

Aşağıdaki değerler, tipik web API + bazı arka plan işler (queue yoksa cron/worker) senaryosu içindir. Gerçek ihtiyaç; eşzamanlı kullanıcı, istek boyutu, veritabanı tipi ve cache stratejisine göre değişir.

• Hafif (20-50 eşzamanlı istek): 2 vCPU, 4 GB RAM, NVMe 40-80 GB
• Orta (50-150 eşzamanlı istek): 4 vCPU, 8 GB RAM, NVMe 80-160 GB
• Yüksek (150-400 eşzamanlı istek): 8 vCPU, 16 GB RAM, NVMe 160-320 GB

Ağ tarafı için hedefiniz şudur: aynı anda birçok küçük isteğin geldiği senaryolarda bağlantı kurulum ve TTFB stabil olmalı. Bu yüzden “paylaşımlı” disk ve aşırı yavaş IOPS’tan kaçınmak kritik.

Hız için iki kontrol metrik

• TTFB (Time to First Byte): Nginx + Node arasındaki proxy gecikmesi ve uygulamanın ilk yanıt süresini yansıtır.
• Event loop gecikmesi: Node.js tarafında CPU kilitlenmesi veya uzun senkron bloklar varsa artar.

Bu metrikleri kurulum sonrası “hemen” ölçün. Çünkü yanlış kararları düzeltmek en pahalı kısımdır.

2) OS hazırlığı: kullanıcı, güncelleme ve zaman

Güvenlik ve bakım için işletim sistemi katmanında birkaç net adım vardır.

Sık yapılan hata: root ile servis çalıştırmak

Kural olarak Node uygulamasını ve süreç yöneticisini ayrı bir kullanıcı ile çalıştırın.

• Uygulama için kullanıcı: nodeapp
• Uygulama dizini: /var/www/nodeapp
• Süreç yöneticisi PM2: nodeapp kullanıcısı altında

Güncellemeler ve zaman senkronu

• Sistemi güncelleyin: apt update && apt upgrade -y (Debian/Ubuntu varsayımıyla)
• Saat senkronu için NTP: timedatectl ile kontrol, uygun servisle düzeltme

Saat hataları özellikle log korelasyonu ve SSL sertifika yenilemede sorun çıkarır.

3) Nginx’i ters proxy olarak kurun (HTTP/HTTPS ve kaynak optimizasyonu)

Node uygulamasını doğrudan internete açmak yerine Nginx’i reverse proxy (ters proxy) olarak konumlandırın. Bu sayede TLS bitirme, bağlantı yönetimi, sıkıştırma ve header politikası merkezi olur.

Temel akış

1. Kullanıcı https://domain isteği gönderir
2. Nginx TLS’i sonlandırır
3. Nginx Node’a http://127.0.0.1:PORT üzerinden proxy yapar
4. Node sadece uygulama mantığını çalıştırır

Nginx tarafında net ayarlar

• TLS: Güvenli şifre paketi (modern tarayıcılarla uyum)
• Gzip/Brotli: Metin ağırlıklı yanıtlar için etkin
• Proxy timeouts: Uzun süren istekler için net sınırlar
• Client body size: Dosya upload varsa boyuta göre sınır

Aşağıdaki parametreler çok kritik: - proxy_read_timeout: Uygulamanın yanıt süresine göre ayarlayın - proxy_connect_timeout: Node’un ayağa kalkma sürelerine göre - client_max_body_size: Upload limit

Upstream ve keep-alive

Node uygulamasına sürekli yeni bağlantı kurmak yerine keep-alive kullanmak TTFB ve CPU tüketimini iyileştirir. Nginx’in proxy ayarlarında keep-alive davranışını doğrulayın.

4) Node.js süreç yönetimi: PM2 ile sağlam çalıştırma

Node tek proses gibi görünse de üretimde süreç yönetimi şarttır. PM2; yeniden başlatma, log yönlendirme, instance çoğaltma (cluster mode) gibi işlevler sunar.

PM2 ile başlatma modelinin net seçimi

• Tek uygulama için: tek proses + istek başına hızlı yanıt
• CPU yoğun işlerde: cluster ile worker sayısını CPU çekirdeğine göre artırın

Uygulama start komutu (örnek)

package.json yerine doğrudan giriş dosyanızı hedefleyin.

• PM2 ile başlatma: pm2 start ecosystem.config.js --env production
• Olası dosya: ecosystem.config.js

Not: Bu örnek yapıyı kendi projene uyarlayın. Port, çalışma dizini ve environment değişkenleri uygulamanıza göre olmalıdır.

Otomatik restart ve log rotasyonu

PM2, process çökmesini takip eder. Ancak loglar sonsuza kadar büyürse diski doldurur.

• PM2 loglarını disk sınırlarıyla yönetin
• Nginx access/error loglarını da günlük döndürün

Log rotasyonu yoksa “bir noktada” disk patlar ve servis kesilir. Bu kesinti genellikle planlı değildir.

Health check endpoint’i

Nginx tarafında veya izleme tarafında kullanmak için uygulamada bir GET /health oluşturun.

Sağlık kontrolü: - Veritabanı bağı hızlıca test edilebilir - Ağır kontroller (tüm sorgular) yapmayın

5) Güvenlik: erişim kontrolü, TLS, header ve dosya izinleri

Node.js VDS’de güvenlik “tek adımda bitmez”. Katman katman düşünmeniz gerekir.

Firewall (UFW veya provider güvenlik grubu)

Aşağıdaki yaklaşımı izleyin: - SSH: sadece kendi IP’nizden izin verin - Web: 80/443 açık - Uygulama portu (ör. 3000): internete kapalı, sadece Nginx’in geldiği lokal arayüzden açık

Bu, en sık karşılaşılan güvenlik hatasını engeller: Node portunu internete açık bırakmak.

TLS sertifikası ve zorunlu HTTPS

TLS kurulumundan sonra: - Tüm trafiği HTTPS’e yönlendirin (301) - Sertifika yenilemeyi otomatikleştirin

Güvenlik header’ları

Nginx üzerinden ekleyin: - Content-Security-Policy (uygulamanıza göre net kurallar) - X-Frame-Options veya benzeri frame koruması - Referrer-Policy - X-Content-Type-Options

Header’lar körlemesine kopyalanmamalıdır. Uygulama kaynaklarınıza göre ayarlayın.

Dosya izinleri: servis kullanıcı-odaklı model

Uygulama klasöründe: - Yazma izinleri yalnızca nodeapp kullanıcısında olmalı - Sistem dosyalarında “genel yazma” yetkisi verilmemeli

Bu, supply chain saldırıları veya yanlış depolama durumlarında hasarı azaltır.

6) Performans: cache, keep-alive, sık loglama ve TTFB kontrolü

Node.js tarafında performans denince iki konu öne çıkar: doğru cache kullanımı ve gereksiz maliyetlerin azaltılması.

Cache stratejisi (net yol haritası)

1. Statik dosyalar: Nginx cache (ETag/Last-Modified)
2. API cache: Uygun olan endpoint’lerde kısa süreli cache
3. Tarayıcı önbelleği: doğru Cache-Control ile

Tarayıcı önbelleği yanlış ayarlanırsa ya güncel içerik gecikir ya da gereksiz trafik oluşur.

TTFB’yi etkileyen tipik hatalar

• Uygulamanın ilk istek sırasında “ağır yük” yapması (ör. büyük konfig dosyalarının anlık okunması)
• Yanlış sıralı middleware (ör. her istekte senkron dosya işlemi)
• Çok fazla senkron CPU işi (event loop blok)

Nginx ile bağlantı optimizasyonu

Aşağıdaki kontrol listesiyle ilerleyin: - Keep-alive aktif mi? - Timeoutlar istek tipine uygun mu? - Proxy başına aşırı buffer kullanımı var mı?

7) İzleme ve log planı: “görmeden” yönetim olmaz

Üretimde kritik soru şudur: “Sorun olunca hangi veriyle nerede patladığını bulacağım?”

Minimum izleme seti

• Uptime / health endpoint: ör. /health
• PM2 process durumu: restart sayısı
• Nginx access/error log: 4xx/5xx oranı
• Disk kullanımı: özellikle loglar için
• CPU/RAM: event loop performansı ile ilişkili

Logları tek bir yerden okumak

Küçük sistemlerde ilk etapta provider logları yeterli olabilir. Ancak Node uygulamanız büyüdükçe logların ayrıştırılması gerekir: - Nginx access log: istek metrikleri - Node logları: uygulama hataları - PM2 logları: process yaşam döngüsü

8) Yedekleme (backup) ve geri dönüş testleri

Yedekleme “dosyayı kopyaladım” demek değildir. Geri dönüş (restore) test edilmeden yedek güvenli sayılmaz.

Node.js VDS’de hangi katmanlar yedeklenir?

Aşağıdaki listeyi bir kontrol listesi gibi düşünün: - Uygulama kodu: Git repo veya deployment artefaktları - Environment dosyaları: .env değerleri (gizlilik) - PM2 süreç konfigürasyonu: ecosystem dosyası - Nginx konfigleri: site/vhost ayarları - Sertifika dosyaları: TLS anahtarları (kullanım gerektirebilir) - Veritabanı: uygulama verisi (genelde ayrı servis/volume)

Yedekleme sıklığı (net öneri)

• Kod: her release
• Konfig: her değişiklikte otomatik
• Veritabanı: veri değişim hızına göre (ör. saatlik) + günlük tam

Restore testi

En az ayda bir: 1. Yedeği ayrı bir dizine restore edin 2. Sistem servislerini yeniden ayağa kaldırın 3. Uygulamanın /health endpoint’ini doğrulayın

Restore testleri olmadan yedek stratejisi “varsayım” olarak kalır.

9) Uygulama portu, süreç izolasyonu ve doğru ağ mimarisi

VDS üzerinde sık yapılan mimari hatalar vardır. Net doğrular:

• Node portu internete açık olmaz: Nginx sadece lokal arayüzden Node’a bağlanır.
• Uygulama ile sistem servisleri (örn. Redis/DB) aynı ağ politikasına göre ayrılır.
• Gereksiz açık port bırakılmaz.

10) Uygulama hazırlığını “yayına alma checklist’i”ne çevirin

Aşağıdaki tablo, yayın öncesi son kontrolü hızlılaştırır.

Sonuç: Node.js VDS’i “ölçülebilir” şekilde kurun

Node.js VDS yapılandırmasında en iyi sonuç; rastgele ayarlarla değil, katman katman kontrol listesiyle gelir. İlk yayında hedefiniz şu olsun: Nginx ile doğru TLS ve proxy, PM2 ile sağlam süreç yönetimi, firewall ile port izolasyonu, log rotasyonu ile disk güvenliği ve yedek (backup) + restore testi ile gerçek geri dönüş.

Bir sonraki adım olarak mevcut altyapınızı ele alın: Node portunuz internete açık mı, log rotasyonunuz var mı, /health endpoint’i çalışıyor mu ve geri dönüş testi yaptınız mı? Bu dört sorunun cevabı, gerçek iyileştirmeyi en hızlı başlatır.