Node.js sebagai Runtime Aplikasi Web

PHP-FPM yang baru saja kita hubungkan ke Nginx dan Apache pada Bab 14 menangani setiap request lewat pool proses worker yang terpisah, sebuah model yang sudah terbukti matang untuk aplikasi PHP klasik seperti WordPress maupun framework seperti Laravel. Developer di banyak perusahaan sekarang juga sering meminta Sysadmin memasang jenis aplikasi web lain di server yang sama, mulai dari REST API berbasis Express sampai aplikasi real-time seperti chat atau dashboard yang memperbarui data tanpa reload halaman. Aplikasi semacam itu hampir selalu dibangun di atas Node.js, sebuah runtime JavaScript sisi server yang model eksekusinya jauh berbeda dari PHP-FPM, dan justru perbedaan itulah yang membuatnya cocok untuk beban kerja yang harus menangani banyak koneksi bersamaan.

Bab ini dimulai dengan konsep dasar Node.js, yaitu model eksekusi yang memungkinkan satu proses tunggal melayani ribuan koneksi tanpa membuka jalur eksekusi baru untuk tiap request, kontras langsung dengan pool worker PHP-FPM di Bab 14. Selanjutnya kita membandingkan empat jalur instalasi Node.js yang umum dijumpai di lapangan yaitu repository resmi Ubuntu, NodeSource, NVM, dan fnm, lengkap dengan kelebihan dan jebakan masing-masing, sebelum mempraktikkan langsung instalasi versi Long-Term Support (LTS) lewat NodeSource, instalasi multi-versi lewat NVM dan fnm, serta mengaktifkan pnpm sebagai package manager alternatif npm di setiap jalur tersebut. Bab ditutup dengan menjalankan aplikasi Node.js sebagai service systemd yang bertahan melewati reboot, mengikuti pola unit file yang sudah kita pelajari di Bab 5, sekaligus menyiapkan backend nyata yang akan dipakai saat membahas reverse proxy dan load balancing di Bab 16.

15.1 Mengenal Node.js: Event-driven dan Non-blocking I/O

Node.js adalah runtime JavaScript sisi server yang dibangun di atas engine V8, mesin yang sama yang menjalankan JavaScript di dalam Google Chrome. Kehadirannya memungkinkan kode JavaScript, yang semula hanya hidup di browser, dijalankan langsung di server untuk menangani request, mengakses filesystem, atau berkomunikasi dengan database, persis seperti peran PHP di Bab 14 maupun bahasa backend lain.

Perbedaan mendasar Node.js dari PHP-FPM terletak pada cara keduanya menangani banyak request sekaligus. PHP-FPM, seperti sudah dibahas di Bagian 14.2.2, menjalankan sejumlah proses worker dalam satu pool, dan setiap worker menangani satu request pada satu waktu sampai selesai. Node.js sebaliknya pada dasarnya berjalan sebagai satu proses tunggal per instance, dan proses itu tidak pernah berhenti menunggu satu operasi selesai sebelum menangani request lain. Model inilah yang disebut event-driven: setiap kejadian, mulai dari request HTTP masuk sampai selesainya pembacaan file, diperlakukan sebagai event yang antre diproses, bukan sebagai alur linear yang memblokir proses.

15.1.1 Single Thread, Banyak Koneksi: Cara Kerja Event Loop

Inti dari model event-driven Node.js adalah event loop, sebuah putaran tak berhenti yang terus memeriksa apakah ada event yang siap diproses. Saat kode Node.js melakukan operasi I/O seperti membaca file, mengirim query ke database, atau memanggil API eksternal, operasi tersebut diserahkan ke lapisan sistem operasi lewat pustaka internal bernama libuv, dan event loop bebas melanjutkan pekerjaan lain alih-alih diam menunggu. Begitu operasi I/O tadi selesai, hasilnya dikembalikan ke event loop dalam bentuk callback yang dieksekusi pada giliran berikutnya. Pola inilah yang disebut non-blocking I/O, dan inilah alasan satu proses Node.js tunggal sanggup melayani ribuan koneksi bersamaan tanpa membuka satu thread terpisah untuk tiap koneksi seperti pada beberapa model server tradisional.

