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

Node.js uygulaması bir “kurup çalıştırma” işinden çok, doğru sunucu katmanları (OS, process yönetimi, ters proxy, TLS, cache, loglama) ile kararlı hâle getirme işidir. Yanlış VDS yapılandırması; yavaş yanıt, rastgele servis düşmesi, dolan disk, süresiz oturumlar veya güvenlik açıkları gibi somut sorunlara dönüşür.

Bu rehberde Node.js uygulamanız için VDS üzerinde “uçtan uca” net bir kurulum/optimizasyon planı bulacaksınız: işletim sistemi seçimi, kullanıcı/SSH güvenliği, PM2 ile süreç yönetimi, Nginx ile reverse proxy, TLS/sertifika planı, performans ayarları, log ve yedekleme, ayrıca temel izleme kontrol listesi.

Node.js için VDS mimarisi: Parçalar ve görevleri

Node.js uygulaması VDS üzerinde genellikle şu şekilde konumlanır:

• Uygulama katmanı: Node.js (ör. Express/Fastify)
• Süreç yönetimi: PM2 (process manager)
• Web giriş katmanı: Nginx (reverse proxy)
• Güvenlik katmanı: TLS (HTTPS) + güvenlik duvarı (firewall)
• Operasyon: loglama, otomatik yeniden başlatma, yedek (backup)

Bu ayrımın faydası nettir: Uygulama portunu (ör. 3000) internet yerine yalnızca Nginx’e açarsınız. Nginx ise hem TLS sonlandırır hem de istekleri uygulamaya iletir.

Tek portlu yaklaşım neden yetmez?

Node uygulamasını doğrudan 80/443’e bağlamak yerine Nginx kullanmak daha güvenli ve yönetilebilirdir. Çünkü Nginx: - Sertifika/anahtar yönetimini standartlaştırır - Compression, header yönetimi ve timeout’ları tek yerde kontrol eder - Uygulama tarafında daha az iş yükü oluşturur

Donanım ve kaynak planı: Minimumdan net öneriye

VDS boyutu uygulama yükünüza göre değişir. Aşağıdaki değerler “başlangıç için net aralık” verir. Amaç; CPU veya RAM yetersizliğiyle servis düşmesini önlemek ve disk taşmasını engellemektir.

Basit kaynak tahmini (başlangıç aralığı)

Uygulama bağımlılıklarını hesaba katın

Node.js tek başına hafif görünse bile şu parçalar RAM/CPU ister: - Template engine veya rendering (server-side) - Görsel/zip işlemleri (ayrı worker gerekebilir) - Queue (BullMQ benzeri) ve Redis - Veritabanı ile yoğun sorgu

Bu nedenle “sadece Node” için değil, uygulamanın kullandığı servisleri de VDS planına ekleyin.

İşletim sistemi ve temel kurulum: Ubuntu/Debian ile başlayın

Node ekosisteminde en az sürpriz veren kurulumlardan biri Ubuntu LTS veya Debian sürümleridir.

Net kurulacaklar listesi

• Güncel sistem güncellemesi
• ufw veya benzeri firewall
• Nginx
• Node.js (veya yönetilen paket/kurulum yöntemi)
• PM2
• Loglar için disk takip (zorunlu)

Kullanıcı ve SSH güvenliği (doğrudan aksiyon)

1) Root ile giriş kapatın (ssh üzerinden yalnızca normal kullanıcı) 2) Şifre tabanlı girişi devre dışı bırakın 3) SSH için key (anahtar) kullanın 4) SSH portunu değiştirmek tek başına güvenlik sağlamaz; asıl güvenlik doğru yetkiler ve firewall’dır

Bu ayarlar, “tüm brute-force denemeleri” uygulama katmanına kadar gelmeden durdurur.

PM2 ile Node.js süreç yönetimi: Düşmeyi engelleyen temel

PM2, Node uygulamasını arka planda çalıştırır ve çökerse otomatik toparlama davranışı sunar.

