Nodejs Kurulumu Nasıl Yapılır ve Uygulama Nasıl Deploy Edilir?

Nodejs kurulumu nedir ve uygulamayı sunucuya nasıl çıkarırsınız?

Nodejs kurulumu, JavaScript çalışma ortamını bir Linux sunucuya yükleyip uygulamanızı tarayıcıdan erişilebilir hale getirmek demektir. Süreç beş adımdan oluşur: Node.js'i kurarsınız, kodu sunucuya alırsınız, ortam değişkenlerini tanımlarsınız, Nginx ile dış dünyaya açarsınız ve systemd ile sürekli çalışır tutarsınız.

Bu yazı, kendi VPS'ini yöneten web sitesi sahiplerine ve yazılımcılara hitap ediyor. Komutları sırayla uygularsanız basit bir Node.js uygulamasını alan adınızın arkasında yayına alırsınız. Yönetimi hosting firmasına bırakmışsanız, bu sayfa size sağlayıcınıza hangi soruları soracağınızı gösterir.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu nedenle anlatım Node.js, Nginx ve systemd resmi dokümanlarına dayanır. Komut örneklerinde yalnızca example.com ve dokümantasyon IP blokları geçer. Kendi gerçek adresinizi ve parolalarınızı örneklerle karıştırmayın.

Kardeş konuları burada tekrarlamıyoruz. Süreç yönetimi için PM2'yi ayrı bir yazıda ele alıyoruz. Next.js uygulamalarının VPS'e çıkışı da ayrı bir yazının konusudur. Bu yazıda yalnızca çıplak Node.js uygulamasını ele alırız.

Nodejs kurulumundan önce hangi hazırlıklar gerekir?

Önce elinizde root ya da sudo yetkili bir kullanıcı, SSH erişimi ve internete açık bir Linux sunucu olmalı. Ayrıca alan adınızın bir A kaydı sunucunun IP adresini göstermeli. Bu kayıt yayılmadan Nginx ve TLS adımlarını test edemezsiniz.

DNS kaydının doğru yayıldığını görmek için DNS sorgulama aracını kullanabilirsiniz. Sunucunun IP adresini teyit etmek için de IP sorgulama aracı işinizi görür.

Hazırlık listesi şöyledir:

• Parola yerine SSH anahtarıyla giriş yapın.
• Uygulama için root olmayan ayrı bir sistem kullanıcısı oluşturun.
• Paket listesini güncelleyin ve güvenlik güncellemelerini yükleyin.
• Alan adının A kaydını sunucu IP adresine yönlendirin.
• Güvenlik duvarında yalnızca SSH, 80 ve 443 portlarını açık bırakın.

Uygulama portunu, örneğin 3000'i, dışarıya açmayın. Uygulama yalnızca yerel adreste dinleyecek, dış trafiği Nginx karşılayacak. Bu ayrımı ilerleyen bölümlerde nedenleriyle anlatıyoruz.

Nodejs kurulumu için hangi yöntemi seçmelisiniz: dağıtım deposu, NodeSource ya da nvm?

Üç yaygın yol var ve her birinin farklı bir takası var. Dağıtım deposu en basit olanıdır, ancak sürüm dağıtımın takvimine bağlıdır. NodeSource deposu daha güncel sürüm sunar. nvm ise kullanıcı bazında birden çok sürüm tutmanızı sağlar.

Tek uygulamalı bir üretim sunucusunda biz paket yöneticisiyle gelen yöntemi öneririz, çünkü güncellemeler sistemin geri kalanıyla birlikte gelir. Ayrıca systemd servisinde yol sorunu yaşamazsınız. Birden fazla proje ve sürüm yönetmeniz gerekirse nvm daha rahattır.

Üretimde hangi Node.js sürümünü kullanmalısınız?