Di lapangan, karakteristik ini membuat Node.js sangat cocok untuk aplikasi yang didominasi operasi I/O seperti REST API, proxy, aplikasi real-time berbasis WebSocket, atau layanan yang lebih banyak menunggu response dari service lain dibanding melakukan komputasi berat. Sebaliknya, proses komputasi yang benar-benar membebani CPU dalam waktu lama, misalnya pengolahan gambar resolusi tinggi atau enkripsi data dalam jumlah besar, bisa memblokir event loop dan membuat seluruh koneksi lain ikut tertunda, karena pada dasarnya hanya ada satu thread utama yang menjalankan kode JavaScript. Kasus seperti ini biasanya diatasi dengan modul worker_threads bawaan Node.js atau dengan memisahkan proses berat itu ke service lain, topik lanjutan yang berada di luar cakupan bab ini.

15.2 Metode Instalasi: Repository Ubuntu, NodeSource, NVM, dan fnm

Ada empat jalur umum untuk memasang Node.js di Ubuntu Server, dan masing-masing punya trade-off berbeda soal versi, cakupan instalasi, dan kecocokan untuk lingkungan production. Memilih jalur yang tepat sejak awal menghindarkan Sysadmin dari migrasi yang merepotkan di kemudian hari, terutama saat aplikasi Developer ternyata mensyaratkan versi Node.js tertentu, atau package manager tertentu, yang tidak tersedia lewat jalur yang sudah terlanjur dipakai.

15.2.1 Repository Resmi Ubuntu

Cara paling sederhana adalah memasang paket nodejs langsung dari repository resmi Ubuntu.

sudo apt update
sudo apt install nodejs npm

Paket nodejs di Ubuntu Server 26.04 berada di komponen universe, bukan main, dan membawa Node.js versi 22.x yang saat modul ini ditulis berstatus Maintenance LTS, bukan versi paling baru. Berbeda dari kebiasaan paket lain, npm di sini bukan dependency wajib melainkan hanya disarankan, sehingga perlu disebutkan eksplisit di perintah apt install seperti contoh di atas, atau paket nodejs saja akan terpasang tanpa npm sama sekali. Kelebihan jalur ini adalah kesederhanaan dan integrasi penuh dengan siklus update Ubuntu, termasuk unattended-upgrades dari Bab 6, tetapi versi Node.js yang didapat nyaris selalu tertinggal dari rilis resmi terbaru, dan hanya ada satu versi yang bisa terpasang system-wide dalam satu waktu.

Paket nodejs di jalur ini juga membawa dependency node-corepack, yaitu Corepack, utilitas resmi Node.js yang menjembatani ke package manager alternatif seperti pnpm dan Yarn tanpa instalasi terpisah. Karena Node.js di jalur ini terpasang system-wide di /usr/bin, mengaktifkan pnpm tetap membutuhkan sudo.

sudo corepack enable pnpm
pnpm -v

15.2.2 NodeSource sebagai Repository Pihak Ketiga

NodeSource adalah penyedia repository APT pihak ketiga yang khusus mendistribusikan paket Node.js resmi dari nodejs.org, jauh lebih cepat mengikuti rilis terbaru dibanding repository Ubuntu. NodeSource menyediakan pilihan versi mayor secara eksplisit, misalnya 22.x untuk jalur Maintenance LTS atau 24.x untuk jalur Active LTS, sehingga Sysadmin bisa memilih persis versi yang dibutuhkan aplikasi Developer. Sama seperti repository Ubuntu, hasil instalasinya tetap system-wide lewat apt, ditaruh di path standar seperti /usr/bin/node, dan paket nodejs-nya sudah otomatis menyertakan npm tanpa perlu dipasang terpisah. Kombinasi versi terkini dan path yang konsisten inilah yang membuat NodeSource menjadi pilihan paling umum untuk server production, dan menjadi jalur yang kita praktikkan di Bagian 15.3. Paket Node.js dari NodeSource juga membawa Corepack yang sama seperti repository Ubuntu, sehingga pnpm bisa diaktifkan dengan cara serupa, dipraktikkan lengkap di Bagian 15.3.3.