PM2 ile net çalışma modeli

• Uygulamayı bir “process” olarak tanımlayın
• Environment değişkenlerini (ör. NODE_ENV, DATABASE_URL) ayrı yönetin
• Crash durumlarında restart stratejisi uygulayın

Örnek (uygulama klasöründe):

pm2 start server.js --name node-app --time
pm2 save
pm2 startup

• pm2 startup komutu sisteminize PM2’nin boot sırasında çalışmasını bağlar.
• pm2 save mevcut process listesini kalıcı hâle getirir.

Tek instance mı, cluster mı?

• Tek instance: Basitlik ve daha az hata riski.
• Cluster: CPU çekirdeği arttıkça fayda sağlar ama uygulamanın stateless olmasını gerektirir.

Net kontrol: Eğer uygulamanız session’ı hafızada tutuyorsa cluster kullanırken sorun yaşayabilirsiniz. Bu durumda session’ı dış servis (ör. Redis) veya token tabanlı yaklaşımla yönetmeniz gerekir.

Nginx reverse proxy: Uygulama portunu saklama ve performans ayarı

Nginx’in amacı: 80/443 üzerinden gelen trafiği uygulama portunuza iletmek (ör. 3000) ve istemciyi doğru şekilde yönetmek.

Net Nginx yerleşimi

• server bloğunda listen 80 ve listen 443 ssl
• proxy_pass http://127.0.0.1:3000
• WebSocket varsa Upgrade/Connection header’ları

Minimum proxy ayarları (mantık)

• Uygulama zaman aşımı (timeout)
• Client body limit (upload varsa)
• Proxy header’lar (IP adresini doğru iletmek için)

Bu başlıklarda eksik ayar, uygulama içinde yanlış IP görme veya uzun isteklerde kesilme gibi somut problemlere yol açar.

TLS/HTTPS: Sertifika yönetimini “operasyon rutini” yapın

TLS kurulumunda kritik nokta: Sertifikayı sadece “ilk kez almak” değil, süre/yenileme işlemlerini işletmektir.

Net önerilen yaklaşım

• Otomatik yenileme (genellikle ACME istemcisi)
• Güçlü şifreleme ayarları
• HTTP’ten HTTPS’e zorunlu yönlendirme (redirect)

Sık karşılaşılan hata: yenileme unutulması

Sertifika yenilenmezse yaşanan problem net biçimde görünür: site belirli aralıklarla güvenlik uyarısı verir. Bu nedenle yenileme durumunu düzenli kontrol edin.

HSTS ve güvenlik header’ları

HSTS (Strict-Transport-Security) ve temel güvenlik header’ları, HTTPS davranışını daha tutarlı hâle getirir. Ancak ilk etapta yanlış max-age veya yanlış preload yaklaşımı risk doğurabilir; bu ayarları test ortamında doğrulayın.

Performans ayarları: Node tarafını değil, giriş/altyapıyı optimize edin

Node uygulamasını hızlandırmak çoğu zaman “tek başına Node’u optimize etmek” değildir. VDS üzerinde en hızlı kazanım genellikle ters proxy ve cache katmanında gelir.

Nginx’te net kazanımlar

• Gzip/brotli compression (uygun MIME türlerinde)
• Statik dosyalarda doğru cache-control
• Uzun isteklerde timeout’ların uygulamanıza uygun olması

Gerekli değilse cache’i abartmayın

Bazı içerikler (kişiye özel sayfalar gibi) cache edilmemelidir. Aksi hâlde veri karışması yaşanır. Cache kurgusu yaparken hangi endpoint’lerin cache edileceğini net listeleyin.

Loglama ve disk yönetimi: En sık düşüren sorunlardan biri

Node uygulaması logları hızla disk şişmesine neden olabilir. Bu, servislerin “kendi kendine” durmasına kadar gidebilir.

Net log stratejisi

• Uygulama loglarını ayrı dosyalara alın
• Log rotasyonu (rotation) kullanın
• Disk doluluk takibi kurun