Üretimde yalnızca Active LTS ya da Maintenance LTS sürümünü kullanın. Node.js'in sürüm durumları sayfası bunu açıkça söyler: üretim uygulamaları yalnızca LTS sürümlerini kullanmalıdır. Current sürüm yeni özellikleri denemek içindir.

Sayfaya göre Current aşaması altı ay sürer, LTS ise toplam 30 ay kritik hata düzeltmesi garantisi verir. Sürüm numaraları sık değiştiği için bu yazıya sabit bir numara yazmıyoruz. Güncel LTS numarasını her zaman o sayfadan kontrol edin.

Sürüm kararında iki pratik kural işe yarar:

• Projenin package.json dosyasındaki engines alanına desteklediği sürümü yazın.
• Bitmiş ömrü (EOL) olan sürümde kalmayın, çünkü güvenlik yaması almazsınız.
• Sürümü yükseltmeden önce kopyada test edin ve bağımlılıkları yeniden kurun.

Böylece hem geliştirme hem üretim aynı ana sürümde kalır. Sürüm farkından doğan "bende çalışıyordu" sorunlarının çoğu da burada biter.

Nodejs kurulumunu dağıtım deposundan nasıl yaparsınız?

Debian tabanlı bir dağıtımda Node.js kurulumu iki komuttan ibarettir. Önce paket listesini yeniler, ardından nodejs ve npm paketlerini kurarsınız. Kurulum bitince sürümü komut satırından doğrularsınız.

sudo apt update
sudo apt install nodejs npm
node --version
npm --version

Dağıtım deposundaki sürüm LTS olmayabilir. Bu yüzden çıktıdaki numarayı resmi sürüm sayfasıyla karşılaştırın. Numara eski bir ana sürümü gösteriyorsa NodeSource ya da nvm yöntemine geçmeyi düşünün.

RHEL ailesinde paket yöneticisi farklıdır, ancak mantık aynıdır. Dağıtımınızın kendi dokümanına bakın ve Node.js için hangi modül ya da paket adının kullanıldığını orada doğrulayın. Biz burada bu dağıtımlar için komut uydurmuyoruz.

NodeSource deposuyla Nodejs kurulumunu nasıl yaparsınız?

NodeSource, kurmak istediğiniz ana sürümü paket olarak sunan üçüncü taraf bir depodur. Bir kurulum betiği sistemin paket yöneticisine bu depoyu ekler. Ardından Node.js'i yine apt ya da dnf ile kurarsınız.

Güncel betik adresini ve komutlarını NodeSource'un kendi sayfasından alın. Biz burada sabit bir komut yazmıyoruz, çünkü betik adresi ve sürüm seçimi zamanla değişiyor. Eski bir blog yazısından kopyalanan komut, bugün başka bir sürümü kurabilir.

Betikleri doğrudan kabuğa yönlendirmek yerine önce indirip okuyun. Yani dosyayı kaydedin, içeriğine göz atın, sonra çalıştırın. Bu alışkanlık yalnızca NodeSource için değil, her kurulum betiği için geçerlidir.

Depo eklendikten sonra güncellemeler paket yöneticisinden gelir. Üstelik sürüm yükseltmesini bilinçli yaparsınız, çünkü ana sürüm değişimi için depoyu yeniden ayarlamanız gerekir. Bu da beklenmedik yükseltmeleri engeller.

nvm ile Nodejs kurulumunu nasıl yaparsınız ve servislerde nelere dikkat edersiniz?

nvm, Node.js sürümlerini kullanıcı dizininizde yöneten bir araçtır. Resmi README, kurulum betiğini sürüm numarası içeren bir adresten çekmenizi söyler. Yazıldığı sırada README'de v0.40.8 görünüyordu, ancak siz güncel numarayı depodan teyit edin.

curl -o install-nvm.sh https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh
less install-nvm.sh
bash install-nvm.sh
nvm install --lts
nvm alias default node

Betiği önce dosyaya indirip less ile okumak, körlemesine çalıştırmaktan daha güvenlidir. Kurulumdan sonra yeni bir oturum açın ya da kabuğu yeniden yükleyin. Aksi halde nvm komutunu bulamazsınız.