15.2.3 NVM sebagai Version Manager per User

NVM (Node Version Manager) mengambil pendekatan yang sama sekali berbeda, tidak memasang Node.js lewat apt, melainkan mengunduh binary Node.js langsung ke direktori .nvm di dalam home user yang menjalankannya. Satu user bisa memasang banyak versi Node.js sekaligus dan berpindah di antara versi tersebut kapan saja, bahkan mengatur versi berbeda otomatis per project lewat file .nvmrc. Pola ini sangat cocok untuk mesin Developer yang harus menguji aplikasi di beberapa versi Node.js berbeda, tetapi kurang ideal sebagai basis service production karena path binary-nya bergantung pada user dan versi yang sedang aktif, bukan path tetap seperti /usr/bin/node, konsekuensi yang perlu penanganan khusus saat dihubungkan ke systemd di Bagian 15.6.2. Corepack tetap tersedia di setiap versi Node.js yang dipasang lewat NVM, sehingga pnpm bisa diaktifkan per versi tanpa sudo, dipraktikkan di Bagian 15.4.3.

15.2.4 fnm sebagai Alternatif Ringan untuk NVM

fnm (Fast Node Manager) adalah version manager Node.js lain yang konsepnya mirip NVM, yaitu memasang banyak versi Node.js berdampingan di dalam home directory satu user, lengkap dengan dukungan file .node-version maupun .nvmrc untuk mengunci versi per project. Perbedaan utamanya ada di implementasi: fnm ditulis dalam bahasa Rust dan didistribusikan sebagai satu binary tunggal, sehingga proses inisialisasinya di setiap sesi shell baru jauh lebih cepat dibanding NVM yang ditulis sebagai kumpulan fungsi shell script. Perbedaan ini umumnya tidak terlalu terasa untuk pemakaian sehari-hari, tetapi mulai kelihatan di server dengan banyak sesi SSH pendek yang sering dibuka-tutup, atau di pipeline CI/CD yang sensitif terhadap waktu startup shell. Sisi trade-off-nya, fnm masih kalah populer dibanding NVM sehingga referensi dan troubleshooting-nya di komunitas tidak sebanyak NVM. Langkah instalasi lengkap dipraktikkan di Bagian 15.5.

15.2.5 Tabel Perbandingan dan Rekomendasi Pemakaian

Keempat jalur instalasi ini bukan saling menggantikan secara mutlak, melainkan cocok untuk skenario yang berbeda.

Rekomendasi paling umum di lapangan adalah NodeSource untuk server production yang menjalankan aplikasi sebagai service, sedangkan NVM dan fnm sama-sama cocok untuk mesin development atau staging yang perlu berpindah versi dengan cepat, tinggal disesuaikan dengan preferensi terhadap kecepatan shell atau kematangan komunitas. Bagian selanjutnya mempraktikkan instalasi lewat NodeSource, NVM, dan fnm secara berurutan, karena jalur repository Ubuntu sudah cukup lengkap dipraktikkan langsung di Bagian 15.2.1.

15.3 Instalasi Node.js LTS via NodeSource

Bagian ini memasang Node.js lewat repository NodeSource, memakai versi 24.x yang berstatus Active LTS saat modul ini ditulis. Catatan penting: nomor versi Active LTS berganti setiap sekitar setahun mengikuti jadwal rilis resmi Node.js, jadi periksa kembali halaman rilis resmi di nodejs.org untuk memastikan nomor yang masih relevan sebelum mempraktikkan langkah berikut di server sungguhan.

15.3.1 Menambahkan Repository dan GPG Key NodeSource

NodeSource mendistribusikan sebuah setup script yang mengurus penambahan GPG key dan pendaftaran repository sekaligus, sehingga langkah manual yang perlu dilakukan Sysadmin jauh lebih sedikit dibanding menambah repository pihak ketiga secara manual.

Langkah Praktik

1. Pasang dependency yang dibutuhkan proses instalasi.

   sudo apt update
   sudo apt install -y ca-certificates curl gnupg

