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

Node.js uygulaması için VDS (Virtual Dedicated Server) kurarken en sık yapılan hata, “paket almak” ile işin bitmiş sayılmasıdır. Oysa performans, güvenlik ve yönetilebilirlik; doğru süreç yönetimi, doğru ağ katmanı (reverse proxy), doğru log/izleme ve düzenli yedekleme ile oluşur.

Bu rehberde; web isteklerini doğru yöneten mimariyi, PM2 ile kararlı çalışma yaklaşımını, Nginx/Caddy seçimini, güvenlik duvarı ve bağlantı limitlerini ve pratik test yöntemlerini net bir sırayla göreceksiniz. Okuduktan sonra VDS’inizi hangi ayarlarla “prod’a benzer” hale getireceğinizi açık şekilde planlayabileceksiniz.

Node.js VDS mimarisi: Tek sunucu, net görev dağılımı

Node.js uygulamasını VDS’e koyduğunuzda en temiz kurulum şudur:

• İnternet → reverse proxy (Nginx veya Caddy)
• Reverse proxy → Node.js uygulaması (localhost:port)
• Süreç yönetimi → PM2 (process manager)
• Loglar → uygulama logları + Nginx erişim logları
• Yedekleme → uygulama kodu + yapılandırma + veritabanı

Bu dağıtımın pratik getirisi şudur: TLS (SSL), sıkıştırma, cache (gerektiğinde), rate limit ve gzip/brotli gibi özellikleri reverse proxy üzerinden yönetirsiniz. Node.js tarafında ise yalnızca uygulama mantığı çalışır.

Nginx mi Caddy mi? Hızlı seçim

VDS’te Node.js için iki seçenek de kullanılabilir. Ancak başlangıçta hedef, “daha az sürpriz” olan kurulumdur.

NetKıyas bakış açısıyla öneri: Ekibiniz/erişilebilir dokümantasyon Nginx ağırlığındaysa Nginx ile ilerleyin. “En kısa sürede çalışır” önceliği varsa Caddy de doğrudan sonuç verir.

Donanım seçimi: Node.js için doğru temel değerler

Node.js’in performansı yalnızca CPU’ya bağlı değildir. Event loop, eşzamanlı istek sayısı, uygulamanın yaptığı I/O (DB, dosya, HTTP çağrıları) ve Node süreçlerinin sayısı belirleyicidir.

Başlangıç için net VDS öneri profilleri

Aşağıdaki tablolar, tipik web/API senaryolarında “çalıştır-izle” yaklaşımı içindir. Değerleri uygulamanızın yoğunluğuna göre güncelleyin.

Not: RPS hedefiniz net değilse “CPU% + Memory RSS + event loop lag” verilerine göre karar verin. Sadece “paket küçük/ büyük” şeklinde ilerlemek gecikme doğurur.

CPU/RAM dışında disk ve IOPS neden kritik?\n- Loglar büyür (özellikle access log) → disk dolarsa servisler bozulabilir.

• Yedekleme (backup) dosyaları geçici alan ister.
• Uygulama build çıktıları (örn: bundler) ve cache dizinleri büyüyebilir.

Bu yüzden disk alanını ve I/O performansını SSD/NVMe tercih ederek almak, “beklenmeyen kesinti” riskini azaltır.

Kurulum adımları: VDS üzerinde Node.js’yi kalıcı çalıştırın

Bu bölümde Ubuntu/Debian benzeri bir sistem varsayımıyla anlatıyorum. Dağıtıma göre paket adları değişebilir.

1) Node.js ortamını kurun (tekil sürüm, kontrollü güncelleme)

• Node.js sürümünü uygulama ile uyumlu tutun.
• Global bir “rastgele” sürüm kullanmak yerine, proje üzerinden sabitleyin.

Pratik yaklaşım: - Eğer kullandığınız framework veya kütüphaneler belirli Node sürümüne bağlıysa aynı major sürümü kullanın. - Gerektiğinde sürümü güncelleyin, ama prod’da otomatik sürüm atlaması yapmayın.

2) PM2 ile süreç yönetimi (restart, log, otostart)

PM2, Node.js uygulamasını çökme sonrası yeniden ayağa kaldırmak ve logları yönetmek için en pratik araçlardan biridir.

PM2 ile temel bir akış: - Uygulamayı start edin - Logları yapılandırın - Sistem reboot sonrası otomatik başlatmayı ekleyin

Örnek (uygulama dosyanıza göre değiştirin):

pm2 start ecosystem.config.js --env production
pm2 save
pm2 startup

PM2’de kritik ayarlar

• instances: CPU sayısına göre paralel örnek (ör. cluster) kurabilirsiniz.
• max_memory_restart: Bellek limitini aşınca restart ile “sızıntı” senaryolarını yönetebilirsiniz.
• out_log / error_log: Logları disk dolmayacak şekilde planlayın.

3) Reverse proxy ile güvenli port ayrımı

Node uygulamasını genellikle localhost üzerinde dinletin. Örneğin uygulama 127.0.0.1:3000 adresinde dinlesin.

Reverse proxy ise dışarıya açık portları yönetir: - 80 → 443 yönlendirme - TLS termination - Request header düzenleme - WebSocket desteği (varsa)

Bu ayrımın faydası: Node uygulaması direkt internete çıkmaz; saldırı yüzeyi azalır.

WebSocket kullanıyorsanız kontrol listesi

WebSocket yoksa bu adımı atlayın. Var ise şunları doğrulayın: - Reverse proxy Upgrade/Connection header’larını doğru iletir - Idle timeout (varsa) çok kısa değildir - PM2 loglarında bağlantı kopması görünmüyor

Nginx/Caddy ile net örnek mantık