Burada kritik bir nokta var. nvm README'sine göre nvm bir ikili dosya değil, kaynaklanan bir kabuk fonksiyonudur. Servisler ve systemd profil dosyalarınızı otomatik yüklemez. Bu yüzden systemd birimine node'un tam yolunu yazmanız gerekir.

Proje köküne bir .nvmrc dosyası koyarsanız, nvm use komutu sürümü oradan okur. Üretimde ise sürüm değişimi yerine sabit bir yol tercih edin. Ekip büyüdükçe bu tutarlılık size zaman kazandırır.

Uygulama kodunu sunucuya nasıl alırsınız?

En temiz yol, kodu Git deposundan çekmektir. Dosyaları elle kopyalamak hata üretir, çünkü hangi sürümün sunucuda olduğunu izleyemezsiniz. Git ile ise her yayının bir commit numarası olur ve geri dönüş kolaylaşır.

Git komutları için Git ve GitHub kullanım rehberimize bakabilirsiniz. Sunucuda yalnızca okuma yetkili bir deploy anahtarı kullanın. Kişisel hesabınızın anahtarını sunucuya koymayın.

sudo useradd --system --create-home --home-dir /srv/nodeapp --shell /usr/sbin/nologin nodeapp
sudo -u nodeapp git clone https://git.example.com/ekip/nodeapp.git /srv/nodeapp/current
cd /srv/nodeapp/current
sudo -u nodeapp npm ci --omit=dev

Burada npm ci komutunu seçmemizin nedeni var. Node.js güvenlik rehberi, kilit dosyasını zorunlu kılmak için npm install yerine npm ci kullanmanızı önerir. Bu komut, kilit dosyasındaki sürümleri birebir kurar.

Projeniz bir derleme adımı gerektiriyorsa, örneğin TypeScript, derlemeyi yayın sırasında çalıştırın. Bazı projelerde geliştirme bağımlılıkları derleme için gerekir. Bu durumda önce hepsini kurup derlemeyi yapar, sonra yalnızca üretim bağımlılıklarını tutarsınız.

.env dosyası ve ortam değişkenlerini nasıl yönetirsiniz?

Ortam değişkenleri, parola ve API anahtarı gibi gizli değerleri koddan ayırır. Bu değerleri Git deposuna koymayın. Depoya giren bir anahtarı sonradan silseniz bile geçmişte durur. Bu yüzden .gitignore dosyanıza .env satırını ekleyin.

Node.js, ek paket olmadan da bu dosyayı okuyabilir. Resmi CLI dokümanı, --env-file seçeneğinin v20.6.0 ile geldiğini ve yeni sürümlerde deneysel etiketini kaybettiğini yazar. Aynı değişken hem ortamda hem dosyada varsa ortamdaki değer kazanır.

PORT=3000
NODE_ENV=production
DATABASE_URL=postgres://uygulama:PAROLA@127.0.0.1:5432/uygulama

Üretimde ise çoğu zaman systemd'nin EnvironmentFile ayarı daha pratiktir. Dosyayı kod dizininin dışına, örneğin /etc/nodeapp/nodeapp.env yoluna koyarsınız. systemd bu dosyayı servis kullanıcısına geçmeden okur. Dolayısıyla dosyayı root'a ait ve 600 izinli tutabilirsiniz.

Dosya biçimini basit tutun: her satırda bir ANAHTAR=değer çifti. Örnekteki PAROLA yer tutucudur. Gerçek bir değeri bu yazıdan, ekran görüntüsünden ya da sohbetten kopyalamayın.

Uygulamayı ilk kez elle nasıl çalıştırıp test edersiniz?

Nodejs kurulumunu bitirdikten sonra servisi kurmadan önce uygulamayı elle çalıştırıp çalıştığını görün. Hata varsa sorunu systemd'nin arkasında değil, doğrudan terminalde görürsünüz. Aşağıdaki küçük sunucu, deneme için yeterlidir.