2. Unduh setup script ke file lokal lebih dulu, bukan langsung dieksekusi lewat pipe dari curl, supaya isinya sempat diperiksa sebelum dijalankan dengan hak root, kebiasaan yang sama seperti verifikasi installer Composer di Bagian 14.5.1.

   curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh

3. Jalankan setup script dengan sudo -E. Opsi -E mempertahankan environment variable milik user yang menjalankan perintah, dibutuhkan script ini untuk mendeteksi konfigurasi proxy jaringan jika ada.

   sudo -E bash nodesource_setup.sh

   Script ini menambahkan GPG key NodeSource ke /etc/apt/keyrings/nodesource.gpg, mendaftarkan repository baru di /etc/apt/sources.list.d/nodesource.list, lalu otomatis menjalankan apt update di baliknya.
4. Pastikan repository benar-benar terdaftar.

   cat /etc/apt/sources.list.d/nodesource.list

Verifikasi dan Troubleshooting

• Jika ingin memasang versi mayor lain, misalnya 22.x yang berstatus Maintenance LTS, ganti angka pada URL setup script menjadi setup_22.x. Hindari memakai setup_lts.x untuk server production karena alias tersebut mengikuti LTS terbaru yang bisa berpindah ke versi mayor baru tanpa pemberitahuan eksplisit setiap kali script dijalankan ulang, berbeda dari menyebut angka versi secara eksplisit yang hasilnya selalu konsisten.
• Error terkait GPG atau signature yang tidak valid biasanya berarti proses unduh script terputus di tengah jalan. Hapus nodesource_setup.sh dan ulangi proses unduh dari awal.

15.3.2 Instalasi Node.js dan Verifikasi

Repository NodeSource yang sudah terdaftar di Bagian 15.3.1 membuat paket nodejs versi terbaru langsung tersedia lewat apt, menggantikan versi lama dari repository Ubuntu jika sebelumnya sempat terpasang.

Langkah Praktik

1. Pasang Node.js.

   sudo apt install -y nodejs

2. Periksa versi Node.js dan npm yang terpasang.

   node -v
   npm -v

   Berbeda dari paket nodejs di repository Ubuntu pada Bagian 15.2.1, paket dari NodeSource ini sudah membawa npm sekaligus tanpa perlu memasangnya terpisah.
3. Jalankan satu baris kode JavaScript langsung dari terminal sebagai pengujian cepat.

   node -e "console.log('Node.js siap dipakai di server ini')"

4. Catat lokasi binary Node.js, karena path ini akan dipakai langsung di konfigurasi systemd pada Bagian 15.6.2.

   which node

Verifikasi dan Troubleshooting

• Output which node seharusnya menunjukkan /usr/bin/node. Jika yang muncul justru path lain seperti /usr/local/bin/node, kemungkinan ada instalasi Node.js lain yang terpasang lebih dulu di server yang sama, misalnya lewat tarball manual, dan berpotensi bentrok.
• Paket nodejs dari NodeSource ikut ter-update otomatis lewat unattended-upgrades dari Bab 6 selama masih dalam versi mayor yang sama, tetapi berpindah ke versi mayor baru harus dilakukan manual dengan mengulang Bagian 15.3.1 memakai nomor versi yang baru.

15.3.3 Mengaktifkan pnpm Lewat Corepack

pnpm adalah package manager alternatif npm yang menyimpan seluruh dependency di satu content-addressable store terpusat lalu menghubungkannya ke tiap project lewat symlink, sehingga jauh menghemat ruang disk dan mempercepat instalasi ulang dependency dibanding npm maupun Yarn klasik, terutama di server yang menjalankan banyak project Node.js sekaligus. Sejak Node.js 14.19 hingga sebelum versi 25, Node.js resmi sudah membawa Corepack secara bawaan, utilitas resmi yang menjembatani Node.js dengan pnpm maupun Yarn tanpa perlu memasangnya manual lewat npm install -g yang rawan menghasilkan versi berbeda-beda di tiap server.

Langkah Praktik

1. Pastikan Corepack sudah tersedia bersama instalasi Node.js dari Bagian 15.3.2.

   corepack --version

2. Aktifkan shim pnpm. Karena Node.js dari NodeSource terpasang system-wide di /usr/bin, aktivasi ini membutuhkan sudo.

   sudo corepack enable pnpm

