Node.js VDS Kurulumu: Performans ve güvenlik odaklı net yapı

Node.js uygulamalarında asıl fark, “uygulama çalışıyor”dan sonra başlar: bağlantıların doğru yoldan gitmesi, uygulamanın yeniden başlatmalarla ayakta kalması, logların izlenebilir olması ve trafiğin güvenli yönetilmesi. Bu rehber; bir VDS (Virtual Dedicated Server) üzerinde Node.js uygulamanızı ters proxy, process yönetimi, TLS (HTTPS) ve güvenlik bileşenleriyle birlikte, adım adım ve kontrol edilebilir şekilde yapılandırmanızı sağlar. Okuduktan sonra, kendi ortamınıza uygun çekirdek mimariyi kurup “nerede sorun yaşanır” sorusuna da net yanıt vereceksiniz.

Hedef mimari: VDS üzerinde hangi bileşenler olmalı?

Node.js tek başına çalışabilir; ancak üretim ortamında pratik gereksinimler devreye girer: statik dosyalar, HTTPS, HTTP/2 uyumu, bağlantı limitleri, uygulama çökünce otomatik ayağa kalkma ve logların merkezi takibi.

Aşağıdaki şema pratikte en sık kullanılan üretim mimarisidir: - Nginx: İstemciden gelen HTTP/HTTPS trafiğini karşılar, ters proxy yapar - Node.js uygulaması: localhost üzerinden Nginx’e servis verir - systemd: Uygulama süreçlarını yönetir (restart, start/stop, bağımlılıklar) - log yönetimi: Uygulama logları + Nginx logları izlenebilir olur - yedekleme (backup): Kod + yapılandırma + gerekirse veri katmanı - Güvenlik katmanları: firewall, SSH kısıtları, otomatik güncelleme disiplini

Tek uygulama mı, çoklu uygulama mı?

Tek bir Node.js uygulaması için de aynı bileşenler kullanılır; fark, process yönetiminde birden fazla systemd birimi veya bir iş yöneticisi (ör. PM2) tercihidir. - Tek servis: systemd birimi doğrudan yeterlidir. - Çok servis / sık ölçekleme: PM2 veya container yaklaşımı değerlendirilebilir; ancak bu rehber VDS odaklı “temiz” systemd kurulumunu esas alır.

1) VDS işletim sistemi ve kaynak planı: yanlış seçim maliyeti artırır

Node.js uygulamasında en kritik nokta performanstan önce stabilitedir. OS seçimi ve minimum kaynak planı, günlük operasyon maliyetini belirler.

Önerilen OS: LTS tabanlı Linux

Şu yaklaşım net ve güvenilirdir: - Dağıtım: Ubuntu LTS veya Debian Stable - Yalnızca gerekli paketler kurulur - Zaman dilimi, locale ve DNS çözümleme ayarları standardize edilir

Kaynak planı: “tek sayı” yok, ölçüm var

Aşağıdaki tablo, tipik Node.js (REST/API) yükleri için başlangıç çerçevesi verir. Kesin değer değildir; doğru değer, uygulama ölçümüyle netleşir.

Net kural: Uygulamanızda CPU sürekli %70+ bandına oturuyorsa “RAM artırmak” çoğu zaman yanlış ilk adımdır; önce darboğaz tespiti gerekir.

2) Node.js kurulumu: uygulama bağımsız, sürüm kontrolü net olmalı

Sürüm yönetimi üretimde kritik bir konudur. Sistem Node’u ile uygulama Node’u karıştığında sorun büyür.

Sürümü kilitleme yaklaşımı

• Uygulama klasöründe package.json üzerinden Node uyumluluğunu tanımlayın
• Build/CI tarafında aynı Node sürümünü kullanın
• Çalışan sürümü node -v ile doğrulayın

Çalıştırma portu stratejisi

Uygulamanız Nginx’e servis versin; doğrudan internetten açılan port sayısını minimumda tutun. - Node uygulama portu: ör. 127.0.0.1:3000 - Nginx listen: ör. 80 ve 443

Bu sayede firewall ve erişim kontrolü daha net olur.

3) Nginx ters proxy: bağlantı akışı, TLS ve limitler doğru kurulmalı

Nginx’in amacı sadece “proxy yapmak” değil; HTTP/HTTPS yönetimini, performans limitlerini ve güvenliği tek noktada toplamak.

Temel ayarlar

Aşağıdaki konfigürasyon mantığıyla ilerleyin: - server bloğunda listen 443 ssl http2; - location / içinde proxy_pass http://127.0.0.1:3000; - WebSocket varsa Upgrade başlıklarını ekleyin - Zaman aşımı ve body limitlerini uygulama gerçeklerine göre ayarlayın

Örnek Nginx server bloğu (mantık şablonu)

server {
  listen 443 ssl http2;
  server_name example.com;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  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_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;

    client_max_body_size 20m;
  }
}

Not: WebSocket kullanıyorsanız proxy_set_header Upgrade $http_upgrade; ve proxy_set_header Connection "upgrade"; ekleyin.

Hata ayıklama için net test

Konfigürasyon sonrası şunları doğrulayın: - Nginx yapılandırması: nginx -t - Uygulama portu yerel mi: curl -I http://127.0.0.1:3000/ - Harici istek akışı: curl -I https://example.com/

4) systemd ile process yönetimi: uygulama çökünce otomatik toparlanır

Node.js uygulaması hata verip kapanırsa, “otomatik yeniden başlatma” üretim için zorunludur. systemd bunu ölçülebilir ve denetlenebilir şekilde sağlar.

systemd birimi (örnek)