const http = require('node:http');
const port = process.env.PORT || 3000;
const server = http.createServer(function (req, res) {
  res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
  res.end('Uygulama calisiyor\n');
});
server.listen(port, '127.0.0.1');

Dikkat edin: listen çağrısında adres olarak 127.0.0.1 verdik. Böylece uygulama yalnızca sunucunun kendi içinden erişilebilir olur. Dışarıdan doğrudan bağlantı gelmez, trafik Nginx üzerinden geçer.

Uygulamayı başlatın, başka bir terminalde curl -i http://127.0.0.1:3000/ komutuyla yanıt alın. 200 kodu ve metni görüyorsanız uygulama hazırdır. Ardından Ctrl+C ile durdurup bir sonraki adıma geçersiniz.

Node.js uygulamasını neden doğrudan 80 ve 443 portunda çalıştırmayız?

Çünkü 1024'ün altındaki portlar ayrıcalık ister ve uygulamayı root ile çalıştırmak büyük risktir. Ayrıca TLS sertifikası, sıkıştırma, statik dosya ve istek sınırlama gibi işleri Nginx çok daha olgun biçimde yapar. Uygulamanız yalnızca iş mantığıyla ilgilenir.

Node.js güvenlik rehberi de bu yönde bir öneri verir. HTTP sunucusuna yönelik hizmet engelleme saldırılarına karşı istekleri alıp ileten bir ters proxy kullanmanızı söyler. Aynı bölüm, headersTimeout ve requestTimeout gibi sunucu zaman aşımlarını doğru ayarlamayı da vurgular. Kaynak: Node.js güvenlik en iyi uygulamaları.

Bu mimarinin özeti şöyledir:

• Nginx 80 ve 443 portlarını dinler, TLS'i sonlandırır.
• Node.js uygulaması yerel adreste, örneğin 3000 portunda dinler.
• systemd uygulamayı root olmayan bir kullanıcıyla çalıştırır ve çökerse yeniden başlatır.

Web güvenliğinin genel çerçevesi için OWASP Top 10 yazımıza göz atın. Sunucu tarafı mimariyi daha geniş anlamak isterseniz back-end nedir yazısı iyi bir başlangıçtır.

Nginx ters proxy ile Node.js uygulamasını nasıl yayına alırsınız?

Nginx'te bir sunucu bloğu açar ve istekleri uygulamanın yerel adresine yönlendirirsiniz. Debian tabanlı dağıtımlarda yapılandırma dosyaları çoğunlukla sites-available altında durur. Başka dağıtımlarda conf.d klasörü kullanılabilir. Kendi dağıtımınızın düzenini kontrol edin.

server {
    listen 80;
    server_name example.com www.example.com;

    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;
    }
}

Yapılandırmayı kaydettikten sonra önce sözdizimini sınayın, sonra yeniden yükleyin. Hatalı bir dosyayı yüklemek, çalışan siteyi düşürebilir. Bu yüzden nginx -t adımını asla atlamayın.

sudo nginx -t
sudo systemctl reload nginx

Nginx dokümanına göre proxy_pass yönergesi protokolü ve adresi belirler. Adresin sonuna bir URI eklerseniz eşleşen konum bölümü onunla değişir. Eklemezseniz Nginx normalleştirilmiş istek adresini olduğu gibi iletir. Kaynak: ngx_http_proxy_module.

HTTPS için sertifikayı Nginx'e tanımlarsınız. Sertifikanın ne olduğunu SSL sertifikası yazımızda anlattık. Kurulumdan sonra SSL sorgulama aracıyla zinciri kontrol edebilirsiniz.

Nginx ayarında hangi başlıklar ve zaman aşımları önemlidir?