3. Verifikasi pnpm sudah bisa dipanggil.

   pnpm -v

Verifikasi dan Troubleshooting

• Percobaan pertama menjalankan pnpm biasanya memunculkan prompt Corepack is about to download..., karena Corepack baru mengunduh binary pnpm versi tertentu saat benar-benar dibutuhkan. Untuk kebutuhan automasi non-interaktif seperti script CI/CD, set environment variable COREPACK_ENABLE_DOWNLOAD_PROMPT=0 supaya proses ini berjalan tanpa menunggu konfirmasi.
• Versi pnpm per project bisa dikunci lewat field packageManager di package.json, misalnya "packageManager": "[email protected]", diatur otomatis lewat perintah corepack use pnpm@<versi> di dalam direktori project.
• Node.js 25 ke atas tidak lagi membawa Corepack secara bawaan. Jika suatu saat bermigrasi ke versi tersebut, pasang Corepack manual lebih dulu lewat sudo npm install -g corepack sebelum corepack enable pnpm di atas bisa dijalankan.

15.4 Instalasi Multi-Versi via NVM

Skenario umum yang dihadapi Sysadmin adalah Developer yang perlu menguji aplikasi lama yang masih terikat Node.js versi 22.x, sementara project lain di mesin yang sama sudah memakai versi 24.x. Bagian ini mempraktikkan instalasi NVM untuk memenuhi kebutuhan multi-versi tersebut pada user biasa, dipisahkan dari instalasi Node.js system-wide lewat NodeSource yang sudah dipasang di Bagian 15.3.

15.4.1 Instalasi NVM

Langkah Praktik

1. Jalankan install script resmi NVM sebagai user biasa, bukan root, karena NVM memang dirancang terpasang per user.

   curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.7/install.sh | bash

   Script ini meng-clone NVM ke direktori ~/.nvm, lalu menambahkan beberapa baris loader ke file profil shell seperti ~/.bashrc agar perintah nvm otomatis tersedia setiap sesi terminal baru dibuka.
2. Muat ulang profil shell tanpa perlu logout, atau buka sesi terminal baru.

   source ~/.bashrc

3. Pastikan perintah nvm sudah dikenali.

   command -v nvm

Verifikasi dan Troubleshooting

• Jika command -v nvm tidak menghasilkan apa pun, periksa apakah baris loader NVM benar-benar tertulis di ~/.bashrc, karena beberapa shell alternatif seperti fish tidak memakai file ini dan membutuhkan plugin NVM terpisah yang tidak dibahas di bab ini.
• NVM sengaja tidak dipasang dengan sudo maupun untuk user root. Instalasi ulang sebagai user berbeda di server yang sama akan menghasilkan direktori .nvm yang benar-benar terpisah satu sama lain.

15.4.2 Mengelola Beberapa Versi Node.js dengan NVM

Langkah Praktik

1. Lihat daftar versi LTS yang tersedia untuk dipasang.

   nvm ls-remote --lts

2. Pasang dua versi sekaligus sebagai simulasi kebutuhan multi-versi, versi LTS terbaru dan versi 22.x.

   nvm install --lts
   nvm install 22

3. Lihat seluruh versi yang sudah terpasang lewat NVM di user ini.

   nvm ls

4. Berpindah antar versi, lalu periksa versi yang sedang aktif setiap kali berpindah.

   nvm use 22
   node -v
   nvm use --lts
   node -v

5. Tetapkan versi default yang otomatis aktif setiap sesi terminal baru.

   nvm alias default 22

6. Buat sebuah folder project percobaan yang mengunci versi Node.js-nya sendiri lewat .nvmrc, terpisah dari versi default di atas.

   mkdir ~/demo-project && cd ~/demo-project
   echo "lts/*" > .nvmrc
   nvm use

   Perintah nvm use tanpa argumen di dalam direktori yang punya file .nvmrc otomatis membaca isi file tersebut dan berpindah ke versi yang tertulis di sana.

Verifikasi dan Troubleshooting