• Servis adı: ör. node-app.service
• Çalışma dizini: uygulama klasörü
• Çalıştırma komutu: npm start veya node dist/server.js

[Unit]
Description=Node.js API
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/node-app
Environment=NODE_ENV=production
ExecStart=/usr/bin/npm start
Restart=always
RestartSec=3

StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Net kontrol adımları

1. Servisi ekle: /etc/systemd/system/node-app.service
2. Yükle: systemctl daemon-reload
3. Başlat: systemctl start node-app
4. Durum kontrol: systemctl status node-app --no-pager
5. Otomatik açılış: systemctl enable node-app

5) Loglar ve izleme: “sorun oldu mu?” sorusunu dakikaya indir

Node.js + Nginx kurulumunda loglar iki kaynakta toplanır: - Nginx erişim/hata logları - Node süreç logları (systemd journal)

Hedef: belirli hata türlerine hızlı erişim

Önerilen pratik: - HTTP 5xx artışını Nginx hata loglarıyla ilişkilendir - Uygulama tarafında request başına request id ile log satırlarını eşleştir - OOM (Out of Memory) gibi uç durumları RAM kullanımıyla bağla

Net komutlar

• journalctl -u node-app -n 200 --no-pager
• Nginx hata logu inceleme: dağıtıma göre /var/log/nginx/error.log

6) Güvenlik: VDS üzerinde “internet maruziyetini” azaltın

Node.js servisinin güvenliği, sadece kod güvenliği değil aynı zamanda ağ yüzeyinin küçültülmesiyle sağlanır.

SSH kısıtları ve parola yerine anahtar

• Parola ile giriş kapatın
• SSH anahtarı kullanın
• Varsayılan port değiştirmek tek başına güvenlik değildir; asıl etki firewall ile gelir

Firewall (UFW veya dağıtım firewall’ı)

Net uygulama mantığı: - Sadece 80/443 açık - SSH gerekiyorsa 22 sadece belirli IP’lerden açık - Node portu 3000 gibi portlar internete kapalı kalsın

Örnek kurgu: - Açık: 80, 443 - Kısıtlı: 22 (sadece kendi IP’niz) - Kapalı: 3000 (yalnızca localhost)

Güncelleme disiplini

• OS güvenlik güncellemelerini düzenli uygula
• Node modüllerinde sürüm güncellemelerini kontrol et
• Üretimde geliştirici araçlarını (ör. gereksiz paketler) tutma

7) Yedekleme (backup) tasarımı: yanlış yedek, kayıp veri demektir

Yedekleme sadece “kopya almak” değildir. Hangi veriyi, hangi sıklıkla, nasıl doğrulayacağınız net olmalıdır.

Kod ve yapılandırma

Minimum set: - Uygulama kodu (git repo veya dosya kopyası) - Nginx konfigürasyon dosyaları - systemd servis dosyaları - Ortam değişkenleri (env): mümkünse şifreli saklama

Veri katmanı varsa

• Veritabanı için ayrı yedek alın
• Yedek dosyalarını test edin: geri yükleme (restore) denemesi yapın

Net kontrol listesi

• Yedekleme aralığı: kritik işlerde saatlik
• Saklama süresi: en az 7-14 gün (politika net olmalı)
• Geri yükleme testi: ayda en az 1 kez

8) Performans iyileştirmeleri: ilk hedef doğru limitler ve doğru önbellek

Node.js tarafında performans; gereksiz senkron işler, yetersiz timeoutlar ve kontrolsüz istek hacmiyle düşer. Nginx burada ilk “kalkan” olur.

Net uygulanabilir iyileştirmeler

• Nginx’te client_max_body_size değerini gerçek ihtiyaca göre ayarla
• Uygulama yanıt süresi uzuyorsa Nginx timeoutlarını körü körüne yükseltme; önce uygulama darboğazını bul
• İlgili uçlarda cache katmanı kullan: statik içerik + mümkün olan API sonuçları
• Log seviyesini üretimde aşırı verbose tutma; disk şişmesini engelle

9) Node.js için ölçekleme: dikey mi yatay mı, önce kriter belirle

VDS ölçeklemede iki yol var: daha fazla kaynak (dikey) veya birden fazla instance (yatay).

Dikey ölçeklemenin net göstergeleri

• CPU kullanımı sürekli yüksek
• Tek instance performansı düşüyor ama istek dağılımı gerekmiyor

Yatay ölçeklemenin net göstergeleri

• Trafik arttıkça gecikme büyüyor
• Uygulama stateless hale getirilebiliyor (session’lar dış depoda)

Yatayda Nginx load balancing devreye girebilir; ancak önce uygulamanın stateless tasarımı sağlanmalıdır.

Sonuç: VDS kurulumu için yapılacak aksiyon listesi

Node.js uygulaması için VDS yapılandırmasında en doğru yaklaşım, bileşenleri “tek tek çalıştırmak” değil, birlikte denetlenebilir hale getirmektir. Bugün yapmanız gereken net adımlar şunlar: 1. Node uygulamanızı localhost üzerinde çalıştırın ve internetten kapalı tutun 2. Trafiği Nginx ile yönetin; TLS (HTTPS) ve doğru header’ları ekleyin 3. Uygulamayı systemd ile yönetin; restart ve journal log akışını kurun 4. Firewall ile yalnızca gerekli portları açın (80/443 + gerekirse kısıtlı SSH) 5. Kod + konfigürasyon + veri katmanını kapsayan yedekleme planı oluşturun ve geri yükleme testi yapın

Bu sırayla ilerlediğinizde; hem performans hem de güvenlik “sonradan düzeltilecek” sorunlar yerine, başlangıçta kontrol altına alınır.