Üç şeye dikkat edin: Host başlığı, istemci IP bilgisi ve zaman aşımları. Nginx dokümanına göre Host varsayılan olarak $proxy_host değerini alır. Uygulamanız orijinal alan adını görmek istiyorsa $host ile açıkça geçirmeniz gerekir.

İkinci konu istemci IP'sidir. Proxy arkasında uygulama, bağlanan tarafı hep 127.0.0.1 görür. X-Forwarded-For ve X-Forwarded-Proto başlıkları gerçek bilgiyi taşır. Uygulama çerçevenizin bu başlıklara güvenmesi için proxy ayarı gerekebilir. Örneğin Express'te bunun için trust proxy ayarı vardır.

Uygulamanız uzun süren istekler ya da WebSocket kullanıyorsa proxy_read_timeout değerini gözden geçirin. WebSocket için ayrıca Upgrade ve Connection başlıklarını geçirmeniz gerekir. Ayrıntı için Nginx'in WebSocket proxy belgesine bakın.

systemd servisi ile Node.js uygulaması nasıl sürekli çalışır?

systemd, uygulamanızı arka planda başlatır, çökerse yeniden ayağa kaldırır ve sunucu açıldığında otomatik çalıştırır. Bunun için bir birim dosyası yazarsınız. Dosyayı /etc/systemd/system/nodeapp.service yoluna koyun.

[Unit]
Description=Ornek Node.js uygulamasi
After=network.target

[Service]
Type=simple
User=nodeapp
Group=nodeapp
WorkingDirectory=/srv/nodeapp/current
EnvironmentFile=/etc/nodeapp/nodeapp.env
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

ExecStart satırındaki yolu kendi sisteminizde command -v node komutuyla bulun. systemd tam yol ister. nvm kullandıysanız yol kullanıcı dizininizin altında olacaktır.

systemd belgesine göre Type=simple varsayılandır ve ana süreç başladığı anda servis başlamış sayılır. Restart=on-failure ise sıfır olmayan çıkış kodunda yeniden başlatır. RestartSec yeniden başlatmadan önceki bekleme süresidir. Kaynak: systemd.service kılavuzu.

sudo systemctl daemon-reload
sudo systemctl enable --now nodeapp
sudo systemctl status nodeapp
sudo journalctl -u nodeapp -f

Son komut canlı günlükleri gösterir. Uygulama açılmıyorsa ilk bakacağınız yer burasıdır.

systemd servisini nasıl daha güvenli hale getirirsiniz?

Birim dosyasına birkaç satır ekleyerek uygulamanın yetkilerini daraltabilirsiniz. systemd.exec kılavuzu bu satırları anlatır. Her biri bir saldırı yüzeyini küçültür, fakat sıkı ayarlar uygulamanın dosya yazmasını da engelleyebilir. Bu yüzden birini ekleyip test edin.

• NoNewPrivileges=true süreçlerin yeni yetki kazanmasını engeller.
• PrivateTmp=true servise ayrı bir /tmp ve /var/tmp verir.
• ProtectSystem=strict dosya sistemini salt okunur yapar, yalnızca ReadWritePaths= ile açtığınız yollara yazabilirsiniz.

Uygulamanız yükleme klasörüne ya da günlük dosyasına yazıyorsa, o yolu ReadWritePaths ile açmayı unutmayın. Aksi halde uygulama izin hatası verir ve nedeni ilk bakışta belli olmaz.

Ayarları tek tek ekleyin, her seferinde systemctl restart ve günlük kontrolü yapın. Bu yöntem yavaş sürer. Ancak hangi satırın soruna yol açtığını kolayca bulursunuz.

Node.js uygulamasını Docker ile mi çıkarmalısınız?

Docker, uygulamayı bağımlılıklarıyla tek pakette çalıştırmanın bir yoludur. Bu yazıdaki yöntem ise uygulamayı doğrudan sunucuda çalıştırır. İkisi de geçerlidir. Seçim, ekibinizin alışkanlığına ve altyapınızın büyüklüğüne bağlıdır.