• Path binary Node.js yang sedang aktif lewat NVM selalu mengikuti versi terpilih dan user yang menjalankannya, misalnya ~/.nvm/versions/node/v22.x.x/bin/node, jauh berbeda dari path tetap /usr/bin/node hasil instalasi NodeSource di Bagian 15.3.2. Periksa sendiri lewat perintah berikut.

  which node

• Kedua instalasi Node.js ini, lewat NodeSource maupun NVM, bisa hidup berdampingan tanpa konflik di satu server yang sama, karena keduanya memakai path yang sama sekali berbeda dan tidak saling menimpa.
• Perbedaan path inilah yang membuat NVM membutuhkan perlakuan khusus saat aplikasinya hendak dijalankan sebagai service systemd, topik yang dibahas di Bagian 15.6.2.

15.4.3 Mengaktifkan pnpm Lewat Corepack di NVM

Corepack ikut terpasang di setiap versi Node.js yang diunduh NVM di Bagian 15.4.2, karena binary yang diunduh NVM persis sama dengan distribusi resmi dari nodejs.org. Bedanya dari Bagian 15.3.3, aktivasi di sini tidak membutuhkan sudo sama sekali, karena seluruh instalasi Node.js lewat NVM berada di dalam home directory user, bukan di direktori sistem.

Langkah Praktik

1. Pastikan versi Node.js yang ingin diaktifkan pnpm-nya sedang aktif.

   nvm current

2. Aktifkan shim pnpm untuk versi Node.js yang sedang aktif tersebut.

   corepack enable pnpm

3. Verifikasi.

   pnpm -v

Verifikasi dan Troubleshooting

• Shim pnpm ini ditaruh di dalam folder bin milik versi Node.js yang sedang aktif saat perintah dijalankan, bukan di lokasi global bersama. Setiap kali memasang versi Node.js baru lewat nvm install, ulangi corepack enable pnpm untuk versi tersebut sebelum dipakai.
• Catatan prompt download dan cara mengunci versi pnpm lewat packageManager di package.json pada Bagian 15.3.3 berlaku sama persis di sini.

15.5 Instalasi Multi-Versi via fnm

Bagian ini mempraktikkan fnm sebagai alternatif NVM yang sudah dikenalkan konsepnya di Bagian 15.2.4, cocok untuk Sysadmin atau Developer yang lebih mengutamakan kecepatan startup shell dibanding kematangan ekosistem NVM yang lebih lama.

15.5.1 Instalasi fnm

Langkah Praktik

1. Jalankan install script resmi fnm sebagai user biasa, sama seperti NVM, karena fnm juga dirancang terpasang per user.

   curl -fsSL https://fnm.vercel.app/install | bash

   Script ini mengunduh binary fnm ke ~/.local/share/fnm, lalu menambahkan baris inisialisasi ke file profil shell seperti ~/.bashrc.
2. Muat ulang profil shell, atau buka sesi terminal baru.

   source ~/.bashrc

3. Pastikan perintah fnm sudah dikenali.

   fnm --version

Verifikasi dan Troubleshooting

• Jika fnm --version tidak dikenali setelah membuka terminal baru, periksa baris inisialisasi fnm env benar-benar tertulis di ~/.bashrc, sama seperti pola troubleshooting NVM di Bagian 15.4.1.
• fnm dan NVM bisa terpasang berdampingan di user yang sama tanpa konflik, karena keduanya menyimpan binary Node.js di direktori yang sama sekali berbeda, tetapi sebaiknya hanya salah satu yang benar-benar dipakai aktif untuk menghindari kebingungan versi mana yang sedang berjalan.

15.5.2 Instalasi dan Mengelola Versi Node.js dengan fnm

Langkah Praktik

1. Pasang Node.js versi 24.x lewat fnm.

   fnm install 24

2. Periksa versi yang aktif.

   node -v

   Output-nya berupa nomor versi lengkap seperti v24.20.0, mengikuti rilis patch terbaru dari jalur Active LTS saat perintah ini dijalankan, jadi jangan heran jika angka di belakang berbeda dari contoh ini.
3. Lihat seluruh versi yang sudah terpasang lewat fnm.

   fnm list