Pratik kontrol noktaları

• /var/log/nginx ve uygulama log dizinlerinde büyümeyi takip edin
• Haftalık/dönemsel olarak eski logları temizleyin
• Disk doluluğu için eşiği belirleyin (ör. %80)

Yedekleme (backup) ve geri dönüş planı

VDS üzerinde yedekleme yalnızca dosyaları kopyalamak değildir; geri dönüş süresi (RTO) ve veri kaybı (RPO) kritik metriklerdir.

Net yedek kapsamı

• Uygulama kodu + konfigürasyon dosyaları
• Environment değişkenleri için kullanılan şema/sekreter yönetimi
• Veritabanı (mümkünse ayrıca)
• Nginx konfigürasyonları ve PM2 process listesi

En azından şu geri dönüş senaryosunu yazın

• “Son çalışır hâlimiz hangi tarihteydi?”
• “Kod + konfigürasyon geri gelince veritabanı hangi snapshot ile eşleşti?”

Bu cümleler belirsiz kalırsa, bir arıza anında kurtarma süresi uzar.

İzleme ve sağlık kontrolleri: Rutin test listesi

“Çalışıyor” görmeniz tek başına yeterli değildir. Performans düşüşü, hata artışı veya gecikme (latency) ilk fark edilmesi gereken şeylerdir.

Net izleme kontrolleri

• CPU ve RAM trendi
• Uygulama yanıt süresi (p95/p99 hedefleyin)
• Hata oranı (HTTP 5xx)
• Nginx upstream timeout sayıları
• Disk doluluğu
• PM2 restart sayıları

Basit bir sağlık endpoint’i

Uygulamada /health gibi bir endpoint tanımlayın: - Veritabanına gerçekten bağlanıp bağlanmadığını net belirleyin - Nginx ve izleme sistemleri bunu kontrol etsin

Node.js deploy akışı: Kesintisiz güncelleme hedefi

Güncelleme sırasında servis kesilmesi yaşarsanız bu “planlanmış bakım” gibi görünür. Net deploy akışı için:

• Yeni sürümü hazırlayın
• Mümkünse zero-downtime davranış planlayın
• Hatalı sürümde rollback mekanizması kurun

Rollback için pratik yaklaşım: - Son stabil build’leri saklayın - PM2 ile eski process state’ini yeniden ayağa kaldırın

Karşılaştırma: VDS kurulumunda en sık yapılan 7 hata

Aşağıdaki maddeler Node.js uygulamasını en çok etkileyen konulardır. Bu rehberin önceki bölümlerinde her birine net çözüm adımı verdik.

1) Uygulama portunu doğrudan internete açmak 2) PM2’nin boot sırasında çalışmasını bağlamamak (pm2 startup) 3) Şifreli SSH ile girişe izin vermek 4) Nginx timeout/headers’ı ayarlamadan WebSocket veya upload denemek 5) Log rotasyonu olmadan uzun süre çalıştırmak 6) Yedekleme var ama geri dönüş test edilmemiş olmak 7) İzleme yokken “bir anda yavaşladı”yı yakalayamamak

Sonuç: Hemen uygulayabileceğiniz aksiyon listesi

Node.js uygulaması için VDS yapılandırmasını tek seferde “mükemmel” yapmak yerine, riskleri sırayla kapatın. Önce güvenlik ve servis sürekliliğini alın (SSH key + firewall, PM2 startup), sonra giriş katmanını doğru kurun (Nginx reverse proxy + TLS), ardından operasyonu standardize edin (log rotasyonu + disk takibi + yedek ve geri dönüş kontrolü).

Bugün yapmanız gereken en net adımlar: 1) PM2 ile process’i başlatıp boot’a bağlayın, 2) Nginx ile 443’te TLS kullanıp uygulama portunu internetten kapatın, 3) log rotasyonu ve disk eşiği takibini ekleyin, 4) yedekten geri dönüş senaryosunu en az bir kez test edin.