Node.js Uygulaması İçin VDS Yapılandırması: Pratik Rehber

Node.js uygulamalarında performans ve kararlılık, sadece kod kalitesiyle değil; VDS (Virtual Dedicated Server) üzerinde doğru mimariyle birlikte gelir. Yanlış ters proxy ayarı, eksik TLS yapılandırması, logların kontrolsüz büyümesi veya otomatik yeniden başlatmanın yapılmaması maliyet ve kesinti üretir. Bu rehberde Node.js için; gerekli bileşenler, güvenli bir başlangıç mimarisi ve karşılaştırmalı seçimler ile net bir VDS yapılandırması kuracaksınız.

Hedef mimari: Node.js + Nginx + PM2 (ve neden)

VDS üzerinde Node.js uygulaması çalıştırırken en yaygın ve yönetilebilir yaklaşım şu katmanlara ayrılır:

• Nginx: İstemci ile uygulama arasında reverse proxy (proxy_forward) görevi görür. TLS (HTTPS) sonlandırma burada yapılır.
• PM2: Node süreçlerini başlatır, yeniden başlatır, logları yönetir (process manager).
• OS ve güvenlik katmanı: Dosya izinleri, kullanıcı izolasyonu, firewall (ufw) ve temel sistem sertleştirme.

Bu yaklaşımın pratik avantajı nettir: TLS ve istek yönlendirme tek noktada (Nginx) kontrol edilir; uygulama tarafında ise PM2 sayesinde “çöktü, ayağa kalkmadı” senaryosu azalır.

Hangi Node.js sürümünü hedefleyin?

• Uygulamanız spesifik bir sürüm gerektiriyorsa (örn. bazı paketler) onu değiştirin.
• Gereksiz riskten kaçınmak için “LTS olmayan” sürümlerden kaçının.

VDS kaynak planı (minimumdan başlayın)

Node.js için kaynak planı, uygulamanın tipine göre değişir. Aşağıdaki tablo “başlangıç / ölçeklenme” perspektifi sunar.

Disk türü için somut özet: NVMe SSD, özellikle log yazma ve küçük dosya okuma yoğun işlerde daha stabil gecikme sağlar. Her durumda “NVMe = katlanır performans” değildir; ama Node uygulamanızın etrafında çalışan bileşenlerin (loglar, cache dosyaları, paketler) toplam I/O yükü görünür hale geldiğinde fark hissedilir.

İşletim sistemi seçimi: Ubuntu/Debian tabanı ile başlamak

Node ekosisteminde en sorunsuz başlangıç, Ubuntu LTS veya Debian tabanlı dağıtımlarla olur. Neden? - Paket yöneticisi güncellemeleri düzenlidir. - Nginx/Certbot kurulumu ve güvenlik güncellemeleri daha standart ilerler.

Net seçim kılavuzu (komponent uyumu)

• Kontrol panel düşünmüyorsanız (bare yaklaşım): Debian/Ubuntu genelde daha “istikrarlı ve tahmin edilebilir” ilerler.
• Kurumsal ortam varsa (mevzuat/ops): AlmaLinux/Rocky de tercih edilir; ancak burada rehber Ubuntu/Debian akışını baz alır.

Node.js kurulum: Uygulamayı “tek dizin” değil “yayın akışıyla” taşıyın

Uygulama dizin yapısını baştan doğru kurgulamak, ileride güncelleme ve geri dönüş (rollback) için kritiktir.

Önerilen akış: 1. Uygulama kodunu /home/app/myapp altına alın. 2. Ayrı bir kullanıcı kullanın (ör: app). 3. Ortam değişkenlerini ayrı tutun (env dosyası / sistem env).

Neden ayrı kullanıcı?

Sistem dosyalarını uygulamaya karıştırmadan; dosya izinleri ve güvenlik izolasyonu sağlarsınız. Bu, RCE (remote code execution) sonrası hasarı azaltır.

PM2 yapılandırması: Yeniden başlatma, log ve instance

PM2’nin amacı “hata alınca servis durmasın” ve logları kontrol edilebilir kalsın.