4. Tetapkan versi default yang otomatis aktif setiap sesi terminal baru, setara nvm alias default di Bagian 15.4.2.

   fnm default 24

5. Buat file .node-version di sebuah folder project percobaan untuk mengunci versi Node.js-nya, format bawaan yang dipakai fnm.

   mkdir ~/demo-project-fnm && cd ~/demo-project-fnm
   echo "24" > .node-version
   fnm use

Verifikasi dan Troubleshooting

• fnm juga membaca file .nvmrc jika .node-version tidak ditemukan, sehingga folder project yang sebelumnya dibuat untuk NVM di Bagian 15.4.2 tetap terbaca otomatis oleh fnm tanpa perubahan apa pun.
• Fitur auto-switch versi setiap kali cd berpindah folder project tidak aktif secara default, dan baru menyala jika baris eval "$(fnm env --use-on-cd --shell bash)" ada di file profil shell, biasanya sudah otomatis ditambahkan installer resmi di Bagian 15.5.1 sesuai shell yang terdeteksi.
• Path binary Node.js yang aktif lewat fnm bisa diperiksa dengan cara yang sama seperti NVM.

  which node

15.5.3 Mengaktifkan pnpm Lewat Corepack di fnm

Sama seperti NVM, Node.js yang dipasang fnm membawa Corepack bawaan sehingga pnpm bisa diaktifkan tanpa sudo.

Langkah Praktik

1. Aktifkan shim pnpm untuk versi Node.js yang sedang aktif.

   corepack enable pnpm

2. Verifikasi.

   pnpm -v

Verifikasi dan Troubleshooting

• fnm menyediakan jalan pintas untuk menggabungkan instalasi Node.js dan aktivasi Corepack sekaligus lewat satu perintah, memakai flag --corepack-enabled saat memasang versi baru.

  fnm install 24 --corepack-enabled

• Catatan soal prompt download pnpm dan cara mengunci versi lewat packageManager di package.json pada Bagian 15.3.3 berlaku sama persis di sini.

15.6 Menjalankan Aplikasi sebagai Service dengan Systemd

Node.js yang dijalankan langsung dari terminal akan langsung mati begitu sesi SSH terputus atau server di-reboot, jelas tidak cocok untuk aplikasi yang harus tetap online. Bagian ini menerapkan pola unit file systemd yang sudah dipelajari di Bagian 5.2, kali ini disesuaikan khusus untuk aplikasi Node.js yang dipasang lewat NodeSource di Bagian 15.3, sehingga aplikasi otomatis start saat boot dan otomatis pulih sendiri jika crash.

15.6.1 Membuat Aplikasi Node.js Sederhana

Sebagai contoh, kita membuat aplikasi HTTP server kecil memakai modul http bawaan Node.js, tanpa dependency framework tambahan seperti Express, supaya fokus bab ini tetap pada konfigurasi systemd, bukan pada pengembangan aplikasinya.

Langkah Praktik

1. Siapkan direktori aplikasi.

   sudo mkdir -p /opt/demo-node

2. Buat file server.js.

   sudo nano /opt/demo-node/server.js

3. Isi dengan kode berikut.

   const http = require('http');
   const os = require('os');
   
   const port = process.env.PORT || 3000;
   
   const server = http.createServer((req, res) => {
     res.writeHead(200, { 'Content-Type': 'text/plain' });
     res.end(`Node.js aktif di ${os.hostname()}, waktu server: ${new Date().toISOString()}\n`);
   });
   
   server.listen(port, () => {
     console.log(`Server berjalan di port ${port}`);
   });

   Environment variable PORT sengaja dibaca lewat process.env alih-alih ditulis tetap di kode, supaya port bisa diatur belakangan lewat konfigurasi systemd tanpa mengubah file aplikasi sama sekali.
4. Uji jalankan langsung dari terminal untuk memastikan tidak ada error sebelum dijadikan service.

   node /opt/demo-node/server.js

5. Dari sesi terminal lain, uji dengan curl.

   curl http://localhost:3000

6. Hentikan proses manual tadi dengan Ctrl+C sebelum lanjut ke langkah berikutnya.

15.6.2 Membuat Unit Systemd untuk Aplikasi Node.js