Tek bir küçük uygulama için nodejs kurulumu ve systemd çoğu zaman yeterli ve sadedir. Birden çok servisiniz varsa ya da yerel ortamla birebir aynılık istiyorsanız Docker mantıklıdır. Konteynerlerin temelini Docker nedir rehberimizde anlattık.

Bağımlılıkları ve güvenlik duvarını nasıl kontrol altında tutarsınız?

İki alışkanlık işinizi büyük ölçüde korur: bağımlılıkları denetlemek ve açık port sayısını en aza indirmek. Node.js güvenlik rehberi, kilit dosyası kullanmayı ve CI sürecinde npm audit ile zafiyet taramasını otomatikleştirmeyi önerir.

Güvenlik rehberi ayrıca kötü niyetli üçüncü taraf modüllere karşı sürümleri sabitlemeyi anlatır. Yani bağımlılık aralıkları yerine kesin sürümler ve kilit dosyası kullanırsınız. Böylece sunucuya her çıkışta aynı kod ağacını kurarsınız.

Güvenlik duvarında ise yalnızca gerekli portlar açık kalsın:

• SSH için yönetim portu, mümkünse yalnızca bilinen adreslere.
• HTTP ve HTTPS için 80 ve 443 portları.
• Uygulama portu, yani örnekteki 3000, kapalı kalsın.

Güvenlik duvarı aracı dağıtıma göre değişir. Kendi dağıtımınızın belgesini izleyin ve kuralları uygulamadan önce SSH oturumunuzun kapanmayacağından emin olun. Bu adımda yanlış bir kural sizi sunucudan dışarıda bırakabilir.

Yeni sürümü sunucuya nasıl çıkarırsınız?

Güncelleme akışı kısadır: kodu çekin, bağımlılıkları kurun, gerekirse derleyin ve servisi yeniden başlatın. Her adımı elle yazmak yerine küçük bir betikte toplarsanız hata payı düşer. Üstelik her yayın aynı sırayla ilerler.

cd /srv/nodeapp/current
sudo -u nodeapp git pull --ff-only
sudo -u nodeapp npm ci --omit=dev
sudo systemctl restart nodeapp
sudo systemctl status nodeapp

Yeniden başlatma sırasında kısa bir kesinti olur. Küçük siteler için bu çoğu zaman kabul edilebilir. Kesintisiz geçiş gerekiyorsa süreç yöneticisi ya da birden çok kopya kullanmanız gerekir. PM2 yazımızda bu yaklaşımı ayrıca ele alıyoruz.

Geri dönüş planınız da hazır olsun. Her yayını etiketleyin, sorun çıkarsa önceki etikete dönün ve servisi yeniden başlatın. Veritabanı şeması değişen yayınlarda geri dönüş daha karmaşıktır. Bu durumda yedekleri önceden almak şarttır.

Yedekleme düzeni için web sitesi yedekleme stratejisi yazısına bakın.

Yayına aldıktan sonra neleri kontrol etmelisiniz?

Önce servisin ayakta olduğunu, sonra dış dünyadan yanıt verdiğini doğrulayın. Ardından günlüklerde hata olup olmadığına bakın. Son olarak hız ve güvenlik ölçümlerini alın. Bu üç kontrol, yayın sonrası sürprizlerin çoğunu yakalar.

• systemctl status nodeapp servisin çalıştığını gösterir.
• curl -I https://example.com/ komutu dış yanıtı ve başlıkları verir.
• journalctl -u nodeapp uygulama günlüklerini listeler.
• Sertifika zincirini SSL aracıyla, DNS kaydını DNS aracıyla doğrulayın.

Performans için Lighthouse ile site performans testi yapmanızı öneririz. Sonuçların arama görünürlüğüne etkisini site hızı ve SEO yazısında anlattık.

Uygulamanız sık aynı veriyi okuyorsa önbellek de yardımcı olur. Redis ve Memcached farkını önbellekleme yazımızda bulabilirsiniz.