Çalıştırma stratejisi (tek instance vs cluster)

• Tek CPU: 1 instance yeterli olabilir.
• Çok çekirdek: PM2 cluster ile işlem başına CPU kullanımı dengelenir.

Aşağıdaki kontrol listesiyle karar verin:

• Uygulama CPU-bound mı? (ağ değil hesap ağırlıklı)
• Evetse instance sayısını artırın.
• Uygulama I/O-bound mı? (DB sorgu, HTTP çağrısı)
• Evetse instance sayısı DB limitleriyle uyumlu olmalı.
• WebSocket kullanıyor musunuz?
• Evetse bağlantı yoğunluğuna göre RAM/file descriptor ayarlarını kontrol edin.

PM2 log kontrolü (log şişmesi kesinti üretir)

Loglar kontrolsüz büyürse disk doluluk problemi doğurur. - PM2 log rotasyon ayarlarını etkinleştirin. - Nginx loglarını da rotasyona bağlayın.

Nginx reverse proxy: Cache değil, doğru yönlendirme

Nginx burada iki işi yapar: 1. HTTPS/TLS sonlandırma. 2. Node uygulamasına istek iletme.

En kritik noktalar

• proxy_pass doğru portu hedeflemeli.
• WebSocket için gerekli header’lar eklenmeli.
• Uygulamanızın limitlerini (body size, timeouts) net ayarlayın.

Nginx ayarı kontrol listesi

Aşağıdaki maddeler, “çalışıyor ama ara ara kopuyor” sorunlarını sık engeller: - Timeouts: upstream zaman aşımı çok düşükse istekler kesilir. - WebSocket: Upgrade/Connection başlıkları olmadan anlık kopmalar olur. - Gecikme (latency): gzip/buffer ayarlarını aşırı agresif yapmayın; önce baseline ölçün.

TLS (HTTPS) kurulumu: Sertifikayı otomatik yenileyin

VDS üzerinde HTTPS için hedef “manuel uğraşsız yenileme”dir.

ACME/Certbot ile otomatik yenileme

• Alan adınızı (domain) VDS IP’sine yönlendirdikten sonra sertifikayı otomatik alın.
• Certbot yenileme loglarını takip edin.

Somut doğrulama: - Sertifika alındıktan sonra tarayıcıda zincir doğrulaması sorunsuz olmalı. - Yenileme simülasyon testi yapılmalı (yenileme komutu denenmeli).

Güvenlik: Firewall, SSH sertleştirme, süreç izolasyonu

Node tarafında “yazılım güvenliği” kadar altyapı güvenliği de kesinti azaltır.

Uygulanabilir güvenlik adımları

• SSH için: varsayılan porta gerek yok; fakat en önemlisi anahtar tabanlı giriş (password kapat), root direkt erişimini kısıtlama.
• Firewall (ufw): 22/80/443 dışındaki portları kapalı tutun.
• Dosya izinleri: uygulama dosyaları yalnızca uygulama kullanıcısına yazılabilir olmalı.
• Nginx: gereksiz endpoint’leri açıkta bırakmayın.

Performans ayarları: Ölçmeden optimize etmeyin

Node uygulamasında performans problemleri çoğu zaman “tek bir ayar” değil; çoklu bileşen etkileşimidir: Nginx timeouts, keep-alive, PM2 instance sayısı, DB bağlantısı sayısı, dosya descriptor limitleri.

Gerçek ölçüm yapın (en azından)

• Sunucu yanıt süresi (TTFB / total response time)
• 4xx/5xx oranı
• CPU/RAM trendi
• Disk doluluğu
• Aktif bağlantı ve WebSocket sayısı

Somut hedef aralığılar

Tekil uygulamada hedef değişir, fakat pratik kontrol ölçütleri: - 5xx oranı gün içinde kalıcı şekilde artmamalı. - CPU uzun süre %80+ seviyesinde kilitlenmemeli. - Disk doluluğu %80’e gelmeden log temizleme/rotasyon devrede olmalı.

Yedekleme (backup): Uygulama kodu + yapılandırma + veri ayrımı