Langkah Praktik

1. Buat user sistem khusus untuk aplikasi ini, mengikuti prinsip least privilege yang sama seperti Bagian 5.2.2.

   sudo useradd --system --no-create-home --shell /usr/sbin/nologin nodeapp

2. Samakan kepemilikan direktori aplikasi.

   sudo chown -R nodeapp:nodeapp /opt/demo-node

3. Buat file unit baru.

   sudo nano /etc/systemd/system/demo-node.service

4. Isi dengan konfigurasi berikut.

   [Unit]
   Description=Aplikasi Node.js Demo
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   Type=simple
   User=nodeapp
   Group=nodeapp
   WorkingDirectory=/opt/demo-node
   Environment=NODE_ENV=production
   Environment=PORT=3000
   ExecStart=/usr/bin/node /opt/demo-node/server.js
   Restart=on-failure
   RestartSec=5
   
   [Install]
   WantedBy=multi-user.target

   Path /usr/bin/node pada ExecStart ini persis hasil which node yang sudah kita catat di Bagian 15.3.2, hasil instalasi NodeSource yang path-nya tetap dan tidak bergantung pada user tertentu.
5. Beri tahu systemd bahwa ada unit file baru.

   sudo systemctl daemon-reload

6. Enable sekaligus jalankan service.

   sudo systemctl enable --now demo-node.service

7. Uji kembali dengan curl.

   curl http://localhost:3000

Verifikasi dan Troubleshooting

• Periksa status service beserta beberapa baris log terakhir.

  systemctl status demo-node.service

• Ikuti log aplikasi secara langsung, termasuk baris console.log dari kode Node.js yang otomatis tertangkap journalctl tanpa konfigurasi logging tambahan, persis seperti aplikasi Python di Bagian 5.2.2.

  journalctl -u demo-node.service -f

• Error Address already in use di log biasanya berarti proses manual dari Bagian 15.6.1 belum benar-benar dihentikan sebelum service diaktifkan. Periksa proses yang masih menempati port tersebut.

  ss -tlnp | grep 3000

• Kesalahan paling umum ketika aplikasi Node.js dipasang lewat NVM atau fnm alih-alih NodeSource adalah mengisi ExecStart hanya dengan node tanpa path lengkap, mengandalkan PATH yang biasa aktif di sesi shell interaktif. Systemd menjalankan service tanpa pernah memuat shell login maupun fungsi nvm atau fnm di ~/.bashrc, sehingga service akan langsung gagal dengan pesan node: command not found meskipun perintah node terbukti berjalan normal saat dicoba manual login sebagai user yang sama. Jika memang harus memakai Node.js dari NVM atau fnm sebagai basis service, ExecStart wajib diisi path lengkap ke binary versi spesifik, misalnya /home/deploy/.nvm/versions/node/v22.x.x/bin/node, hasil pencarian lewat nvm which 22 saat login sebagai user pemilik instalasi tersebut. Inilah alasan utama NodeSource lebih disarankan untuk basis service production dibanding NVM maupun fnm, konsisten dengan catatan trade-off di tabel Bagian 15.2.5.
• Jika aplikasi sungguhan memakai dependency npm pihak ketiga yang dipasang lewat pnpm dari Bagian 15.3.3, 15.4.3, atau 15.5.3, konfigurasi unit file ini tidak perlu berubah sama sekali. Cukup jalankan pnpm install --prod di WorkingDirectory sebelum service pertama kali dijalankan, atau setiap kali deployment versi baru, karena ExecStart di atas tetap memanggil node langsung, bukan lewat pnpm.

Node.js yang sudah berjalan sebagai service systemd ini pada dasarnya adalah backend aplikasi biasa yang mendengarkan satu port, sama seperti PHP-FPM di Bab 14 maupun aplikasi lain yang menjalankan HTTP server sendiri. Bab 16 melanjutkan dengan reverse proxy dan load balancing, memperlakukan backend seperti ini, baik Node.js, PHP-FPM, maupun aplikasi lain, sebagai bagian dari upstream yang bisa diperbanyak dan didistribusikan traffic-nya lewat Nginx.