Ayrıntılı “kopyala-çalıştır” yerine mantığı net anlatmak daha doğru olur; çünkü uygulama yolları (path), servis adı ve port değişebilir.

Common path: İstekleri Node’a proxy etme

• server_name alanına domaininizi tanımlayın
• location / ile tüm istekleri proxy_pass ile Node portuna gönderin
• Header’ları iletmek için standart proxy ayarlarını kullanın (host, x-forwarded-for vb.)

Rate limit ve body limit (DoS ve hatalı client senaryoları)

Node tarafına kontrolsüz istek yollamak; hem performansı düşürür hem de log şişmesine neden olur.

Net öneri: - Reverse proxy’de rate limit uygulayın - Upload varsa client_max_body_size gibi sınırlar belirleyin - Uygulama tarafında da istek doğrulamasını güçlendirin

Güvenlik: Firewall + süreç yalıtımı + güncel paketler

VDS’te güvenlik “tek ayar” değildir. En hızlı etki eden üçlü: 1) Sadece gerekli portları açın 2) Güncellemeleri düzenli tutun 3) Uygulamayı root olarak çalıştırmayın

Firewall (UFW/iptables) ile net port politikası

Örnek politika (senaryonuza göre uyarlayın): - 22 (SSH): yalnızca kendi IP’nizden erişim - 80/443: herkese açık - 3000/uygulama portu: sadece localhost’a bağlı, externale kapalı

Bu yaklaşım, uygulama portunu internete açmadığınız için saldırı yüzeyini küçültür.

SSH erişimi: anahtar (key) zorunluluğu

Şunları net şekilde yapın: - Parola ile giriş kapatın - SSH key ile giriş kullanın - Fail2ban gibi araçlarla brute force denemelerini sınırlayın

Güncelleme rutini

• Kernel/OS güncellemelerini düzenli planlayın
• Nginx/Caddy ve Node paketlerini “kontrollü güncelleme” ile ilerletin
• Uygulama bağımlılıklarını (npm/yarn) günlerken test edin

Log, izleme ve disk dolmasını önleme

Node + reverse proxy kombinasyonunda en hızlı kesintiler genelde “disk doldu” veya “log patladı” yüzündendir.

Log rotasyonu (logrotate) şart

Aksiyon: - Nginx access/error log için logrotate etkin olsun - PM2 logları için saklama politikası belirleyin

Ölçüm: - Günlük olarak /var/log büyümesini kontrol edin - Uygulama loglarına gereksiz debug seviyesini uzun süre açık bırakmayın

Health check ve canlılık doğrulama

Sadece “servis çalışıyor” demek yetmez.

• Reverse proxy’den bir health endpoint (örn: /health) oluşturun
• PM2 ile süreç ayağa kalksa bile uygulama DB’ye bağlanamıyorsa hatayı yakalayın

Yedekleme (backup): Node kodu + yapılandırma + veri

Yedekleme planı tek başına yeterli değil; geri yükleme (restore) test edilmelidir.

Ne yedekleyin?

• Uygulama kodu (repo/artefact)
• PM2 ekosistem dosyaları (process ayarları)
• Reverse proxy konfigürasyonu (Nginx/Caddy)
• Ortam değişkenleri (env) yaklaşımı
• Veritabanı (MySQL/PostgreSQL) dump + mümkünse tutarlı zaman aralığı

Saklama ve sıklık

Net kural: - Günlük yedek + haftalık tam yedek mantığını kullanın - Kritik bir değişiklikten önce (örn: yeni release) “ön yedek” alın

Performans testleri: Ters proxy ve Node’u birlikte ölçün

VDS kurduktan sonra iki noktayı ölçün: - Reverse proxy’den gelen yanıt süreleri - Uygulamanın darboğazı (CPU, event loop, DB latency)

Testte bakacağınız net metrikler

• TTFB (Time to First Byte): İlk yanıt gecikmesini gösterir
• Toplam istek süresi (p95/p99)
• Hata oranı (4xx/5xx)
• CPU yüzdesi ve RAM kullanımı

Basit yük testi yöntemi

• Uygulamanın gerçek route’ları ile test yapın
• Aynı endpoint için farklı dakikalarda deneme yapın
• DB güncellemesi gerektiren testlerden kaçının (kademeli ortamda)

Tipik yanlışlar ve net düzeltmeler

• Node portunu internete açık bırakmak: Reverse proxy yalnız kalsın, Node localhost’a bağlı olsun.
• PM2 loglarını sınırsız bırakmak: Disk dolması çok hızlı olur.
• Rate limit olmadan prod’a çıkmak: Trafik dalgalanması uygulamayı yorar.
• Sadece CPU’ya bakmak: RAM ve event loop gecikmesi de aynı derecede belirleyicidir.
• Yedek aldıktan sonra restore test etmemek: “Yedek var” değil, “yedek geri getiriliyor” olmalı.

Sonuç: VDS’inizi “prod’a benzer” hale getirmek için aksiyon planı

İlk hedefiniz; Node.js uygulamanızı internete doğrudan maruz bırakmadan reverse proxy üzerinden çalıştırmak, PM2 ile süreç yönetimini oturtmak ve log/disk güvenliğini sağlamak olmalı. Ardından firewall ile port politikanızı netleştirin, /health ile canlılık ölçümü ekleyin ve yedekleme için en azından günlük plan + restore testi yapın.

Bugün atacağınız en net adımlar: (1) Node’u localhost’ta çalıştırın, (2) Nginx/Caddy ile TLS + proxy kurun, (3) PM2 ve log rotasyonu ayarlayın, (4) sadece gerekli portları açın, (5) yedek alıp geri yüklemeyi deneyin. Bu sırayı izlediğinizde Node.js VDS kurulumunuz “çalışıyor” seviyesinden “yönetilebilir ve öngörülebilir” seviyesine çıkar.