“Yedek alındı” demek tek başına yetmez; geri dönüş (restore) senaryosu net olmalıdır.

Node uygulaması için yedek kapsamı

• Uygulama kodu (repo + deployment dosyaları)
• PM2 process ayarları (ekli dosyalar/ekosistem)
• Nginx konfigürasyonları
• Ortam değişkenleri (env değerleri; güvenli saklama)

Veri katmanı (DB) yedeği

Uygulamanın yedek kurgusu DB olmadan eksik kalır. DB’niz: - VDS üzerinde PostgreSQL çalışıyorsa: düzenli dump veya snapshot. - Ayrı managed DB ise: managed sağlayıcının snapshot/yedek politikası.

Geri dönüş testi

En önemli aksiyon: yedekten restore almayı belirli aralıklarla denemek. Bir kere “yedek alındı” demek yerine, restore ile doğrulayın.

Yük ve ölçek: Neden “instance artırmak” tek çözüm değil?

Node uygulamasını ölçeklerken asıl darboğazı doğru tespit etmek gerekir.

Hızlı teşhis akışı

1. CPU mu artıyor, yoksa RAM mi?
2. 5xx artışı var mı?
3. DB sorgu süreleri uzuyor mu?
4. Nginx upstream timeouts tetikleniyor mu?

Ölçek için 3 net yol

• PM2 instance artırma: CPU çekirdekleriyle uyumlu.
• Reverse proxy ayarlarını iyileştirme: keep-alive, timeouts, buffer.
• Veri katmanını iyileştirme: DB indeksleri, bağlantı havuzu (connection pool).

“Instance sayısını sınırsız artırma” yaklaşımı DB’yi hızlıca boğar. Bu yüzden DB tarafında bağlantı havuzu ve max bağlantı değerleri uygulama ölçeğiyle uyumlu olmalıdır.

Resmi kontrol listesi: Kurulum bittiğinde doğrulanacak maddeler

Aşağıdaki listeyi “yayına hazır” kontrolü gibi kullanın.

• [ ] Nginx reverse proxy çalışıyor
• [ ] HTTPS (TLS) aktif ve otomatik yenileniyor
• [ ] PM2 uygulamayı yeniden başlatıyor
• [ ] PM2 log rotasyonu aktif (disk şişmiyor)
• [ ] Uygulama env değerleri güvenli
• [ ] SSH password kapalı, anahtar tabanlı giriş aktif
• [ ] Firewall 22/80/443 dışında kapalı
• [ ] Disk doluluk alarmı/izleme var
• [ ] Yedek alınıyor ve restore testi yapıldı

Node.js için yayına alma: Başlangıçtan canlıya geçiş planı

Canlıya geçişte hedef “kesintiyi minimize etmek”tir.

Yayına alma sırası

1. Uygulamayı VDS üzerinde test ortamında çalıştırın.
2. Nginx üzerinden staging domain veya farklı route ile test edin.
3. TLS oturtun.
4. Trafiği kontrollü artırın.
5. İlk 24 saatte hata oranı ve kaynak trendlerini izleyin.

İlk gün izleme (net bakılacak metrikler)

• Nginx 4xx/5xx dağılımı
• PM2 restart sayısı (sürekli artıyorsa kök neden bulunmalı)
• Memory usage (RSS) artışı trendi (sızıntı varsa işlem büyür)
• Disk doluluk (log rotasyon yeterli mi)

Sonuç: Aksiyona dönük kurulum önerisi

Node.js için VDS yapılandırmasında en hızlı doğru sonuç; Nginx reverse proxy + PM2 process yönetimi + otomatik TLS + log rotasyonu + net yedek/restore planı kombinasyonunu birlikte kurmakla gelir. İlk gün hedefiniz tüm bileşenleri çalışır hale getirmek değil; yukarıdaki kontrol listesinde işaretlediğiniz maddelerle “kesinti riskini ölçülebilir şekilde düşürmek” olsun. Kurulumu tamamladığınızda mutlaka 24 saat trend izleyin; ardından instance sayısı, timeouts ve DB bağlantı ayarlarını tespit ettiğiniz darboğaza göre net şekilde optimize edin.