Günlükleri ve kaynak kullanımını nasıl izlersiniz?

systemd, servisin çıktısını journal'a yazar. Ayrı bir günlük dosyası tutmanız gerekmez. journalctl -u nodeapp --since "1 hour ago" komutuyla son bir saati listelersiniz. Böylece hatanın ne zaman başladığını görürsünüz.

Bellek sızıntısı Node.js uygulamalarında sık görülen bir sorundur. Servis zamanla daha çok bellek yer ve sonunda çöker. Restart=on-failure bunu geçici olarak örter, ama nedeni çözmez. Bu yüzden yeniden başlatma sayısını da izleyin.

Basit bir izleme için dışarıdan çalışan bir çalışma süresi kontrolü kurun. Adresinizi belirli aralıklarla yoklayan ve yanıt gelmezse size haber veren bir hizmet yeterlidir. Sunucunun içinden yapılan kontrol, sunucu tamamen düşerse sizi uyarmaz.

Node.js deploy ederken en sık hangi hatalar çıkar?

En sık hatalar port uyuşmazlığı, izin sorunu ve eksik ortam değişkenidir. Çoğunda tarayıcıda 502 Bad Gateway sayfası görürsünüz. Bu hata, Nginx'in uygulamaya ulaşamadığını söyler. Nedeni genellikle uygulamanın çalışmaması ya da farklı portta dinlemesidir.

Hata ayıklarken önce günlüğe bakın. Tahmin yürütmek yerine journalctl çıktısını okuyun. Çoğu zaman cevap son birkaç satırda yazar. Hâlâ çözemiyorsanız, sorunu tek bir değişkene indirmek için servisi durdurup elle çalıştırın.

Nodejs kurulumunu ne zaman kendiniz yapmamalısınız?

Yedeksiz canlı veritabanı değişikliği, saldırı altındaki bir sunucu ya da ödeme alan bir mağaza söz konusuysa işi hosting sağlayıcınıza bırakın. Sunucu yönetimi sürekli bakım ister. Güncelleme, izleme ve olay müdahalesi için zamanınız yoksa yönetilen bir hizmet daha güvenlidir.

Biz hosting firması olmadığımız için bu yazı deneyim iddiası taşımaz. Resmi belgelere dayanır. Üretimde kritik bir uygulama işletecekseniz, sağlayıcınızdan yedekleme, izleme ve destek süresini yazılı isteyin.

Şu durumlarda sağlayıcıya ya da yönetilen platforma yönelin:

• Sunucuya her hafta güvenlik yaması uygulayacak kimse yoksa.
• Kesinti, doğrudan gelir kaybı demekse.
• Kişisel veri ya da ödeme bilgisi işliyorsanız ve uyum yükümlülükleriniz varsa.

Hosting seçimi için hosting rehberimize göz atın. Uygulamanın kendisini geliştirmek ya da devralmak isterseniz özel yazılım geliştirme hizmetimiz bu konuda destek verir.

Sonuç: Nodejs kurulumu için kısa kontrol listesi

Özetle nodejs kurulumu ve yayın akışı şöyledir: LTS sürümü kurun, kodu Git ile alın, gizli değerleri koddan ayırın, uygulamayı yalnızca yerel adreste dinletin ve dış trafiği Nginx'e bırakın. Süreklilik için systemd kullanın ve her yayından sonra günlükleri kontrol edin.

• Sunucuda root olmayan servis kullanıcısı var mı?
• Node.js sürümü Active ya da Maintenance LTS mi?
• Gizli değerler Git dışında, 600 izinli bir dosyada mı?
• Uygulama 127.0.0.1 adresinde mi dinliyor?
• nginx -t hatasız geçiyor mu?
• Servis yeniden başlatma sonrası otomatik kalkıyor mu?

Bu listeyi her yeni projede tekrar uygulayın. Tekrar ettikçe süreç sizin için rutin olur.