From Localhost to Live LMS

Apa itu VPS untuk LMS

Sebelum LMS kita bisa diakses banyak orang melalui internet, aplikasi itu membutuhkan rumah online. Rumah online itulah yang dalam course ini kita sebut sebagai VPS atau Virtual Private Server.

Kalau saat ini LMS kita berjalan di localhost, artinya aplikasi hanya hidup di komputer kita sendiri. Orang lain tidak bisa membukanya dari internet. Begitu kita ingin LMS menjadi live, bisa diakses lewat domain, aktif 24 jam, dan stabil sebagai environment production, kita perlu memindahkan aplikasi itu ke server.

Definisi sederhana

VPS adalah komputer virtual yang berjalan di data center dan bisa kita sewa. Walaupun bentuknya virtual, fungsinya mirip seperti komputer Linux sungguhan: kita bisa login, install software, membuat folder project, menjalankan aplikasi, membuka port tertentu, dan menghubungkannya ke domain.

Di course ini, VPS yang kita pakai menggunakan Ubuntu 22.04, lalu dari Windows kita mengaksesnya memakai PuTTY melalui koneksi SSH.

Kenapa LMS butuh VPS?

• Agar online 24 jam — LMS tidak lagi bergantung pada laptop atau PC lokal kita.
• Agar bisa diakses publik — learner bisa membuka LMS dari browser lewat IP atau domain.
• Agar siap production — kita bisa menambahkan Nginx, SSL, PM2, firewall, dan optimasi server.
• Agar lebih terstruktur — pemisahan jelas antara environment development di localhost dan environment live di server.

Bedanya localhost dan VPS

Analogi yang paling mudah

Bayangkan LMS kita seperti toko.

• Localhost = toko masih di dalam rumah sendiri. Kita bisa lihat, kita bisa coba, tetapi orang lain tidak bisa datang bebas.
• VPS = kita pindahkan toko ke ruko yang memang menghadap jalan umum. Orang bisa datang, alamatnya jelas, dan toko bisa buka terus.

Apa saja yang nanti berjalan di VPS ini?

VPS bukan hanya tempat menyimpan file. VPS akan menjadi tempat untuk menjalankan seluruh stack deployment kita, misalnya:

• Node.js untuk menjalankan aplikasi LMS berbasis Next.js.
• Nginx sebagai web server dan reverse proxy.
• SSL agar domain LMS aman dengan HTTPS.
• PM2 agar aplikasi tetap hidup walau terminal ditutup atau server reboot.
• Firewall dan hardening agar server lebih aman saat dibuka ke internet.

Apakah semua website harus pakai VPS?

Tidak selalu. Tetapi untuk course ini, memakai VPS sangat tepat karena kita ingin belajar workflow production yang nyata: login ke server, setup Ubuntu, deploy app, hubungkan domain, pasang SSL, dan memelihara aplikasi live. Jadi bukan sekadar teori hosting, tetapi benar-benar membangun pengalaman deploy yang real.

Apa yang akan kita lakukan setelah memahami VPS?

Setelah lesson ini, kita akan masuk ke langkah yang lebih praktis:

1. Memahami kenapa kita memilih Ubuntu 22.04.
2. Login ke VPS memakai PuTTY.
3. Melakukan login pertama sebagai root.
4. Update package Ubuntu.
5. Membuat user deploy non-root.
6. Menyiapkan folder project LMS di server.

Mindset penting sebelum lanjut

Mulai dari titik ini, kita perlu membedakan dua dunia kerja:

• Local development — tempat kita coding, testing, dan memperbaiki bug di komputer sendiri.
• Live server / VPS — tempat aplikasi yang sudah siap dijalankan untuk diakses publik.

Jadi singkatnya: VPS adalah rumah online untuk LMS kita. Tanpa VPS atau server sejenis, LMS tetap hanya menjadi project lokal. Dengan VPS, LMS mulai berubah menjadi aplikasi sungguhan yang siap dibuka lewat internet.

Kesimpulan lesson ini

Kalau localhost adalah tempat kita membangun LMS, maka VPS adalah tempat kita menjalankan LMS secara live.

Di lesson berikutnya, kita akan mulai dari fondasi paling aman dan stabil: mengapa kita memilih Ubuntu 22.04 sebagai sistem operasi server.

Memilih Ubuntu 22.04

Setelah kita memahami apa itu VPS, pertanyaan berikutnya adalah: sistem operasi apa yang paling aman dan nyaman untuk mulai belajar deployment LMS?

Di course ini, kita memilih Ubuntu 22.04 LTS. Bukan karena Ubuntu adalah satu-satunya pilihan, tetapi karena Ubuntu 22.04 memberi kombinasi yang sangat baik antara stabilitas, dokumentasi, kemudahan belajar, dan kesiapan production.

Apa arti Ubuntu 22.04 LTS?

Ubuntu adalah distribusi Linux yang sangat populer untuk server. Angka 22.04 menunjukkan versi rilisnya. Sedangkan LTS berarti Long Term Support, yaitu versi yang didukung dalam jangka panjang dan cocok untuk server yang ingin kita pakai dengan tenang tanpa terlalu sering pindah versi.

Untuk learner yang baru mulai belajar VPS, memilih versi LTS adalah langkah yang bijak karena fokus kita bukan mengejar versi paling baru, tetapi membangun server yang stabil, konsisten, dan mudah dirawat.

Kenapa bukan OS lain dulu?

Sebenarnya ada banyak pilihan lain seperti Debian, Rocky Linux, AlmaLinux, atau bahkan distro yang lebih minimal. Tetapi untuk kebutuhan course ini, Ubuntu 22.04 lebih cocok karena:

• Lebih ramah pemula — banyak tutorial, dokumentasi, dan contoh command yang mudah ditemukan.
• Ekosistem luas — sangat umum dipakai untuk Node.js, Nginx, SSL, Git, PM2, dan berbagai workflow deployment web app.
• Komunitas besar — kalau nanti kita menemui error, kemungkinan besar solusi atau pembahasannya sudah banyak tersedia.
• Cocok untuk production — bukan hanya bagus untuk belajar, tetapi juga sangat layak dipakai untuk website live sungguhan.

Kenapa Ubuntu 22.04 cocok untuk LMS kita?

LMS frontend yang sedang kita bangun berjalan dengan stack yang sangat cocok di Ubuntu 22.04. Nanti di VPS ini kita akan memasang beberapa komponen penting:

• Node.js untuk menjalankan aplikasi Next.js.
• Nginx sebagai reverse proxy dan web server.
• Certbot + SSL untuk mengaktifkan HTTPS.
• PM2 untuk menjaga aplikasi tetap berjalan di background.
• UFW dan Fail2Ban untuk lapisan keamanan dasar.

Ubuntu 22.04 sangat nyaman untuk semua kebutuhan tersebut karena package management-nya jelas, workflow install-nya rapi, dan command-command Linux server dasarnya sangat umum dipakai.

Keuntungan belajar di Ubuntu 22.04

1. Perintah Linux yang kita pelajari relevan
   Apa yang kita pelajari di sini akan berguna lagi saat nanti menangani VPS lain, server staging, atau project production lain.
2. Lebih mudah mengikuti course langkah demi langkah
   Karena kita menyamakan OS, maka instruksi instalasi, lokasi file konfigurasi, dan pola troubleshooting menjadi lebih konsisten.
3. Minim kejutan untuk pemula
   Semakin banyak perbedaan OS, semakin besar peluang bingung di tengah jalan. Dengan Ubuntu 22.04, kita menurunkan kompleksitas awal.
4. Lebih mudah saat terjadi error nyata
   Karena course ini adalah living course, saat muncul error nyata di VPS, materi bisa kita update dengan lebih konsisten jika fondasi OS-nya sama.

Stabilitas lebih penting daripada sekadar terbaru

Dalam dunia server, versi paling baru belum tentu pilihan terbaik untuk belajar deployment dasar. Untuk LMS yang ingin kita jalankan live, yang lebih penting adalah:

• mudah di-maintain,
• kompatibel dengan dependency umum,
• tidak sering berubah drastis,
• dan punya dokumentasi yang matang.

Itulah sebabnya Ubuntu 22.04 LTS terasa sangat pas: cukup modern, tetapi tetap stabil.

Analogi sederhananya

Kalau VPS adalah rumah online untuk LMS kita, maka Ubuntu 22.04 adalah pondasi dan tata ruang rumah itu. Kita ingin pondasi yang kuat, layout yang mudah dipahami, dan lingkungan yang tidak bikin kita repot setiap saat. Jadi sebelum kita isi rumah itu dengan Node.js, Nginx, SSL, dan PM2, kita pastikan dulu pondasinya memang nyaman dipakai.

Apa yang akan kita rasakan nanti saat memakai Ubuntu 22.04?

Saat kita mulai login ke server dan menjalankan command satu per satu, kita akan melihat bahwa banyak langkah deployment di Ubuntu cukup natural, misalnya:

sudo apt update
sudo apt upgrade -y
sudo apt install nginx -y

Model kerja seperti ini sangat cocok untuk belajar VPS karena kita jadi memahami server secara bertahap, bukan hanya klik-klik tanpa tahu apa yang sebenarnya terjadi.

Kesesuaian dengan course ini

Course From Localhost to Live LMS dirancang agar mengikuti pengalaman nyata deployment di VPS Ubuntu 22.04 dari Windows menggunakan PuTTY. Jadi pemilihan Ubuntu 22.04 bukan hanya teori, tetapi memang selaras dengan alur berikutnya:

1. Login ke VPS
2. Update package
3. Membuat user deploy
4. Install Node.js dan Nginx
5. Menjalankan LMS
6. Menghubungkan domain dan SSL
7. Menjaga aplikasi tetap hidup dengan PM2

Kesimpulan lesson ini

Ubuntu 22.04 dipilih karena stabil, populer, mudah dipelajari, dan sangat cocok untuk deployment LMS berbasis Node.js.

Dengan kata lain, Ubuntu 22.04 memberi kita fondasi server yang cukup profesional untuk production, tetapi tetap nyaman untuk learner yang baru mulai mengenal VPS.

Di lesson berikutnya, kita akan masuk ke hal yang lebih praktis: bagaimana mengakses server Ubuntu VPS dari Windows menggunakan PuTTY.

Akses server dengan PuTTY

Dari Windows, kita bisa memakai PuTTY untuk login ke VPS melalui SSH. Pastikan kita memiliki IP VPS, username, password atau private key, serta port SSH yang benar.

Apa yang harus diisi di PuTTY Configuration?

Sebelum klik tombol Open, perhatikan beberapa field penting di layar konfigurasi PuTTY berikut:

• Host Name (or IP address) → isi dengan IP public VPS Anda.
• Port → biasanya 22 jika masih memakai port SSH default.
• Connection type → pilih SSH.

Contoh tampilan awal PuTTY Configuration. Masukkan IP VPS pada Host Name, pastikan Port benar, lalu pilih SSH sebelum klik Open.

Urutan login singkat

1. Buka aplikasi PuTTY.
2. Masukkan IP VPS pada field Host Name (or IP address).
3. Pastikan Port sesuai, biasanya 22.
4. Pilih SSH pada Connection type.
5. Klik Open.
6. Masukkan username server, biasanya root untuk login pertama.
7. Masukkan password server saat diminta.

Jika semua benar, Anda akan masuk ke terminal Ubuntu VPS dan siap menjalankan command Linux dari Windows.

Menyimpan session di PuTTY agar tidak ketik IP berulang kali

Selain dipakai untuk login manual, PuTTY juga punya fitur built-in yang sangat membantu, yaitu Saved Sessions. Fitur ini memungkinkan kita menyimpan konfigurasi koneksi server, sehingga pada login berikutnya kita tidak perlu mengetik ulang IP, port, atau setting lain dari awal.

Untuk workflow LMS seperti course ini, fitur Saved Sessions sangat berguna karena kita akan berkali-kali masuk ke VPS yang sama.

Tutorial step-by-step menyimpan host di PuTTY

1. Buka PuTTY
   Jalankan aplikasi PuTTY seperti biasa sampai muncul layar PuTTY Configuration.
2. Isi Host Name / IP Address
   Pada bagian Host Name (or IP address), isi dengan IP VPS Anda, misalnya 103.xxx.xxx.xxx.
3. Pastikan port benar
   Biarkan port default 22 jika masih memakai SSH standar.
4. Beri nama session
   Pada bagian Saved Sessions, isi nama bebas yang mudah diingat, misalnya VPS-LMS, Server-Odoo, atau Production-Server.
5. Klik tombol Save
   Setelah nama session diisi, klik Save. Jika berhasil, nama session akan muncul di daftar bawahnya.

Cara menggunakan kembali session yang sudah disimpan

Saat nanti Anda ingin login lagi ke server yang sama, langkahnya jauh lebih cepat:

1. Buka PuTTY.
2. Klik nama session yang sudah tersimpan, misalnya VPS-LMS.
3. Klik tombol Load.
4. Klik tombol Open.

Dengan cara ini, Anda tidak perlu mengetik IP VPS lagi setiap kali ingin masuk ke server.

Tips pro: simpan username juga

Kalau ingin lebih nyaman, Anda bisa menyimpan username default di session yang sama.

1. Buka menu Connection > Data.
2. Isi field Auto-login username dengan username server, misalnya root atau deploy.
3. Kembali ke menu Session.
4. Pilih nama session Anda.
5. Klik Save lagi.

Setelah itu, PuTTY akan otomatis menyiapkan username saat session dibuka.

Tips pro: simpan private key jika memakai SSH key

Kalau server Anda memakai SSH key, session PuTTY juga bisa menyimpan referensi file private key.

1. Buka menu Connection > SSH > Auth.
2. Load file private key .ppk.
3. Kembali ke menu Session.
4. Pilih nama session Anda.
5. Klik Save lagi.

Dengan begitu, session PuTTY Anda menjadi lebih lengkap dan siap dipakai ulang.

Kalau ingin mengubah atau update session

Kalau suatu saat Anda ingin mengubah nama host, port, username, atau key, Anda tidak perlu membuat session baru dari nol. Cukup:

1. Pilih session yang sudah ada
2. Klik Load
3. Lakukan perubahan yang diperlukan
4. Klik Save lagi

Ini akan menimpa session lama dengan konfigurasi terbaru.

Insight penting tentang Saved Sessions

Saved Sessions di PuTTY sangat membantu karena:

• lebih cepat untuk workflow harian,
• mengurangi risiko salah ketik IP atau port,
• tetap tersimpan walaupun Windows direstart,
• dan sangat cocok untuk server yang sering diakses seperti VPS LMS.

Secara umum, konfigurasi ini tersimpan di Windows. Jadi session tetap ada setelah restart, tetapi tidak otomatis ikut pindah ke PC lain.

Contoh nama session yang rapi

• VPS-LMS
• LMS-Production
• Ubuntu-LMS-Deploy

Pakai nama yang jelas agar nanti Anda tidak bingung saat punya lebih dari satu server.

Rekomendasi untuk course ini

Untuk project From Localhost to Live LMS, sangat disarankan Anda langsung menyimpan session PuTTY dengan nama seperti VPS-LMS. Session ini nanti akan terus dipakai saat update package, membuat user deploy, install Nginx, setup SSL, sampai menjalankan PM2.

Kesimpulan lesson ini

PuTTY bukan hanya dipakai untuk login sekali lalu selesai. Dengan fitur Saved Sessions, workflow akses VPS menjadi jauh lebih rapi, cepat, dan nyaman. Jadi setelah berhasil login pertama, biasakan langsung simpan session agar pekerjaan deploy LMS terasa lebih smooth.

Login pertama sebagai root

Setelah berhasil masuk ke VPS melalui PuTTY, biasanya kita akan login pertama kali menggunakan user root. Ini adalah user dengan hak akses tertinggi di server. Artinya, root bisa melakukan hampir semua hal: install software, mengubah konfigurasi sistem, membuat user baru, menghapus file penting, bahkan membuat server tidak bisa dipakai kalau salah langkah.

Karena itu, login pertama sebagai root adalah momen yang sangat penting. Di tahap ini, kita belum hanya belajar masuk ke server, tetapi juga mulai memahami bahwa akses root adalah akses yang sangat powerful dan harus dijaga dengan serius.

Apa itu user root?

Root adalah administrator utama di Linux. Kalau diibaratkan, root adalah pemegang kunci master seluruh bangunan server. Tidak ada area yang tertutup bagi root.

Itulah sebabnya login root biasanya dipakai hanya untuk setup awal, lalu setelah itu kita akan membuat user deploy non-root agar operasional harian lebih aman.

Tampilan setelah login root berhasil

Kalau login berhasil, biasanya terminal akan menampilkan prompt seperti ini:

root@your-server:~#

Tanda # di akhir prompt biasanya menunjukkan bahwa kita sedang berada di user root.

Checklist yang perlu dicek setelah login pertama

Begitu berhasil masuk, jangan langsung install macam-macam. Lakukan pengecekan dasar terlebih dahulu agar kita tahu kondisi awal server.

1. Cek user aktif

   whoami

   Hasilnya seharusnya root.

2. Cek hostname server

   hostname

   Ini membantu kita mengenali identitas server.

3. Cek versi Ubuntu

   lsb_release -a

   Pastikan benar menggunakan Ubuntu 22.04 sesuai course ini.

4. Cek IP server

   ip a

   Gunakan ini untuk melihat interface jaringan dan memastikan server punya IP yang sesuai.

5. Cek waktu server

   date

   Jam server yang salah bisa berpengaruh ke log, SSL, dan troubleshooting nanti.

6. Test update package list

   apt update

   Kalau command ini berjalan normal, berarti server bisa terkoneksi ke repository package Ubuntu.

Hal paling penting: jangan sampai lupa password root

Pada login pertama ini, ada satu hal yang harus benar-benar diberi perhatian: jangan sampai lupa password root.

Password root adalah salah satu akses paling penting ke server. Kalau Anda lupa password ini, maka situasinya bisa sangat merepotkan, apalagi kalau:

• Anda belum membuat user deploy non-root,
• Anda belum memasang SSH key cadangan,
• Anda belum punya akses console recovery dari provider VPS,
• dan server sudah telanjur dipakai untuk deployment.

Di mana sebaiknya menyimpan password root?

Gunakan tempat penyimpanan yang aman dan terorganisir, misalnya:

• password manager terpercaya,
• catatan terenkripsi,
• atau dokumen internal yang benar-benar aman dan hanya bisa diakses pihak yang berwenang.

Jangan menyimpan password root sembarangan di chat, sticky note, atau file teks terbuka di desktop.

Risiko jika lupa password root

Kalau password root hilang, beberapa risiko yang bisa terjadi adalah:

1. Tidak bisa login ke server
   Anda bisa terkunci dari VPS, terutama jika root adalah satu-satunya akun yang masih aktif dan belum ada user lain yang punya hak sudo.
2. Proses setup tertunda
   Deployment LMS tidak bisa dilanjutkan karena Anda tidak punya akses administratif ke server.
3. Harus melakukan reset password
   Ini bisa butuh prosedur tambahan melalui panel provider VPS, recovery mode, rescue mode, atau console khusus.
4. Berisiko salah recovery
   Kalau belum terbiasa, proses reset password root bisa membingungkan dan berisiko menambah masalah baru.
5. Dalam kasus tertentu bisa berujung reinstall server
   Kalau akses benar-benar hilang dan tidak ada jalur recovery yang praktis, kadang solusi paling cepat justru membangun ulang VPS dari awal.

Mindset yang benar tentang root

Root itu penting, tetapi root bukan user yang ideal untuk dipakai kerja harian. Karena itulah setelah login pertama ini, langkah berikutnya dalam course adalah membuat user deploy non-root. Root dipakai secukupnya untuk setup awal dan keadaan darurat.

Apa yang sebaiknya dilakukan segera setelah login root?

• Pastikan password root tersimpan aman.
• Lakukan pengecekan dasar server.
• Jalankan update package.
• Siapkan pembuatan user deploy non-root.

Dengan urutan ini, kita membangun server dengan lebih rapi dan mengurangi risiko salah langkah di awal.

Kesimpulan lesson ini

Login pertama sebagai root adalah pintu masuk administratif ke VPS. Gunakan momen ini untuk memastikan server sehat, identitas server jelas, koneksi package normal, dan yang paling penting: password root tersimpan aman dan tidak akan hilang.

Di lesson berikutnya, kita akan lanjut ke langkah praktis berikutnya yaitu update package Ubuntu sebelum instalasi software lain dimulai.

Mengganti Hostname Server (Best Practice)

Setelah berhasil login pertama sebagai root, ada satu hal kecil tetapi penting yang sebaiknya kita rapikan sejak awal: hostname server.

Pada banyak VPS baru, hostname bawaan sering masih mengikuti nama default dari provider atau image sistem, misalnya:

ip-172-31-xxx-xxx

Secara teknis ini tidak selalu salah, tetapi untuk workflow deployment LMS, nama seperti itu terasa kurang nyaman dibaca, kurang profesional, dan bisa membingungkan saat nanti kita mengelola lebih dari satu server.

Apa itu hostname?

Hostname adalah nama identitas server di dalam sistem Linux. Nama ini sering muncul di terminal prompt, log, dan beberapa konfigurasi sistem. Dengan hostname yang jelas, kita lebih mudah mengenali server yang sedang dipakai.

Tujuan mengganti hostname

Mengganti hostname bukan sekadar kosmetik. Tujuannya cukup penting untuk workflow server yang rapi.

• Membuat identitas server lebih jelas — tidak lagi memakai nama default provider.
• Membuat terminal lebih clean — prompt menjadi lebih mudah dibaca.
• Membedakan environment — misalnya lms-dev, lms-staging, dan lms-prod.
• Mengurangi kebingungan saat mengelola banyak server — terutama kalau nanti ada beberapa VPS.
• Membentuk production mindset — server tidak hanya hidup, tetapi juga dikelola dengan identitas yang rapi.

Contoh sebelum dan sesudah

Sebelum diganti, prompt terminal bisa terlihat seperti ini:

deploy@ip-172-31-xxx-xxx:~$

Setelah diganti, tampilannya bisa menjadi seperti ini:

deploy@lms-prod:~$

Tampilan ini jauh lebih bersih dan lebih mudah dikenali.

Best practice penamaan hostname

Pilih nama yang singkat, jelas, dan relevan dengan fungsi server.

Contoh yang rapi:

• lms-dev
• lms-staging
• lms-prod
• odoo-prod
• campusone-app

Usahakan hostname:

• menggunakan huruf kecil,
• menggunakan tanda minus - jika perlu,
• tidak memakai spasi,
• dan tetap mudah dibaca.

Langkah 1: lihat hostname yang aktif saat ini

Sebelum mengganti, lihat dulu hostname server saat ini:

hostname

Command ini menampilkan hostname aktif secara singkat.

Kalau ingin melihat informasi yang lebih lengkap, gunakan:

hostnamectl

Command ini biasanya menampilkan beberapa informasi penting, misalnya:

 Static hostname: ip-172-31-xxx-xxx
       Icon name: computer-vm
         Chassis: vm
      Machine ID: xxxxx
         Boot ID: xxxxx
  Virtualization: kvm
Operating System: Ubuntu 22.04 LTS
          Kernel: Linux 5.x.x
    Architecture: x86-64

Apa yang perlu diperhatikan dari output hostnamectl?

Fokus utama kita ada pada bagian:

• Static hostname — ini adalah hostname utama yang disimpan permanen oleh sistem.
• Operating System — membantu memastikan kita memang sedang bekerja di server Ubuntu yang benar.
• Kernel dan Architecture — bukan inti lesson ini, tetapi bagus untuk dikenali sejak awal.

Untuk kebutuhan course ini, indikator terpenting adalah Static hostname.

Apakah ada status hostname?

Dalam praktik dasar Ubuntu, yang paling sering kita lihat dari hostnamectl adalah Static hostname. Pada sebagian konfigurasi Linux, kita juga bisa mengenal istilah berikut:

• Static hostname — hostname permanen yang disimpan oleh sistem.
• Transient hostname — hostname sementara yang bisa datang dari network atau DHCP.
• Pretty hostname — nama yang lebih human-friendly untuk tampilan tertentu.

Namun untuk server Ubuntu yang kita kelola di course ini, fokus utamanya tetap pada Static hostname, karena itulah identitas inti server yang kita ubah.

Langkah 2: ganti hostname dengan hostnamectl

Di Ubuntu 22.04, cara yang paling rapi untuk mengganti hostname adalah memakai:

sudo hostnamectl set-hostname lms-prod

Pada contoh ini, kita mengganti hostname menjadi lms-prod. Silakan sesuaikan dengan kebutuhan server Anda.

Kalau saat ini Anda masih login sebagai root, command di atas tetap aman dipakai. Kalau nanti Anda sudah memakai user lain yang punya sudo, polanya juga tetap sama.

Langkah 3: lihat apa yang sudah berubah

Setelah menjalankan command di atas, cek kembali:

hostnamectl

Kalau berhasil, bagian berikut seharusnya berubah:

Static hostname: lms-prod

Anda juga bisa melakukan cek cepat:

hostname

Kalau output command ini sudah menunjukkan lms-prod, berarti hostname aktif sudah berubah.

Langkah 4: cek file yang ikut terkait

Kalau ingin melihat apa yang tersimpan di file hostname sistem, jalankan:

cat /etc/hostname

Output yang diharapkan:

lms-prod

Ini membantu kita melihat bahwa nama hostname baru memang sudah tercatat di sistem.

Langkah 5: sesuaikan file /etc/hosts

Setelah hostname diganti, best practice berikutnya adalah memastikan file /etc/hosts ikut diperbarui agar mapping nama lokal server tetap konsisten.

Buka file-nya dengan editor terminal:

sudo nano /etc/hosts

Cari baris yang biasanya mirip seperti ini:

127.0.1.1   old-hostname

Lalu ubah menjadi:

127.0.1.1   lms-prod

Simpan perubahan tersebut.

Kalau Anda memakai nano, biasanya urutannya:

1. Tekan Ctrl + O untuk save
2. Tekan Enter untuk konfirmasi
3. Tekan Ctrl + X untuk keluar

Kenapa /etc/hosts ikut diedit?

Karena file ini membantu sistem mengenali nama lokal server sendiri. Kalau hostname berubah tetapi file /etc/hosts tidak ikut disesuaikan, kadang bisa muncul perilaku yang membingungkan pada sebagian tool, prompt, atau resolusi nama lokal.

Jadi meskipun mengganti hostname lewat hostnamectl sudah langkah utama, mengupdate /etc/hosts adalah langkah pelengkap yang sangat disarankan.

Langkah 6: lihat apa yang sudah diganti di /etc/hosts

Untuk memastikan file hosts sudah sesuai, Anda bisa cek dengan:

cat /etc/hosts

Pastikan baris hostname lokal sudah menunjukkan nama baru, misalnya:

127.0.1.1   lms-prod

Langkah 7: logout lalu login ulang

Supaya perubahan lebih terasa di tampilan terminal, keluar dulu dari sesi saat ini:

exit

Lalu login kembali ke server melalui PuTTY.

Kalau semua berhasil, prompt terminal biasanya akan berubah menjadi lebih rapi, misalnya:

deploy@lms-prod:~$

Kenapa perlu login ulang?

Walaupun hostname biasanya sudah berubah segera setelah command dijalankan, session terminal yang sedang aktif belum tentu langsung memperlihatkan tampilan prompt yang baru. Karena itu, logout lalu login ulang adalah cara paling mudah untuk memastikan perubahan terlihat jelas.

Apakah mengganti hostname wajib?

Jawaban jujurnya: tidak selalu wajib untuk membuat server bisa berjalan.

Tanpa mengganti hostname, server tetap bisa dipakai untuk install Node.js, Nginx, PM2, SSL, dan menjalankan LMS. Jadi ini bukan syarat mutlak agar deployment berhasil.

Namun, untuk workflow yang lebih rapi dan mindset production, mengganti hostname sangat direkomendasikan.

Risiko kalau hostname dibiarkan default

• Terminal terasa kurang nyaman dibaca karena nama server terlalu teknis.
• Lebih mudah bingung jika nanti Anda mengelola beberapa VPS.
• Kurang profesional saat dilihat dalam demo, tutorial, screenshot, atau dokumentasi.
• Kurang selaras dengan environment karena nama server tidak mencerminkan fungsi sebenarnya.

Contoh alur lengkap yang aman

hostname
hostnamectl
sudo hostnamectl set-hostname lms-prod
hostnamectl
cat /etc/hostname
sudo nano /etc/hosts
cat /etc/hosts
exit

Kesimpulan lesson ini

Mengganti hostname bukan langkah yang membuat server hidup, tetapi langkah yang membuat server terasa lebih rapi, jelas, dan profesional.

Yang perlu kita pahami bukan hanya cara menggantinya, tetapi juga cara melihat apa yang sudah berubah: melalui hostname, hostnamectl, /etc/hostname, /etc/hosts, dan tampilan prompt setelah login ulang.

Dengan begitu, kita tidak hanya menjalankan command, tetapi benar-benar mengerti hasil perubahan yang terjadi di server.

Di lesson berikutnya, kita akan lanjut ke kebiasaan penting berikutnya yaitu update package Ubuntu sebelum menginstall software lain.

Update package Ubuntu

Sebelum kita menginstall software apa pun di VPS Ubuntu, ada satu kebiasaan penting yang harus dibangun dari awal: cek dan update package list terlebih dahulu.

Di Ubuntu, kita biasanya memakai command berikut:

sudo apt update && sudo apt upgrade -y

Command ini sangat umum, tetapi pemula sering belum benar-benar paham bedanya apt update dan apt upgrade. Padahal memahami dua command ini penting supaya kita tahu kapan harus menjalankannya dan kapan tidak perlu berlebihan.

Apa itu apt update?

apt update tidak langsung mengupdate software yang terpasang. Command ini berfungsi untuk mengambil informasi terbaru tentang package dari repository Ubuntu.

Sederhananya, apt update adalah proses refresh daftar paket. Jadi server Anda diberi tahu: versi terbaru package apa saja yang tersedia saat ini.

Apa itu apt upgrade?

Kalau apt update hanya menyegarkan daftar, maka apt upgrade baru benar-benar menginstall versi terbaru dari package yang sudah ada di server, selama upgrade itu aman dilakukan tanpa menghapus package lain.

Jadi urutan logikanya seperti ini:

1. apt update = ambil info terbaru
2. apt upgrade = pasang update yang tersedia

Kenapa ini penting sebelum install software?

Karena saat kita mau install software seperti Nginx, Node.js, Git, UFW, atau Fail2Ban, kita ingin server membaca repository terbaru, bukan data lama yang mungkin sudah kadaluarsa.

Kalau package list terlalu lama, beberapa hal bisa terjadi:

• server tidak menemukan package tertentu,
• versi package yang diambil bukan yang terbaru dari repository saat itu,
• muncul error dependency atau metadata lama,
• dan proses install jadi membingungkan untuk pemula.

Apakah setiap mau install sesuatu harus apt update lagi?

Jawaban singkatnya: tidak harus setiap beberapa menit, tetapi cukup sering dan masuk akal.

Yang perlu dipahami adalah apt update itu seperti menyegarkan katalog. Kalau baru saja Anda menjalankannya, lalu beberapa menit kemudian mau install package lain, biasanya tidak perlu update lagi.

Contohnya:

sudo apt update
sudo apt upgrade -y
sudo apt install nginx -y
sudo apt install git -y

Pada contoh di atas, setelah Anda baru saja menjalankan apt update, lalu langsung install nginx dan git di sesi kerja yang sama, maka tidak perlu menjalankan apt update berulang-ulang sebelum setiap install.

Kalau sudah update, sudah install sesuatu, lalu mau install yang lain, perlu update lagi?

Tergantung jarak waktunya.

• Kalau masih dalam sesi setup yang sama, misalnya selang beberapa menit atau beberapa command, biasanya tidak perlu.
• Kalau sudah cukup lama, misalnya beberapa jam, besok, atau beberapa hari kemudian, lebih baik jalankan apt update lagi sebelum install package berikutnya.

Jadi bukan aturan kaku “setiap install harus update”, tetapi lebih ke prinsip: jalankan apt update saat package list kemungkinan sudah tidak fresh lagi.

Apakah cukup 1 kali per hari?

Untuk workflow belajar dan setup VPS seperti di course ini, pendekatan 1 kali di awal sesi kerja itu sudah sangat baik.

Misalnya hari ini Anda mau setup server selama 1 jam. Maka pola yang aman:

1. Login ke VPS
2. Jalankan sudo apt update
3. Kalau ada pembaruan penting, jalankan sudo apt upgrade -y
4. Lanjut install package-package yang dibutuhkan dalam sesi itu

Kalau nanti malam Anda login lagi untuk install hal lain, tidak masalah menjalankan apt update lagi. Jadi secara praktis, 1 kali di awal sesi kerja lebih masuk akal daripada memikirkan angka kaku seperti “harus 1 kali sehari” atau “setiap install wajib update”.

Kapan sebaiknya jalankan apt update lagi?

Gunakan panduan sederhana ini:

Apakah selalu perlu apt upgrade -y juga?

Tidak selalu harus setiap saat, tetapi pada awal setup server baru, sangat dianjurkan.

Karena VPS baru sering masih memakai package versi awal image bawaan provider. Dengan melakukan apt upgrade -y, kita membawa server ke kondisi yang lebih rapi dan lebih aman sebelum mulai menginstall komponen penting lain.

Namun setelah server berjalan stabil di production, upgrade besar perlu dilakukan dengan lebih hati-hati, terutama jika server sudah memegang layanan penting.

Pola aman untuk server baru

Untuk VPS baru seperti dalam course ini, pola yang aman adalah:

sudo apt update
sudo apt upgrade -y

Setelah itu baru lanjut ke instalasi lain, misalnya:

sudo apt install nginx -y

sudo apt install ufw -y

sudo apt install fail2ban -y

Tidak perlu menyisipkan apt update sebelum setiap baris install di atas kalau semuanya masih dilakukan dalam sesi yang sama.

Tips praktis untuk pemula

• Jangan spam command update terus-menerus hanya karena takut salah. Gunakan dengan logika.
• Biasakan update di awal sesi kerja saat mau setup atau install sesuatu.
• Untuk VPS baru, jalankan update + upgrade di awal sebelum instal komponen penting.
• Kalau kembali lagi di lain waktu, refresh lagi dengan apt update.

Kesimpulan lesson ini

apt update dipakai untuk menyegarkan daftar package, sedangkan apt upgrade dipakai untuk memasang pembaruan yang tersedia.

Anda tidak perlu menjalankan apt update sebelum setiap install kalau masih dalam sesi setup yang sama. Tetapi jika sudah beda waktu, beda sesi, atau server baru saja diakses lagi setelah beberapa lama, jalankan lagi apt update agar package list tetap fresh.

Di lesson berikutnya, kita akan masuk ke langkah penting berikutnya: membuat user deploy non-root agar workflow deployment LMS lebih aman.

Membuat user deploy

Setelah login pertama sebagai root, langkah penting berikutnya adalah membuat user non-root yang akan kita gunakan untuk pekerjaan deployment sehari-hari.

Dalam course ini, kita memakai nama user deploy. Nama ini bukan aturan wajib, tetapi cukup jelas karena perannya memang untuk membantu proses deploy aplikasi LMS.

Kenapa tidak langsung pakai root saja?

Secara teknis, root memang bisa melakukan semuanya. Tetapi justru karena itulah root terlalu berbahaya untuk dipakai kerja harian. Jika kita salah mengetik command saat memakai root, dampaknya bisa besar sekali: file sistem bisa terhapus, konfigurasi bisa rusak, atau service penting bisa terganggu.

Karena itu, pola yang lebih aman adalah:

• root dipakai untuk setup awal dan kondisi administratif tertentu,
• deploy dipakai untuk pekerjaan sehari-hari seperti upload source code, install dependency, build project, menjalankan aplikasi, dan maintenance ringan.

Apa itu user deploy?

User deploy adalah user Linux biasa yang kita buat secara khusus untuk mengelola project aplikasi di server. User ini bukan superuser penuh seperti root, tetapi bisa diberi hak sudo agar tetap bisa menjalankan command administratif saat diperlukan.

Dengan begitu, kita mendapatkan keseimbangan yang baik antara keamanan dan fleksibilitas kerja.

Command untuk membuat user deploy

Jalankan command berikut saat masih login sebagai root:

adduser deploy

Setelah command itu dijalankan, Ubuntu biasanya akan meminta beberapa input:

• password untuk user deploy,
• konfirmasi password,
• dan kadang informasi tambahan seperti full name, room number, work phone, dan sebagainya.

Untuk field tambahan itu, Anda bisa langsung tekan Enter saja jika tidak ingin mengisinya.

Contoh proses pembuatan user

root@your-server:~# adduser deploy
Adding user `deploy' ...
Adding new group `deploy' (1001) ...
Adding new user `deploy' (1001) with group `deploy' ...
Creating home directory `/home/deploy' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for deploy
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] Y

Kalau proses ini selesai dengan normal, berarti user deploy sudah berhasil dibuat.

Memberi hak sudo ke user deploy

Setelah user dibuat, tambahkan user tersebut ke group sudo:

usermod -aG sudo deploy

Atau versi yang juga umum dipakai:

adduser deploy sudo

Kedua pendekatan ini tujuannya sama: membuat user deploy bisa menjalankan command dengan sudo.

Kenapa hak sudo itu penting?

Karena nanti saat deploy LMS, ada beberapa command yang tetap membutuhkan hak administratif, misalnya:

• install package dengan apt install,
• reload Nginx,
• mengubah permission folder tertentu,
• atau mengelola service.

Kalau user deploy tidak punya hak sudo, kita akan bolak-balik login sebagai root, dan itu justru kurang praktis serta kurang aman.

Contoh penggunaan sudo setelah login sebagai deploy

Misalnya nanti Anda login sebagai deploy, lalu ingin update package:

sudo apt update

Sistem akan meminta password user deploy, bukan password root. Ini penting untuk dipahami.

Langkah setelah user deploy selesai dibuat: logout dari root lalu login ke deploy

Begitu user deploy sudah dibuat dan sudah masuk group sudo, langkah berikutnya yang sangat disarankan adalah berhenti bekerja sebagai root, lalu mulai masuk memakai user deploy.

Ini penting karena setelah lesson ini, workflow tutorial selanjutnya sebaiknya memakai user deploy, bukan root.

Cara logout dari root

Kalau Anda masih berada di terminal root, ketik:

exit

Setelah itu sesi terminal root akan tertutup atau kembali ke prompt sebelumnya. Kalau Anda sedang memakai PuTTY, biasanya session akan selesai dan jendela terminal bisa ditutup.

Login ulang ke server memakai user deploy

Setelah logout dari root, buka lagi session PuTTY Anda, lalu login memakai user deploy.

Contoh alurnya:

1. Buka PuTTY
2. Pilih session server VPS Anda
3. Klik Open
4. Pada prompt login, isi username: deploy
5. Masukkan password user deploy yang tadi dibuat

Contoh login sebagai deploy

login as: deploy
deploy@123.123.123.123's password:

Kalau login berhasil, Anda biasanya akan melihat prompt seperti ini:

deploy@your-server:~$

Perhatikan bedanya:

• root biasanya berakhir dengan tanda #
• deploy biasanya berakhir dengan tanda $

Ini membantu kita cepat sadar sedang berada di user mana.

Verifikasi bahwa Anda sudah benar-benar masuk sebagai deploy

Setelah berhasil login, jalankan command berikut:

whoami

Hasilnya harus:

deploy

Lalu cek juga apakah sudo berjalan normal:

sudo apt update

Jika command ini berjalan dan sistem meminta password user deploy, berarti user ini sudah siap dipakai untuk tutorial berikutnya.

Kenapa mulai sekarang sebaiknya pakai deploy?

Karena mulai setelah tahap ini, pekerjaan kita akan lebih banyak berupa aktivitas harian deployment, misalnya:

• masuk ke folder project LMS,
• clone repository atau upload source code,
• menjalankan npm install,
• menjalankan npm run build,
• mengelola file project,
• dan menjalankan command dengan sudo hanya saat perlu.

Semua ini jauh lebih aman jika dilakukan sebagai deploy.

Checklist setelah user deploy dibuat

Setelah selesai membuat user, lakukan pengecekan cepat berikut:

1. Cek apakah user deploy sudah ada

   id deploy

2. Cek apakah deploy masuk group sudo

   groups deploy

   Hasilnya seharusnya memuat sudo.

3. Pastikan home directory user tersedia

   ls -la /home

   Harus ada folder /home/deploy.

4. Logout dari root

   exit

5. Login kembali sebagai deploy
   Masuk lagi ke server memakai username deploy.
6. Verifikasi user aktif

   whoami

   Hasilnya harus deploy.

Contoh hasil pengecekan group

root@your-server:~# groups deploy
deploy : deploy sudo

Kalau sudo muncul di hasil ini, berarti user deploy sudah punya hak sudo.

Password user deploy juga harus disimpan baik-baik

Sama seperti password root, password user deploy juga harus disimpan aman. Jangan sampai nanti root sudah dinonaktifkan untuk login SSH, tetapi password deploy malah lupa. Itu bisa membuat akses ke server jadi ribet.

Apakah nama user harus deploy?

Tidak harus. Anda bisa memakai nama lain seperti ubuntu, admin, lms, atau nama tim Anda. Tetapi untuk course ini, memakai nama deploy memudahkan kita menjaga konsistensi tutorial dan command berikutnya.

Contoh pola kerja setelah lesson ini

Setelah user deploy tersedia, pola kerja kita nanti menjadi lebih rapi:

• Login awal dan setup inti: pakai root
• Kerja harian deployment: pakai deploy
• Kalau butuh hak administratif: gunakan sudo dari user deploy

Command utama lesson ini

adduser deploy
usermod -aG sudo deploy
exit

Kesimpulan lesson ini

Membuat user deploy adalah langkah penting untuk membangun VPS yang lebih aman dan lebih profesional. Kita tidak ingin semua pekerjaan dilakukan langsung memakai root. Dengan user deploy, workflow deployment LMS menjadi lebih terstruktur, lebih aman, dan lebih siap untuk production.

Mulai setelah lesson ini, biasakan lanjut bekerja memakai deploy. Jadi tutorial-tutorial berikutnya dijalankan dari user deploy, kecuali jika ada instruksi khusus yang memang membutuhkan akses root.

Login ulang dengan user deploy

Setelah user deploy berhasil dibuat dan dimasukkan ke group sudo, kita belum boleh langsung menganggap semuanya selesai. Langkah berikutnya adalah menguji login ulang memakai user baru tersebut.

Tujuan lesson ini sangat penting: memastikan bahwa user deploy benar-benar bisa dipakai untuk bekerja sehari-hari, bukan hanya sekadar tercatat ada di server.

Kenapa perlu login ulang?

Karena sampai titik ini kita masih bekerja sebagai root. Kita perlu membuktikan tiga hal:

1. user deploy benar-benar bisa login lewat SSH / PuTTY,
2. password user deploy benar dan tidak lupa,
3. user deploy benar-benar bisa memakai sudo.

Kalau tiga hal ini lolos, berarti fondasi workflow deployment kita sudah jauh lebih aman.

Tujuan akhir lesson ini

Setelah lesson ini selesai, Anda seharusnya bisa:

• keluar dari sesi root,
• login lagi memakai user deploy dari PuTTY,
• menjalankan command biasa,
• dan menguji command administratif memakai sudo.

Persiapan sebelum login ulang

Sebelum menutup sesi root, pastikan beberapa hal ini sudah benar:

• user deploy memang sudah dibuat,
• user deploy sudah masuk group sudo,
• Anda masih ingat password user deploy,
• IP VPS dan port SSH masih sama dan sudah dicatat.

Kalau perlu, cek lagi dari sesi root:

groups deploy

Hasil yang ideal kurang lebih seperti ini:

deploy : deploy sudo

Langkah 1 — Keluar dari sesi root

Dari terminal root yang masih aktif, ketik:

exit

Atau Anda bisa langsung menutup jendela terminal PuTTY tersebut. Tetapi memakai exit lebih rapi karena sesi ditutup dengan benar.

Langkah 2 — Buka PuTTY lagi

Sekarang buka kembali aplikasi PuTTY di Windows.

Di halaman awal PuTTY, isi setting sama seperti sebelumnya:

• Host Name (or IP address) = IP VPS Anda
• Port = biasanya 22 atau port SSH yang Anda pakai
• Connection type = SSH

Lalu klik Open.

Langkah 3 — Login memakai user deploy

Setelah terminal PuTTY terbuka, akan muncul prompt login:

login as:

Ketik:

deploy

Lalu tekan Enter.

Setelah itu akan diminta password. Masukkan password user deploy yang tadi dibuat saat lesson sebelumnya.

Ingat: saat mengetik password di terminal Linux, karakter memang tidak terlihat. Itu normal. Tetap ketik lalu tekan Enter.

Contoh login lengkap di PuTTY

login as: deploy
deploy@123.45.67.89's password:

Jika password benar, Anda akan masuk ke server dan biasanya melihat prompt seperti ini:

deploy@your-server:~$

Perhatikan tanda $ di akhir prompt. Ini biasanya menandakan bahwa Anda login sebagai user biasa, bukan root.

Langkah 4 — Verifikasi bahwa Anda benar-benar login sebagai deploy

Begitu berhasil masuk, jangan langsung lanjut ke pekerjaan lain. Verifikasi dulu user aktif dengan command berikut:

whoami

Hasilnya harus:

deploy

Anda juga bisa cek lokasi home directory saat ini:

pwd

Biasanya hasilnya:

/home/deploy

Ini menunjukkan bahwa Anda benar-benar berada di environment user deploy.

Langkah 5 — Uji apakah sudo berfungsi

Ini langkah yang sangat penting. Jalankan command berikut:

sudo apt update

Sistem akan meminta password. Masukkan password user deploy, bukan password root.

Kalau command ini berjalan normal, berarti user deploy berhasil memakai sudo.

Contoh hasil uji sudo yang berhasil

deploy@your-server:~$ sudo apt update
[sudo] password for deploy:
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Reading package lists... Done

Kalau sampai tahap ini sukses, maka user deploy sudah siap dipakai untuk workflow deployment sehari-hari.

Apa yang harus dicek setelah login deploy berhasil?

1. Cek user aktif

   whoami

2. Cek home directory

   pwd

3. Cek group user

   groups

   Hasil seharusnya memuat sudo.

4. Test sudo

   sudo apt update

Checklist sukses lesson ini

Lesson ini dianggap berhasil kalau semua poin berikut terpenuhi:

• PuTTY bisa terhubung ke VPS,
• login dengan user deploy berhasil,
• whoami menghasilkan deploy,
• groups menampilkan sudo,
• sudo apt update berjalan normal.

Masalah umum dan cara membacanya

Kalau login deploy gagal, apa yang harus dilakukan?

Jangan panik. Selama Anda masih punya akses root, masalah ini masih bisa diperbaiki. Login lagi sebagai root, lalu cek:

id deploy

groups deploy

passwd deploy

Kalau perlu, Anda bisa reset password user deploy dengan:

passwd deploy

Lalu coba login ulang lagi dari PuTTY.

Kenapa lesson ini penting untuk deployment LMS?

Karena setelah ini kita ingin membangun kebiasaan yang benar: tidak selalu bekerja sebagai root. Untuk install dependency project, membuat folder aplikasi, menjalankan npm install, build project, dan mengelola proses deployment, user deploy akan jauh lebih aman dipakai.

Contoh alur praktik singkat

1. Login sebagai root
2. Buat user deploy
3. Tambahkan deploy ke sudo
4. exit dari root
5. Buka PuTTY lagi
6. Login sebagai deploy
7. Jalankan whoami
8. Jalankan sudo apt update

Kalau semua ini berjalan, berarti server Anda sudah siap untuk masuk ke tahap berikutnya.

Kesimpulan lesson ini

Login ulang dengan user deploy adalah langkah verifikasi penting untuk memastikan user non-root yang baru dibuat memang siap dipakai bekerja.

Begitu login deploy dan sudo berhasil, Anda sudah punya pola akses server yang lebih aman dan lebih profesional untuk melanjutkan deployment LMS.

Di lesson berikutnya, kita akan lanjut ke penataan yang lebih rapi lagi: struktur folder untuk LMS di dalam server.

Struktur folder untuk LMS

Setelah user deploy siap dipakai, langkah berikutnya adalah menentukan di mana source code LMS akan diletakkan di server. Ini kelihatan sederhana, tetapi sebenarnya sangat penting karena struktur folder yang rapi akan memudahkan kita saat install dependency, build project, menjalankan aplikasi, mengelola file environment, dan melakukan maintenance di kemudian hari.

Kalau dari awal folder project berantakan, nanti saat LMS sudah semakin besar, proses deploy akan terasa membingungkan. Karena itu, di lesson ini kita membangun kebiasaan yang benar sejak awal.

Tujuan lesson ini

Setelah lesson ini, Anda seharusnya memahami:

• folder mana yang cocok untuk menaruh aplikasi LMS di VPS,
• kenapa kita tidak menaruh project sembarangan,
• bagaimana membuat struktur folder yang rapi,
• dan bagaimana memastikan user deploy menjadi pemilik folder project tersebut.

Kenapa struktur folder itu penting?

Karena VPS bukan hanya tempat menjalankan satu command. VPS adalah tempat aplikasi akan hidup terus-menerus. Nantinya kita akan bekerja dengan banyak hal sekaligus:

• source code project,
• dependency node_modules,
• hasil build production,
• file environment,
• konfigurasi Nginx,
• log aplikasi,
• dan mungkin versi project berikutnya.

Kalau semua itu tidak ditata dengan baik, kita akan cepat bingung: file mana yang aktif, folder mana yang dipakai production, dan user mana yang berhak menulis ke dalamnya.

Pola folder yang kita pakai di course ini

Untuk course ini, pola yang sederhana dan rapi adalah:

/var/www/lms

Ini berarti:

• /var/www menjadi area umum untuk project web,
• lms adalah folder utama project kita.

Pola ini cukup umum, mudah diingat, dan cocok untuk LMS yang akan dijalankan dengan Nginx sebagai reverse proxy.

Kenapa memilih /var/www?

Secara tradisional, banyak aplikasi web di Linux diletakkan di bawah /var/www. Tidak wajib, tetapi ini adalah lokasi yang sangat familiar untuk project web. Keuntungannya:

• mudah dikenali sebagai lokasi aplikasi web,
• rapi saat nanti ada lebih dari satu project,
• mudah dijelaskan dalam tutorial dan maintenance,
• cocok dengan workflow Nginx dan deployment umum.

Jadi bukan karena ini satu-satunya tempat yang benar, tetapi karena ini tempat yang masuk akal dan profesional untuk project web.

Apakah boleh pakai folder lain?

Boleh. Secara teknis Anda bisa menaruh project di lokasi lain seperti:

• /home/deploy/lms
• /opt/lms
• /srv/lms

Tetapi untuk course ini kita memakai /var/www/lms agar pembelajaran konsisten dan mudah diikuti. Saat belajar deployment, konsistensi jauh lebih penting daripada terlalu banyak variasi pilihan.

Struktur dasar yang akan kita buat

Di tahap awal, struktur minimumnya bisa sesederhana ini:

/var/www/
└── lms/
    ├── frontend/
    ├── shared/        (opsional, jika nanti diperlukan)
    ├── backups/       (opsional)
    └── logs/          (opsional)

Kalau saat ini project Anda baru fokus di frontend LMS berbasis Next.js, maka struktur paling sederhana dan aman adalah:

/var/www/lms/frontend

Jadi source code frontend akan berada di sana.

Pola paling sederhana untuk project saat ini

Karena dari file yang sudah kita pakai, fokus saat ini adalah frontend, maka pola awal yang cocok adalah:

/var/www/lms/frontend

Nanti saat Anda masuk ke folder itu, di sanalah Anda bisa:

• clone repository,
• menjalankan npm install,
• menjalankan npm run build,
• dan menjalankan aplikasi production.

Cara membuat folder project

Kalau Anda masih login sebagai root, buat folder utamanya terlebih dahulu:

mkdir -p /var/www/lms

Kalau ingin langsung membuat folder frontend juga:

mkdir -p /var/www/lms/frontend

Option -p membuat command ini aman dijalankan walaupun parent folder belum ada.

Kenapa ownership folder penting?

Membuat folder saja belum cukup. Kita juga harus memastikan bahwa user yang akan bekerja di dalam folder itu adalah user yang tepat, yaitu deploy.

Kalau ownership folder masih milik root, lalu nanti Anda login sebagai deploy, bisa saja Anda tidak bisa menulis file, tidak bisa clone project, atau tidak bisa melakukan build dengan nyaman.

Command untuk mengubah ownership folder

Setelah folder dibuat, ubah pemiliknya ke user deploy:

chown -R deploy:deploy /var/www/lms

Artinya:

• deploy sebagai user owner,
• deploy sebagai group owner,
• -R berarti berlaku rekursif ke seluruh isi folder.

Kenapa bukan root yang tetap jadi owner?

Karena kita sudah memutuskan bahwa pekerjaan deploy harian akan dilakukan dengan user deploy. Maka sangat masuk akal jika folder project juga dimiliki oleh user tersebut.

Pola yang sehat adalah:

• konfigurasi inti sistem: bisa dikelola via sudo,
• folder project aplikasi: dimiliki user deploy,
• workflow harian: dijalankan dari user deploy.

Contoh alur lengkap pembuatan folder

sudo mkdir -p /var/www/lms/frontend
sudo chown -R deploy:deploy /var/www/lms

Kalau Anda sedang login sebagai root, sudo tidak wajib. Tetapi kalau Anda sudah login sebagai deploy, gunakan sudo.

Cara mengecek hasilnya

Gunakan command berikut:

ls -la /var/www

Lalu untuk melihat isi folder LMS:

ls -la /var/www/lms

Untuk melihat ownership lebih jelas:

stat /var/www/lms

Atau cukup:

ls -ld /var/www/lms

Hasil yang kita harapkan adalah owner folder terlihat sebagai deploy deploy.

Contoh hasil yang ideal

drwxr-xr-x 3 deploy deploy 4096 Apr 22 10:00 /var/www/lms

Kalau owner dan group sama-sama deploy, itu pertanda bagus untuk workflow kita.

Apakah perlu membuat banyak folder sejak awal?

Tidak perlu berlebihan. Untuk fase awal, jangan buat struktur yang terlalu rumit. Fokus kita adalah menyiapkan folder yang cukup untuk bekerja dengan rapi.

Untuk kondisi LMS Anda saat ini, pola sederhana berikut sudah sangat cukup:

/var/www/lms/frontend

Nanti jika project berkembang, kita bisa menambah folder lain secara bertahap, misalnya:

• /var/www/lms/backups untuk backup manual,
• /var/www/lms/shared untuk file bersama,
• /var/www/lms/releases jika suatu hari ingin pola deployment versioned.

Tetapi untuk belajar VPS dan deploy pertama, jangan terlalu jauh dulu. Yang penting adalah jelas, sederhana, dan bisa dipakai.

Contoh struktur yang mudah dipahami untuk tahap sekarang

/var/www/lms/
└── frontend/
    ├── package.json
    ├── next.config.js
    ├── src/
    ├── public/
    └── .env.production   (nanti jika diperlukan)

Dengan pola ini, saat Anda masuk ke folder project, semuanya terasa jelas. Anda tahu di mana posisi project, di mana menjalankan command npm, dan di mana hasil build akan terbentuk.

Pola kerja yang akan kita pakai nanti

Nanti alurnya akan seperti ini:

1. Login ke VPS sebagai deploy
2. Masuk ke folder project

   cd /var/www/lms/frontend

3. Clone source code atau upload project ke sana
4. Install dependency

   npm install

5. Build production

   npm run build

6. Jalankan aplikasi dan hubungkan dengan Nginx

Semua workflow ini akan jauh lebih rapi kalau struktur foldernya sudah benar dari awal.

Kesalahan umum yang perlu dihindari

• Menaruh project di folder acak seperti langsung di root home tanpa pola yang jelas.
• Folder dimiliki root padahal kerja harian memakai deploy.
• Membuat struktur terlalu rumit sejak awal padahal project masih sederhana.
• Tidak konsisten nama folder sehingga nanti bingung mana folder aktif production.

Contoh command lengkap lesson ini

sudo mkdir -p /var/www/lms/frontend
sudo chown -R deploy:deploy /var/www/lms
ls -ld /var/www/lms
ls -la /var/www/lms

Kesimpulan lesson ini

Struktur folder yang rapi adalah fondasi workflow deployment yang sehat. Untuk LMS ini, kita memakai pola sederhana dan profesional di /var/www/lms, dengan source code frontend berada di /var/www/lms/frontend.

Setelah folder dibuat dan ownership-nya benar untuk user deploy, kita siap masuk ke tahap berikutnya di module berikutnya: mengamankan server, lalu melanjutkan ke install stack deployment LMS.

Mengubah port SSH

Sebelum kita mengubah port SSH, kita perlu memahami dulu apa itu SSH secara sederhana.

Apa itu SSH?

SSH adalah singkatan dari Secure Shell. Dummy paling gampangnya, SSH adalah jalur aman untuk masuk ke server dari jarak jauh. Jadi saat kita membuka VPS lewat PuTTY, sebenarnya kita sedang masuk ke server melalui layanan SSH.

Kalau diibaratkan, server adalah rumah, dan SSH adalah pintu masuk resminya. Selama pintu itu terbuka dan kita punya credential yang benar, kita bisa masuk lalu menjalankan command dari komputer kita ke VPS.

Kenapa port SSH biasanya 22?

Secara default, SSH memakai port 22. Karena ini adalah default standar, hampir semua orang tahu bahwa banyak server Linux membuka SSH di port ini.

Masalahnya, bot internet juga tahu hal yang sama. Jadi port 22 adalah target yang sangat sering dipindai otomatis.

Kenapa port SSH sering diubah?

Port SSH sering diubah untuk mengurangi noise dan serangan otomatis yang menarget port default. Jadi ini bukan perlindungan utama, tetapi salah satu lapisan keamanan tambahan yang cukup berguna.

Kalau port 22 dibiarkan terbuka, server Anda akan lebih sering menerima percobaan login otomatis dari bot yang memindai internet.

Apa risiko jika port SSH tidak diubah?

• Lebih sering terkena brute-force attempt — bot akan mencoba username dan password berulang kali.
• Log server menjadi lebih berisik — karena banyak percobaan login otomatis tercatat.
• Menambah permukaan serangan — terutama jika password lemah atau root login masih aktif.
• Lebih mudah terdeteksi oleh scanning otomatis — karena port 22 adalah target paling umum.

Perlu dipahami: mengubah port SSH tidak membuat server kebal, tetapi bisa membantu mengurangi serangan otomatis level dasar. Jadi ini lebih seperti menggeser pintu masuk utama dari lokasi yang terlalu mudah ditebak.

Apakah mengubah port SSH wajib?

Tidak mutlak wajib, tetapi sangat disarankan untuk server yang akan dibuka ke internet. Dalam course ini, kita anggap ini sebagai bagian dari server hardening dasar.

Prinsip penting sebelum mengubah port SSH

Sebelum mengganti port, ada dua hal yang wajib diingat:

1. Jangan tutup session SSH yang sedang aktif sebelum Anda yakin port baru bisa dipakai untuk login.
2. Kalau memakai firewall, port baru harus dibuka juga. Kalau tidak, Anda bisa terkunci dari server.

Cara mengubah port SSH di Ubuntu

Login ke server, lalu buka file konfigurasi SSH:

sudo nano /etc/ssh/sshd_config

Cari baris yang berisi #Port 22 atau Port 22. Lalu ubah menjadi port baru, misalnya:

Port 2222

Anda boleh memakai angka lain juga, asalkan:

• bukan port yang sedang dipakai service lain,
• mudah Anda ingat,
• dan nanti dibuka juga di firewall.

Contoh langkah edit

1. Buka file konfigurasi SSH

   sudo nano /etc/ssh/sshd_config

2. Cari bagian port
3. Ubah menjadi misalnya:

   Port 2222

4. Simpan file
5. Restart service SSH

Restart service SSH

Setelah konfigurasi disimpan, jalankan:

sudo systemctl restart ssh

Atau pada beberapa sistem bisa juga:

sudo systemctl restart sshd

Namun untuk Ubuntu, ssh biasanya sudah benar.

Kalau server memakai UFW firewall

Kalau firewall UFW sudah aktif, jangan lupa buka port baru sebelum Anda mencoba login ulang:

sudo ufw allow 2222

Kalau sebelumnya port 22 hanya dipakai untuk SSH dan nanti memang ingin ditutup, lakukan itu setelah login lewat port baru berhasil diuji.

Urutan aman yang disarankan

1. Edit file SSH config

   sudo nano /etc/ssh/sshd_config

2. Ubah port, misalnya jadi 2222
3. Simpan file
4. Buka port baru di firewall jika firewall aktif

   sudo ufw allow 2222

5. Restart service SSH

   sudo systemctl restart ssh

6. Buka PuTTY baru dan test login memakai port baru
7. Kalau berhasil, baru lanjutkan hardening berikutnya

Cara login dari PuTTY setelah port diganti

Setelah port diubah, saat membuka PuTTY Anda harus mengganti field Port dari 22 menjadi port baru, misalnya 2222. Kalau memakai Saved Session, jangan lupa update session itu lalu simpan lagi.

Contoh konfigurasi baru di PuTTY

• Host Name → IP VPS Anda
• Port → 2222
• Connection Type → SSH

Kesalahan umum yang perlu dihindari

• Mengubah port SSH tetapi lupa membuka port baru di firewall
• Menutup session lama sebelum test login ke port baru
• Lupa mengganti port di PuTTY sehingga mengira server error
• Memilih port baru yang bentrok dengan service lain

Contoh command inti lesson ini

sudo nano /etc/ssh/sshd_config

Port 2222

sudo ufw allow 2222

sudo systemctl restart ssh

Kesimpulan lesson ini

SSH adalah jalur aman untuk masuk ke server dari jarak jauh. Karena port default SSH yaitu 22 sangat umum diketahui, banyak bot internet menargetkannya secara otomatis. Dengan mengubah port SSH, kita menambahkan satu lapisan hardening dasar agar server tidak terlalu mudah menjadi target scanning otomatis.

Namun ingat: mengubah port SSH bukan perlindungan utama. Ini harus dipadukan dengan langkah lain seperti disable root login, firewall, dan proteksi tambahan seperti Fail2Ban.

Disable root login

Setelah user deploy siap dipakai, salah satu langkah hardening yang sangat penting adalah menonaktifkan login langsung sebagai root melalui SSH.

Kenapa root login sebaiknya di-disable?

User root adalah akun dengan hak akses tertinggi di server. Kalau seseorang berhasil login sebagai root, maka orang tersebut hampir bisa melakukan apa saja di VPS: mengubah konfigurasi sistem, menghapus file penting, menambah user, mematikan service, bahkan mengambil alih seluruh server.

Karena itulah, root login lewat SSH sebaiknya tidak dibiarkan terbuka untuk akses harian dari internet.

Kenapa ini relevan dengan pola course kita?

Sesuai alur course ini, kita sudah membuat user deploy dan menyiapkannya untuk workflow harian. Artinya, sekarang kita tidak perlu lagi login langsung sebagai root untuk pekerjaan rutin.

Pola yang lebih aman adalah:

• login ke server menggunakan user deploy,
• lalu gunakan sudo jika memang butuh hak administratif.

Apa risiko jika root login tidak di-disable?

• Menjadi target utama brute-force — bot internet sangat sering mencoba login ke username root.
• Risiko kompromi lebih besar — kalau password root bocor atau lemah, dampaknya langsung sangat besar.
• Tidak mengikuti prinsip least privilege — pekerjaan harian dilakukan dengan akses terlalu tinggi.
• Memperbesar dampak human error — salah command saat login sebagai root bisa merusak sistem lebih cepat.

Apakah root harus dihapus?

Tidak. Yang kita nonaktifkan adalah login root lewat SSH, bukan menghapus user root dari sistem. User root tetap ada, tetapi akses remote langsungnya dibatasi.

Prasyarat sebelum disable root login

Jangan lakukan langkah ini kalau user deploy belum benar-benar siap. Pastikan dulu:

1. user deploy sudah dibuat,
2. user deploy sudah masuk group sudo,
3. Anda sudah berhasil login memakai deploy,
4. sudo dari user deploy berjalan normal.

Cara men-disable root login

Login ke server memakai user deploy, lalu buka file konfigurasi SSH:

sudo nano /etc/ssh/sshd_config

Cari baris berikut:

#PermitRootLogin prohibit-password

atau:

PermitRootLogin yes

Lalu ubah menjadi:

PermitRootLogin no

Kalau barisnya masih diberi tanda #, hapus tanda komentar tersebut agar setting benar-benar aktif.

Contoh hasil konfigurasi yang benar

PermitRootLogin no

Simpan file lalu restart SSH

Setelah file diubah dan disimpan, restart service SSH:

sudo systemctl restart ssh

Langkah aman setelah restart

Setelah restart, jangan langsung logout dari session aktif. Buka jendela PuTTY baru dan test login memakai user deploy.

Kalau login user deploy berhasil, barulah perubahan ini dianggap aman.

Apa yang akan terjadi setelah root login di-disable?

Setelah konfigurasi ini aktif:

• login SSH langsung sebagai root akan ditolak,
• login harian harus memakai user biasa seperti deploy,
• hak administratif tetap bisa dipakai melalui sudo.

Contoh workflow yang benar setelah ini

1. Login PuTTY sebagai deploy
2. Masuk ke server
3. Jalankan command biasa untuk kerja harian
4. Gunakan sudo hanya jika diperlukan

Kesalahan umum yang perlu dihindari

• Disable root login sebelum user deploy bisa dipakai
• Lupa menyimpan file sshd_config
• Lupa restart service SSH setelah mengubah konfigurasi
• Tidak menguji login deploy setelah perubahan

Command inti lesson ini

sudo nano /etc/ssh/sshd_config

PermitRootLogin no

sudo systemctl restart ssh

Kesimpulan lesson ini

Root login sebaiknya di-disable karena akun root adalah target utama serangan otomatis dan memiliki hak akses tertinggi di server. Dengan menonaktifkan login root lewat SSH, kita memaksa workflow server menjadi lebih aman: masuk memakai user deploy, lalu naik hak akses hanya saat memang diperlukan dengan sudo.

Ini adalah salah satu langkah hardening paling penting setelah user deploy siap dipakai.

Install UFW Firewall

Setelah port SSH dibahas dan root login mulai diamankan, langkah hardening berikutnya adalah memasang firewall di VPS. Di Ubuntu, tool yang paling umum dan ramah pemula untuk ini adalah UFW.

Apa itu UFW?

UFW adalah singkatan dari Uncomplicated Firewall. Sesuai namanya, UFW dibuat untuk mempermudah pengelolaan firewall di Ubuntu.

Dummy paling sederhananya begini: kalau server adalah rumah, maka UFW membantu kita menentukan pintu mana yang boleh dibuka dan pintu mana yang harus ditutup.

Dalam konteks VPS, “pintu” itu adalah port. Jadi dengan UFW, kita bisa mengatur port mana yang boleh diakses dari internet, misalnya:

• port SSH untuk login ke server,
• port 80 untuk HTTP,
• port 443 untuk HTTPS.

Kenapa harus install UFW?

Karena VPS yang terhubung ke internet idealnya tidak membiarkan semua port terbuka begitu saja. Kita ingin server hanya membuka akses yang memang diperlukan.

Dengan UFW, kita bisa membangun kebiasaan yang sehat:

• hanya membuka port yang benar-benar dipakai,
• menutup port yang tidak perlu,
• mengurangi risiko server menjadi terlalu terbuka ke internet.

Apa risiko jika UFW tidak diinstall?

• Server lebih terbuka dari yang seharusnya — port yang tidak perlu bisa tetap bisa diakses.
• Permukaan serangan lebih luas — semakin banyak layanan terbuka, semakin besar peluang diserang.
• Lebih sulit mengontrol akses — Anda tidak punya lapisan pembatas sederhana di level OS.
• Troubleshooting keamanan jadi kurang rapi — karena tidak ada aturan firewall yang jelas dan terdokumentasi.

Apakah tanpa UFW server pasti langsung berbahaya?

Tidak selalu langsung berbahaya, tetapi jauh kurang rapi dan kurang aman. Untuk server production, firewall adalah salah satu fondasi dasar keamanan. Jadi di course ini, UFW diperlakukan sebagai langkah yang sangat disarankan.

Sesuai pola course ini: gunakan user deploy

Karena workflow kita setelah ini memakai user deploy, maka instalasi UFW juga dilakukan dari user deploy dengan bantuan sudo, bukan dengan login harian sebagai root.

Cara install UFW

Login ke server memakai user deploy, lalu jalankan:

sudo apt update
sudo apt install ufw -y

Kalau instalasi berhasil, berarti tool UFW sudah tersedia di server.

Cara mengecek apakah UFW sudah terinstall

Setelah instalasi, Anda bisa cek statusnya dengan:

sudo ufw status

Kalau UFW baru saja diinstall, biasanya hasil awalnya adalah:

Status: inactive

Itu normal. Artinya UFW sudah terpasang, tetapi belum diaktifkan.

Catatan penting sebelum enable UFW

Jangan langsung mengaktifkan UFW tanpa membuka port SSH lebih dulu. Kalau tidak, Anda bisa terkunci dari VPS.

Karena pada tahap ini kita baru fokus ke instalasi, aktivasi dan pembukaan port akan dibahas di lesson berikutnya.

Contoh alur aman pada tahap ini

1. Login ke VPS sebagai deploy
2. Install UFW dengan sudo
3. Cek status UFW
4. Lanjut ke lesson berikutnya untuk membuka port yang dibutuhkan sebelum enable firewall

Command inti lesson ini

sudo apt update
sudo apt install ufw -y
sudo ufw status

Kesimpulan lesson ini

UFW adalah firewall sederhana bawaan Ubuntu yang membantu kita mengontrol port mana yang boleh diakses dari internet. Untuk VPS production, ini adalah lapisan keamanan dasar yang sangat penting.

Tanpa firewall, server bisa menjadi terlalu terbuka. Dengan UFW, kita bisa mulai membatasi akses secara lebih rapi dan aman. Setelah lesson ini, langkah berikutnya adalah membuka hanya port yang memang dibutuhkan sebelum firewall diaktifkan.

Open ports yang dibutuhkan

Setelah UFW terinstall, langkah berikutnya bukan langsung mengaktifkan firewall, tetapi membuka hanya port yang memang dibutuhkan. Ini penting supaya saat firewall di-enable, server tetap bisa diakses untuk layanan yang memang kita perlukan, dan tetap tertutup untuk layanan yang tidak perlu.

Kenapa port harus dibuka dulu sebelum enable UFW?

Karena UFW bekerja dengan aturan akses. Kalau Anda mengaktifkan firewall sebelum membuka port penting seperti SSH, maka koneksi ke server bisa langsung terblokir. Itulah sebabnya lesson ini datang sebelum lesson enable firewall.

Sesuai pola course ini: gunakan user deploy

Mulai tahap ini, kita tetap mengikuti pola course sebelumnya: bekerja sebagai user deploy lalu memakai sudo saat perlu hak administratif.

Port minimum yang biasanya dibutuhkan LMS

Untuk skenario LMS seperti course ini, port minimum yang paling umum adalah:

• Port SSH — untuk login ke server. Dalam contoh course ini kita memakai port 2222, tetapi sesuaikan dengan port SSH yang benar-benar Anda pakai.
• Port 80 — untuk HTTP.
• Port 443 — untuk HTTPS.

Contoh membuka port yang dibutuhkan

sudo ufw allow 2222
sudo ufw allow 80
sudo ufw allow 443

Kalau server Anda memakai port SSH yang berbeda, misalnya 2203, maka gunakan port yang sesuai:

sudo ufw allow 2203

Prinsip penting: buka hanya yang perlu

Jangan membuka terlalu banyak port tanpa alasan yang jelas. Semakin banyak port dibuka, semakin besar permukaan akses dari internet. Jadi pendekatan yang sehat adalah: buka hanya port yang memang dipakai.

Cara melihat port yang sudah dibuka di UFW

Setelah menambahkan rule, Anda bisa melihat daftar rule UFW dengan command berikut:

sudo ufw status

Kalau ingin tampilan yang lebih detail dan bernomor, gunakan:

sudo ufw status numbered

Contoh hasilnya bisa seperti ini:

Status: active

To                         Action      From
--                         ------      ----
2222                       ALLOW       Anywhere
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere

Kalau UFW belum di-enable, apakah rule tetap bisa ditambahkan?

Ya, bisa. Ini justru workflow yang aman. Kita bisa menambahkan dulu semua rule yang dibutuhkan, lalu baru mengaktifkan firewall setelah semuanya siap.

Cara membaca hasil ufw status

• To = port atau service tujuan
• Action = apakah diizinkan atau ditolak
• From = asal koneksi, biasanya Anywhere

Cara memastikan port SSH yang benar-benar dipakai

Sebelum membuka port SSH di UFW, pastikan Anda benar-benar tahu port SSH aktif yang sedang dipakai server. Jangan asal menebak. Kalau Anda sudah mengganti port SSH sebelumnya, maka port itulah yang harus di-allow.

Misalnya:

• Kalau SSH masih di port default: buka 22
• Kalau SSH sudah dipindah: buka port baru tersebut, misalnya 2222 atau 2203

Contoh skenario yang aman

1. Login ke server sebagai deploy
2. Tambahkan rule untuk port SSH yang aktif
3. Tambahkan rule untuk HTTP dan HTTPS
4. Cek ulang rule dengan sudo ufw status
5. Baru lanjut ke lesson enable firewall

Kalau salah membuka port, bagaimana mengeceknya?

Gunakan:

sudo ufw status numbered

Dengan tampilan bernomor, Anda akan lebih mudah meninjau rule mana yang aktif. Ini sangat membantu sebelum firewall di-enable.

Kesalahan umum yang perlu dihindari

• Membuka port SSH yang salah
• Lupa membuka port SSH sebelum enable firewall
• Mengira semua server selalu memakai port 22
• Membuka terlalu banyak port tanpa kebutuhan yang jelas
• Tidak mengecek ulang hasil rule dengan ufw status

Command inti lesson ini

sudo ufw allow 2222
sudo ufw allow 80
sudo ufw allow 443
sudo ufw status
sudo ufw status numbered

Kesimpulan lesson ini

Sebelum firewall diaktifkan, port yang dibutuhkan harus dibuka lebih dulu. Untuk LMS, port minimum yang paling umum adalah port SSH, HTTP, dan HTTPS. Setelah rule dibuat, biasakan selalu mengeceknya kembali dengan sudo ufw status atau sudo ufw status numbered agar kita benar-benar tahu port mana yang sudah dibuka.

Setelah semua rule dasar siap, barulah kita aman masuk ke lesson berikutnya: mengaktifkan firewall.

Enable firewall

Setelah rule port selesai disiapkan, langkah berikutnya adalah mengaktifkan firewall. Pada course ini, firewall yang kita pakai adalah UFW.

Apa itu firewall?

Firewall adalah lapisan pengaman jaringan yang membantu mengontrol koneksi masuk dan keluar dari server. Dummy paling mudahnya: kalau server adalah rumah, maka firewall adalah satpam di pintu gerbang yang memeriksa siapa yang boleh masuk dan lewat pintu mana.

Dalam konteks VPS, firewall membantu menentukan port mana yang boleh diakses dari internet dan mana yang harus ditutup.

Fungsi firewall di VPS

• Membatasi akses hanya ke port yang memang dibutuhkan
• Mengurangi permukaan serangan dari internet
• Membuat konfigurasi akses lebih rapi dan lebih terkontrol
• Membantu hardening server sebagai lapisan keamanan dasar

Apa risiko jika server tanpa firewall?

• Server bisa terlalu terbuka ke internet
• Port yang tidak perlu berpotensi tetap bisa diakses
• Lebih mudah menjadi target scanning dan probing otomatis
• Kontrol akses menjadi kurang rapi karena tidak ada pembatas dasar di level OS

Sesuai pola course ini: gunakan user deploy

Seperti lesson-lesson sebelumnya, aktivasi firewall dilakukan memakai user deploy lalu menjalankan sudo untuk command administratif.

Kapan firewall boleh di-enable?

Firewall baru boleh diaktifkan setelah rule penting selesai disiapkan, terutama:

• port SSH yang sedang benar-benar dipakai
• port 80 untuk HTTP
• port 443 untuk HTTPS

Cara mengaktifkan UFW

Login ke server sebagai deploy, lalu jalankan:

sudo ufw enable

Biasanya sistem akan menampilkan konfirmasi seperti ini:

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Kalau Anda sudah yakin port SSH yang benar sudah dibuka di lesson sebelumnya, jawab:

y

Setelah enable, cek status firewall

Setelah UFW aktif, segera cek statusnya:

sudo ufw status

Atau kalau ingin tampilan lebih detail dan bernomor:

sudo ufw status numbered

Contoh hasil yang sehat:

Status: active

To                         Action      From
--                         ------      ----
2222                       ALLOW       Anywhere
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere

Kalau port SSH Anda bukan 2222

Sesuaikan dengan port SSH yang benar-benar sedang dipakai server Anda. Misalnya kalau Anda memakai 2203, maka port itulah yang harus sudah di-allow sebelum firewall di-enable.

Cara verifikasi setelah firewall aktif

1. Pastikan sudo ufw status menunjukkan Status: active
2. Pastikan rule SSH, HTTP, dan HTTPS benar-benar muncul
3. Jangan tutup session aktif terlalu cepat
4. Coba buka session PuTTY baru untuk memastikan SSH tetap bisa dipakai

Urutan aman yang disarankan

1. Login ke VPS sebagai deploy
2. Pastikan rule SSH, 80, dan 443 sudah dibuat
3. Cek ulang dengan sudo ufw status
4. Aktifkan firewall dengan sudo ufw enable
5. Cek lagi status firewall
6. Test koneksi SSH di jendela baru

Kesalahan umum yang perlu dihindari

• Enable firewall sebelum membuka port SSH
• Membuka port SSH yang salah
• Tidak mengecek ulang status firewall setelah enable
• Langsung logout tanpa menguji koneksi baru

Command inti lesson ini

sudo ufw enable
sudo ufw status
sudo ufw status numbered

Kesimpulan lesson ini

Firewall berfungsi sebagai lapisan pengendali akses jaringan di VPS. Tanpa firewall, server bisa menjadi terlalu terbuka ke internet. Dengan UFW, kita bisa membatasi akses hanya ke port yang memang dibutuhkan.

Namun aktivasi firewall harus dilakukan dengan hati-hati. Pastikan rule dasar terutama port SSH sudah benar-benar siap sebelum UFW di-enable.

Install Fail2Ban

Setelah firewall aktif, langkah hardening berikutnya adalah menambahkan proteksi terhadap brute-force attack. Salah satu tool paling populer untuk ini di Linux adalah Fail2Ban.

Apa itu Fail2Ban?

Fail2Ban adalah tool keamanan yang memonitor log server, lalu secara otomatis memblokir IP yang mencoba login berulang kali dan gagal.

Dummy paling mudahnya: kalau firewall adalah pintu, maka Fail2Ban adalah satpam yang mengingat siapa yang mencoba masuk berkali-kali dengan cara mencurigakan, lalu melarang orang itu masuk lagi.

Bagaimana cara kerja Fail2Ban?

Fail2Ban akan:

• membaca log (misalnya log SSH),
• mendeteksi percobaan login gagal berulang,
• jika melewati batas tertentu, maka IP tersebut akan diblokir sementara.

Seberapa perlu menggunakan Fail2Ban?

Untuk VPS yang terhubung ke internet publik, Fail2Ban sangat disarankan. Bahkan untuk server production, ini bisa dianggap sebagai salah satu layer keamanan dasar.

Kenapa? Karena hampir semua server di internet akan:

• dipindai oleh bot,
• dicoba login berkali-kali,
• terutama pada layanan seperti SSH.

Apa risiko jika tidak menggunakan Fail2Ban?

• Brute-force attack lebih mudah terjadi — bot bisa mencoba password berkali-kali tanpa diblokir.
• Log server menjadi penuh oleh percobaan login gagal.
• Beban server meningkat karena banyak request login tidak valid.
• Risiko keamanan meningkat jika password lemah atau konfigurasi kurang aman.

Apakah firewall saja tidak cukup?

Firewall seperti UFW hanya mengatur port mana yang boleh diakses. Tetapi firewall tidak tahu apakah login yang dilakukan itu valid atau mencurigakan.

Di sinilah Fail2Ban melengkapi firewall:

• Firewall = kontrol akses port
• Fail2Ban = kontrol perilaku login

Sesuai pola course ini: gunakan user deploy

Instalasi dilakukan menggunakan user deploy dengan bantuan sudo, bukan login langsung sebagai root.

Cara install Fail2Ban

Login ke server sebagai deploy, lalu jalankan:

sudo apt update
sudo apt install fail2ban -y

Jika instalasi berhasil, Fail2Ban akan otomatis terpasang di server.

Cara mengecek status Fail2Ban

Setelah instalasi, Anda bisa cek apakah service berjalan:

sudo systemctl status fail2ban

Atau cek apakah service aktif:

sudo systemctl is-active fail2ban

Jika status masih inactive, cara mengaktifkan Fail2Ban

Pada beberapa VPS, setelah install Fail2Ban, service belum otomatis berjalan. Jika hasil is-active menunjukkan inactive, maka Anda perlu menyalakannya secara manual.

Jalankan command berikut:

sudo systemctl start fail2ban

Setelah itu, cek kembali statusnya:

sudo systemctl is-active fail2ban

Jika berhasil, hasilnya akan menjadi:

active

Supaya Fail2Ban otomatis aktif saat server restart

Agar Fail2Ban tetap berjalan setiap kali VPS direstart, jalankan:

sudo systemctl enable fail2ban

Catatan penting setelah instalasi

Secara default, Fail2Ban sudah memiliki konfigurasi dasar. Namun biasanya pada tahap production, kita akan melakukan konfigurasi tambahan seperti:

• menentukan berapa kali percobaan login gagal sebelum diblokir,
• berapa lama IP diblokir,
• dan service apa saja yang dimonitor.

Contoh workflow yang benar

1. Login ke VPS sebagai deploy
2. Install Fail2Ban dengan sudo
3. Cek status service
4. Pastikan service berjalan normal
5. Lanjut ke konfigurasi lanjutan di tahap berikutnya (opsional)

Command inti lesson ini

sudo apt update
sudo apt install fail2ban -y
sudo systemctl status fail2ban

Kesimpulan lesson ini

Fail2Ban adalah lapisan keamanan tambahan yang melindungi server dari brute-force attack. Tanpa Fail2Ban, server tetap bisa berjalan, tetapi lebih rentan terhadap percobaan login berulang dari bot internet.

Dengan Fail2Ban, server menjadi lebih “cerdas” dalam menghadapi percobaan login mencurigakan, sehingga keamanan VPS meningkat tanpa konfigurasi yang terlalu kompleks.

Install Node.js

Pada module ini, kita mulai masuk ke stack utama yang dibutuhkan untuk menjalankan LMS berbasis Next.js di VPS. Salah satu komponen paling penting adalah Node.js.

Apa itu Node.js?

Node.js adalah runtime JavaScript yang memungkinkan JavaScript dijalankan di luar browser, termasuk di server. Jadi kalau sebelumnya JavaScript sering kita bayangkan hanya hidup di browser, dengan Node.js kita bisa menjalankan aplikasi JavaScript langsung di Ubuntu VPS.

Peran Node.js secara keseluruhan untuk LMS ini

Dalam context LMS yang sedang kita bangun, Node.js punya peran yang sangat penting karena frontend kita berbasis Next.js, dan Next.js membutuhkan lingkungan Node.js untuk bekerja dengan normal.

Secara praktis, Node.js dibutuhkan untuk:

• menjalankan npm install untuk menginstall dependency project,
• menjalankan npm run build untuk membuat build production,
• menjalankan npm run start untuk menghidupkan aplikasi di server,
• menyediakan runtime agar aplikasi Next.js bisa berjalan.

Kenapa tidak cukup hanya upload source code?

Karena source code Next.js tidak cukup hanya dipindahkan ke server. Server juga harus punya runtime yang bisa memahami dan menjalankan ekosistem JavaScript modern tersebut. Di sinilah Node.js menjadi fondasi utamanya.

Apa yang terjadi jika tanpa Node.js?

Kalau Node.js tidak ada di server, maka workflow deploy LMS akan berhenti di banyak titik penting. Misalnya:

• npm install tidak bisa dijalankan,
• npm run build tidak bisa dijalankan,
• npm run start tidak bisa dijalankan,
• aplikasi Next.js tidak punya runtime untuk berjalan.

Artinya, tanpa Node.js, source code LMS Anda hanya menjadi file project saja di server, tetapi belum bisa benar-benar dijalankan sebagai aplikasi live.

Kenapa memakai Node.js versi LTS?

Untuk server production, kita lebih memilih versi LTS (Long Term Support) karena lebih stabil, lebih aman untuk jangka panjang, dan lebih cocok untuk deployment. Dalam course ini kita memakai pola install dari NodeSource agar versi Node.js yang dipasang lebih terkontrol.

Sesuai pola course ini: gunakan user deploy

Instalasi Node.js dilakukan memakai user deploy lalu menjalankan sudo untuk proses yang membutuhkan hak administratif. Jadi kita tetap tidak membangun kebiasaan login harian sebagai root.

Cara install Node.js LTS

Login ke VPS sebagai deploy, lalu jalankan:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install nodejs -y

Command pertama menambahkan repository NodeSource. Command kedua menginstall paket nodejs.

Kenapa repository NodeSource dipakai?

Karena pada banyak kasus, repository bawaan Ubuntu tidak selalu menyediakan versi Node.js yang paling sesuai dengan kebutuhan project modern. Dengan NodeSource, kita bisa mendapatkan versi Node.js yang lebih cocok untuk stack Next.js yang sedang dipakai.

Hal yang perlu diperhatikan sebelum install

• Pastikan server sudah bisa mengakses internet
• Pastikan curl tersedia di server
• Pastikan package Ubuntu sudah cukup rapi dari lesson update sebelumnya

Jika command curl tidak ditemukan

Pada beberapa VPS minimal, curl belum terinstall. Kalau muncul error seperti curl: command not found, install dulu dengan:

sudo apt update
sudo apt install curl -y

Setelah itu, ulangi command install Node.js tadi.

Setelah install selesai

Setelah Node.js berhasil diinstall, langkah berikutnya adalah memverifikasi bahwa node dan npm benar-benar tersedia di server. Itu akan dibahas di lesson berikutnya.

Command inti lesson ini

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install nodejs -y

Kesimpulan lesson ini

Node.js adalah runtime utama yang membuat LMS berbasis Next.js bisa diinstall, dibuild, dan dijalankan di VPS. Tanpa Node.js, source code LMS tidak bisa berubah menjadi aplikasi live di server. Karena itu, install Node.js LTS adalah langkah fondasi yang wajib sebelum melanjutkan ke tahap build dan run aplikasi.

Verifikasi Node dan npm

Setelah kita selesai menginstall Node.js, langkah berikutnya yang sangat penting adalah melakukan verifikasi.

Verifikasi ini memastikan bahwa Node.js dan npm benar-benar sudah terinstall dengan benar, bisa dijalankan, dan siap digunakan untuk menjalankan LMS kita.

Kenapa perlu verifikasi?

Banyak orang langsung lanjut ke step berikutnya tanpa verifikasi. Ini sering jadi sumber error di belakang.

• Memastikan instalasi berhasil — bukan hanya sekadar selesai tanpa error.
• Memastikan command tersedia — Node dan npm bisa dipanggil dari terminal.
• Menghindari error di step berikutnya — terutama saat install dependency project.
• Memberi kepastian environment — kita tahu versi yang sedang dipakai.

Apa itu Node.js dan npm (untuk pemula)

Node.js adalah runtime JavaScript yang memungkinkan kita menjalankan JavaScript di server.

npm (Node Package Manager) adalah tool untuk menginstall library/package yang dibutuhkan oleh aplikasi kita.

Dalam konteks LMS:

• Node.js menjalankan backend atau build system
• npm menginstall dependency seperti framework, library, dan tools

Langkah 1: cek versi Node.js

Jalankan command berikut:

node -v

Contoh output:

v20.10.0

Artinya:

• Node.js sudah terinstall
• Versi yang aktif adalah versi tersebut

Langkah 2: cek versi npm

Jalankan:

npm -v

Contoh output:

10.2.3

Artinya npm juga sudah siap digunakan.

Langkah 3: cek lokasi instalasi (optional, untuk intermediate/expert)

Untuk memastikan Node dan npm terinstall di path yang benar:

which node
which npm

Contoh output:

/usr/bin/node
/usr/bin/npm

Ini penting untuk memastikan tidak ada konflik instalasi (misalnya antara system install vs nvm).

Langkah 4: cek versi detail Node.js

Untuk melihat informasi lebih lengkap:

node -p "process.versions"

Ini biasanya akan menampilkan informasi seperti:

{
  node: '20.x.x',
  v8: '...',
  uv: '...',
  openssl: '...'
}

Untuk pemula, ini tidak wajib dipahami sekarang, tetapi bagus untuk diketahui.

Bagaimana jika command tidak dikenali?

Jika Anda mendapatkan error seperti:

command not found: node

Artinya Node.js belum terinstall dengan benar atau PATH belum terbaca.

Solusi umum:

• Pastikan instalasi Node.js sudah selesai tanpa error
• Logout lalu login ulang ke server
• Cek kembali dengan node -v

Bagaimana jika npm tidak ada?

Jika node -v berhasil tetapi npm -v gagal:

• Instalasi Node.js kemungkinan tidak lengkap
• Gunakan installer resmi Node.js (LTS) yang sudah include npm

Versi berapa yang sebaiknya digunakan?

Untuk production, gunakan versi LTS (Long Term Support).

Contoh:

• Node.js 18 LTS
• Node.js 20 LTS

Hindari versi experimental untuk server production.

Apakah perlu update Node.js sekarang?

Tidak perlu langsung update jika versi yang terinstall sudah LTS dan stabil.

Ringkasan verifikasi cepat

node -v
npm -v
which node
which npm

Jika semua command di atas berjalan tanpa error, berarti environment Node.js Anda sudah siap.

Kesimpulan

Verifikasi Node.js dan npm adalah langkah sederhana tetapi sangat penting.

Dengan memastikan versi, lokasi, dan availability command, kita menghindari banyak error di tahap berikutnya.

Di lesson berikutnya, kita akan mulai menggunakan Node.js untuk menjalankan aplikasi LMS.

Install Nginx

Setelah Node.js terinstall, langkah berikutnya adalah memasang Nginx. Dalam konteks LMS ini, Nginx akan menjadi web server yang menerima request dari browser, lalu nantinya meneruskan request tersebut ke aplikasi LMS yang berjalan di port internal.

Untuk pemula, bayangkan Nginx sebagai pintu depan website. Orang luar masuk dari browser ke Nginx, lalu Nginx meneruskan ke aplikasi kita di dalam server.

Untuk yang sudah lebih advance, Nginx di sini akan berperan sebagai web server dan reverse proxy untuk aplikasi Node.js / Next.js.

Kenapa perlu Nginx?

• Membuka website ke publik dengan cara yang lebih standar.
• Meneruskan request ke aplikasi LMS yang berjalan di port internal seperti 3000.
• Memudahkan domain dan SSL di langkah berikutnya.
• Lebih cocok untuk production mindset dibanding langsung mengekspos aplikasi Node.js ke internet.

Langkah 1: cek apakah Nginx sudah ada

Sebelum install, cek dulu apakah Nginx sudah terpasang:

nginx -v

Kalau Nginx sudah ada, biasanya akan muncul output seperti:

nginx version: nginx/1.18.0 (Ubuntu)

Kalau command tidak dikenali, berarti Nginx belum terinstall dan kita perlu memasangnya.

Langkah 2: install Nginx jika belum ada

Gunakan command berikut:

sudo apt install nginx -y

Kalau package belum ditemukan, refresh repository Ubuntu terlebih dahulu:

sudo apt update

Lalu jalankan lagi:

sudo apt install nginx -y

Langkah 3: verifikasi binary Nginx

Setelah install selesai, cek lagi:

nginx -v

Kalau versi muncul, berarti paket Nginx sudah terinstall dengan benar.

Langkah 4: cek status service Nginx

Karena Nginx adalah service sistem, kita juga perlu memeriksa apakah service-nya berhasil berjalan:

sudo systemctl status nginx

Kalau normal, biasanya akan terlihat status seperti:

Active: active (running)

Namun, pada kasus nyata di VPS, ada kemungkinan Nginx sudah terinstall tetapi gagal start.

Kasus nyata: Nginx terinstall, tetapi service gagal start

Contoh kasus yang bisa terjadi:

nginx -v
nginx version: nginx/1.18.0 (Ubuntu)

Tetapi saat dicek:

sudo systemctl status nginx

Muncul indikasi seperti:

Active: failed (Result: exit-code)

Kalau ini terjadi, artinya masalahnya bukan di instalasi paket, tetapi biasanya di konfigurasi atau port bentrok dengan service lain.

Langkah diagnosis yang disarankan

Untuk melihat apakah port HTTP/HTTPS sedang dipakai service lain, jalankan:

sudo ss -tulpn | grep ':80\|:443'

Kalau pada output terlihat Apache2 memakai port 80, misalnya seperti ini:

tcp   LISTEN 0      128      0.0.0.0:80      0.0.0.0:*    users:(("apache2",pid=4497,fd=3),("apache2",pid=4495,fd=3))

Artinya, Apache2 sedang aktif dan sudah mengambil port 80, sehingga Nginx gagal start karena tidak bisa memakai port yang sama.

Sebelum start ulang Nginx, cek juga syntax konfigurasi Nginx:

sudo nginx -t

Kalau output menunjukkan syntax OK, maka fokus masalahnya memang biasanya bentrok port.

Resolusi kasus: Apache2 memakai port 80

Kalau memang ingin memakai Nginx sebagai web server utama untuk LMS ini, maka Apache2 perlu dihentikan dan dinonaktifkan.

Gunakan alur berikut:

sudo ss -tulpn | grep ':80\|:443'

sudo nginx -t

sudo systemctl stop apache2
sudo systemctl disable apache2
sudo systemctl start nginx
sudo systemctl status nginx

Setelah itu, cek lagi status Nginx. Kalau berhasil, status biasanya berubah menjadi active (running).

Apa fungsi Apache2 yang di-disable itu?

Apache2 adalah web server, sama seperti Nginx. Fungsinya juga bisa melayani website, menerima request HTTP, dan menampilkan aplikasi ke internet.

Masalahnya, dalam satu server, dua web server tidak bisa memakai port publik yang sama secara bersamaan, misalnya sama-sama ingin memakai port 80.

Jadi saat Apache2 di-disable dalam lesson ini, maksudnya adalah kita memilih Nginx sebagai web server utama agar tidak bentrok.

Apa dampaknya jika Apache2 di-disable?

• Website atau service yang sebelumnya dilayani Apache2 akan berhenti dilayani oleh Apache2.
• Port 80 menjadi kosong sehingga bisa dipakai Nginx.
• Tidak ada dampak negatif untuk LMS ini selama memang kita memilih Nginx sebagai web server utama.
• Kalau server masih dipakai untuk website lain yang bergantung pada Apache2, maka website tersebut bisa ikut terganggu. Karena itu, pastikan Apache2 memang tidak sedang dipakai untuk kebutuhan lain.

Dalam flow course ini, kita memang sedang membangun stack deployment berbasis Nginx + Node.js, jadi menonaktifkan Apache2 adalah langkah yang wajar bila Apache2 hanya menjadi pengganggu port.

Versi video

Kalau ingin melihat panduan pendamping dalam bentuk video, gunakan link berikut:

Tonton video pendamping lesson Install Nginx

Kesimpulan lesson ini

Nginx adalah bagian penting dari deployment LMS di VPS. Yang perlu kita pelajari bukan hanya cara menginstallnya, tetapi juga cara melihat statusnya, cara menguji konfigurasinya, dan cara menyelesaikan konflik port bila ada web server lain seperti Apache2 yang sudah aktif lebih dulu.

Dengan begitu, kita tidak hanya berhasil install, tetapi juga benar-benar mengerti kenapa service bisa gagal start dan bagaimana cara memulihkannya.

Test Nginx di browser

Setelah Nginx berhasil diinstall dan service-nya aktif, langkah berikutnya adalah mengujinya langsung dari browser. Ini penting supaya kita tahu bahwa web server benar-benar bisa diakses dari luar server, bukan hanya terlihat aktif dari terminal.

Untuk pemula, anggap langkah ini sebagai tes pintu depan website. Kalau browser bisa menampilkan halaman default Nginx, berarti server sudah siap masuk ke tahap berikutnya seperti reverse proxy, domain, dan SSL.

Untuk yang sudah lebih advance, ini adalah verifikasi sederhana bahwa:

• service Nginx benar-benar berjalan,
• port HTTP bisa diakses,
• server merespons request dari jaringan luar,
• dan belum ada masalah besar di layer awal web serving.

Yang perlu dipastikan sebelum test di browser

Sebelum membuka browser, cek dulu status Nginx:

sudo systemctl status nginx

Kalau normal, biasanya akan terlihat status seperti:

Active: active (running)

Kalau Nginx belum aktif, jalankan:

sudo systemctl start nginx

Lalu cek lagi:

sudo systemctl status nginx

Cek syntax konfigurasi Nginx

Sebelum test dari browser, biasakan juga mengecek konfigurasi Nginx:

sudo nginx -t

Kalau hasilnya menunjukkan syntax OK dan test successful, berarti konfigurasi dasar Nginx aman untuk dipakai.

Langkah utama: buka IP VPS di browser

Setelah itu, buka browser di komputer Anda, lalu akses IP public VPS:

http://IP_VPS_ANDA

Contoh:

http://123.123.123.123

Kalau semua normal, browser biasanya menampilkan halaman default Nginx. Ini adalah tanda yang sangat bagus, karena artinya:

• Nginx berhasil berjalan,
• port HTTP terbuka dan bisa diakses,
• server sudah siap untuk konfigurasi berikutnya.

Bagaimana kalau halaman tidak muncul?

Kalau browser tidak menampilkan halaman default Nginx, jangan langsung panik. Cek beberapa hal berikut secara berurutan.

1. Pastikan Nginx benar-benar running

sudo systemctl status nginx

2. Pastikan tidak ada konflik port 80 atau 443

sudo ss -tulpn | grep ':80\|:443'

Kalau sebelumnya Apache2 sempat aktif, pastikan Apache2 sudah tidak lagi memakai port 80.

3. Pastikan konfigurasi Nginx valid

sudo nginx -t

4. Restart Nginx jika perlu

sudo systemctl restart nginx

Lalu cek lagi statusnya:

sudo systemctl status nginx

5. Test dari browser lagi

http://IP_VPS_ANDA

Troubleshooting nyata: Nginx aktif, tetapi browser tetap tidak bisa dibuka

Dalam praktik nyata, ada kasus seperti ini:

• sudo systemctl status nginx sudah menunjukkan Active: active (running)
• bahkan ada log seperti Started A high performance web server and a reverse proxy server
• tetapi saat IP VPS dibuka di browser, halaman tetap tidak muncul

Kalau ini terjadi, artinya Nginx di dalam server kemungkinan besar sudah sehat, tetapi akses dari luar server masih terhalang.

1. Kalau systemctl status tidak langsung kembali ke prompt

Untuk pemula, ini sering terasa seperti error, padahal sebenarnya normal. Saat menjalankan:

sudo systemctl status nginx

Linux biasanya menampilkan output melalui pager. Karena itu terminal tidak langsung balik ke prompt. Kalau sudah selesai membaca, cukup tekan:

q

Kalau ingin status tampil tanpa masuk ke tampilan pager, gunakan:

sudo systemctl status nginx --no-pager

2. Pastikan Nginx benar-benar listen di port web

Gunakan command berikut:

sudo ss -tulpn | grep ':80\|:443'

Command ini membantu melihat apakah port HTTP atau HTTPS sedang dipakai, dan oleh proses apa.

3. Pastikan dari dalam VPS sendiri, Nginx memang merespons

curl -I http://localhost

Kalau hasilnya HTTP/1.1 200 OK, berarti Nginx di sisi internal VPS sebenarnya sudah bekerja dengan baik.

4. Cek firewall Ubuntu

sudo ufw status

Kalau port 80 dan 443 belum diizinkan, browser dari luar bisa gagal mengakses server walaupun Nginx sebenarnya aktif.

5. Buka akses web di firewall

sudo ufw allow 'Nginx Full'

Rule ini biasanya membuka port HTTP dan HTTPS untuk Nginx. Setelah itu, cek lagi:

sudo ufw status

Kalau sudah benar, coba buka lagi:

http://IP_VPS_ANDA

Apakah perlu install browser di VPS?

Tidak perlu. Yang kita uji di lesson ini adalah akses dari browser di komputer kita menuju VPS melalui jaringan internet.

Jadi tidak ada browser khusus yang perlu diinstall di Ubuntu server hanya untuk test ini.

Verifikasi tambahan untuk intermediate dan expert

Kalau ingin verifikasi dari sisi terminal server, Anda bisa cek apakah Nginx sedang listen di port HTTP:

sudo ss -tulpn | grep ':80\|:443'

Kalau Nginx aktif, biasanya akan terlihat bahwa proses Nginx sedang listen di port 80, dan nanti juga bisa di port 443 setelah SSL dipasang.

Versi video

Kalau ingin melihat materi pendamping dalam bentuk video, putar video berikut:

Ringkasan alur aman

sudo systemctl status nginx
q
sudo systemctl status nginx --no-pager
sudo nginx -t
sudo ss -tulpn | grep ':80\|:443'
curl -I http://localhost
sudo ufw status
sudo ufw allow 'Nginx Full'
http://IP_VPS_ANDA

Kesimpulan lesson ini

Kalau halaman default Nginx berhasil muncul di browser, berarti server web Anda sudah berada di jalur yang benar. Ini adalah checkpoint penting sebelum LMS benar-benar diarahkan ke domain dan aplikasi Node.js di belakang Nginx.

Dengan kata lain, lesson ini membantu kita memastikan bahwa Nginx bukan hanya terinstall, tetapi juga benar-benar hidup dan bisa diakses dari luar.

Upload Source Code dari Localhost ke VPS

Setelah server siap (Node.js dan Nginx sudah berjalan), langkah berikutnya adalah memindahkan source code aplikasi LMS dari komputer lokal ke VPS.

Untuk pemula, ini berarti: meng-copy project dari laptop ke server.

Untuk yang lebih advance, ini adalah bagian dari proses deployment: memindahkan codebase ke environment production.

Kenapa perlu upload source code?

• Aplikasi hanya bisa berjalan jika code ada di server
• Server tidak otomatis punya code dari localhost
• Langkah awal sebelum install dependency dan run aplikasi

Metode upload yang umum

• SCP (Secure Copy)
• SFTP (via tools seperti WinSCP / FileZilla)
• Git clone (untuk workflow yang lebih advanced)

Di lesson ini kita fokus ke metode yang paling mudah: SCP.

Langkah 1: pastikan folder project di localhost

Pastikan Anda tahu lokasi project di komputer Anda.

Contoh:

C:\projects\lms

Langkah 2: upload menggunakan SCP

Dari terminal lokal (bukan VPS), jalankan:

scp -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Penjelasan:

• -r → recursive (copy semua folder)
• ./lms → folder lokal
• deploy@IP → user VPS
• /home/deploy → tujuan di VPS

Flow 1: upload dengan password

Kalau VPS Anda masih menggunakan login password biasa, saat menjalankan SCP biasanya Anda akan diminta memasukkan password user tujuan.

Contohnya:

scp -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Lalu terminal bisa menampilkan prompt seperti:

deploy@IP_VPS_ANDA's password:

Masukkan password user deploy, lalu proses upload akan berjalan.

Untuk pemula, ini normal. Jadi benar, walaupun command SCP tidak menuliskan password di dalam command, autentikasi tetap terjadi melalui password SSH.

Flow 2: upload dengan SSH key

Untuk workflow yang lebih aman dan lebih nyaman, kita bisa menggunakan SSH key. Dengan metode ini, SCP tidak perlu meminta password setiap kali, selama key sudah terpasang dengan benar di server.

Kalau key default Anda sudah aktif di sistem, biasanya cukup:

scp -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Kalau ingin menentukan file key secara eksplisit, gunakan:

scp -i ~/.ssh/id_rsa -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Di beberapa sistem modern, nama file key bisa juga berupa id_ed25519. Jadi sesuaikan dengan key yang Anda miliki.

Untuk learner yang sudah lebih advance, metode SSH key sangat direkomendasikan karena:

• lebih aman dibanding password biasa,
• lebih cepat untuk workflow berulang,
• lebih cocok untuk deployment production.

Flow 3: upload jika SSH memakai port custom

Dalam banyak VPS, SSH tidak selalu memakai port default 22. Ada yang memakai port custom, misalnya 2203.

Kalau SSH Anda memakai port custom, maka command SCP juga harus ikut memakai port tersebut.

Contohnya:

scp -P 2203 -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Perhatikan bahwa untuk SCP, option port menggunakan huruf besar -P, bukan huruf kecil.

Kalau Anda memakai SSH key sekaligus port custom, bentuknya bisa seperti ini:

scp -P 2203 -i ~/.ssh/id_rsa -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Ini adalah kombinasi yang sangat umum untuk server production.

Kalau SCP belum ada?

Di Linux dan macOS biasanya sudah ada.

Kalau di Windows:

• Gunakan PowerShell modern
• Atau gunakan Git Bash

Cara cek dulu apakah koneksi SSH ke VPS sudah benar

Sebelum upload dengan SCP, sangat disarankan untuk test koneksi SSH terlebih dahulu.

Kalau memakai port default:

ssh deploy@IP_VPS_ANDA

Kalau memakai port custom 2203:

ssh -p 2203 deploy@IP_VPS_ANDA

Kalau SSH berhasil login, biasanya SCP juga akan jauh lebih mudah berhasil. Ini membantu kita memastikan bahwa user, password, key, dan port memang sudah benar sebelum mulai upload file.

Langkah 3: verifikasi file di VPS

Masuk ke VPS:

ssh deploy@IP_VPS_ANDA

Lalu cek folder:

ls -la

Masuk ke project:

cd lms

Cek isi folder:

ls -la

Kalau file muncul, berarti upload berhasil.

Langkah 4: cek ukuran dan struktur (optional)

du -sh lms

Ini membantu memastikan semua file ikut ter-copy.

Troubleshooting umum

1. Permission denied

Biasanya karena:

• user salah
• password salah
• folder tujuan tidak punya izin tulis
• SSH key tidak cocok dengan server

2. Connection timeout

Biasanya karena:

• port SSH salah
• firewall blok
• IP VPS salah

3. SCP gagal karena SSH sebenarnya memakai port custom

Ini kasus yang sangat sering terjadi. SSH bisa sukses di PuTTY karena Anda sudah mengisi port custom, misalnya 2203, tetapi SCP gagal karena command masih mencoba port default 22.

Solusinya, tambahkan port custom secara eksplisit:

scp -P 2203 -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

3. Upload sangat lama

Biasanya karena:

• banyak file kecil (node_modules)

Solusi:

• Jangan upload node_modules
• Gunakan .gitignore

4. Terminal meminta password terus walaupun merasa sudah pakai key

Biasanya ini berarti key belum terbaca, nama file key salah, atau public key belum terpasang di server.

Coba tentukan key secara eksplisit:

scp -i ~/.ssh/id_rsa -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Kalau masih gagal, cek kembali konfigurasi SSH key di server.

Best practice penting

Kenapa node_modules tidak boleh di-upload (real production rule)

Ini adalah salah satu aturan penting dalam deployment Node.js yang sering dilewatkan pemula.

Saat kita bekerja di localhost, folder node_modules biasanya terbentuk setelah menjalankan npm install. Folder ini berisi semua dependency project. Walaupun terlihat praktis untuk langsung ikut di-copy ke VPS, dalam praktik production hal itu tidak disarankan.

Ada beberapa alasan penting:

• Environment lokal dan server bisa berbeda — misalnya localhost memakai Windows, sedangkan VPS memakai Ubuntu Linux. Beberapa package Node.js memiliki binary atau dependency native yang bisa berbeda antar sistem operasi.
• Ukuran folder sangat besar — node_modules sering berisi ribuan file kecil. Ini membuat proses upload menjadi jauh lebih lama dan tidak efisien.
• Lebih rawan error — dependency yang berhasil di localhost belum tentu sehat saat dipindahkan mentah-mentah ke server.
• Bukan workflow production yang rapi — server seharusnya menginstall dependency sendiri berdasarkan package.json dan package-lock.json.

Jadi, pola yang benar adalah:

1. Upload hanya source code project
2. Jangan ikut upload node_modules
3. Masuk ke VPS
4. Jalankan npm install langsung di VPS

Contoh alur yang lebih tepat:

scp -P 2203 -r ./lms deploy@IP_VPS_ANDA:/home/deploy/
ssh -p 2203 deploy@IP_VPS_ANDA
cd /home/deploy/lms
npm install

Selain node_modules, biasanya folder hasil build seperti .next, dist, build, atau cache lain juga sebaiknya tidak ikut di-upload, kecuali memang ada workflow khusus yang sengaja mengharuskannya.

Untuk course ini, biasakan mindset berikut:

Server bukan salinan mentah dari laptop kita. Server adalah environment baru yang harus menerima source code bersih, lalu membangun dependency sendiri.

Itulah sebabnya rule “jangan upload node_modules” adalah salah satu kebiasaan penting yang membedakan workflow pemula dan workflow production yang lebih profesional.

3 cara upload yang benar: SCP vs RSYNC vs ZIP

Setelah memahami bahwa tidak semua file boleh ikut dikirim ke server, sekarang kita perlu mengenal tiga pendekatan upload yang paling umum. Ketiganya sama-sama bisa dipakai, tetapi masing-masing punya karakter yang berbeda.

1. SCP — paling mudah untuk mulai

SCP adalah cara yang paling cepat dipahami oleh pemula. Konsepnya sederhana: copy folder atau file dari localhost ke VPS melalui koneksi SSH.

Contoh:

scp -P 2203 -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Kelebihan SCP:

• mudah dipelajari,
• langsung tersedia di banyak sistem,
• cocok untuk upload awal yang sederhana.

Kekurangan SCP:

• tidak fleksibel untuk exclude file/folder tertentu,
• kurang efisien kalau project sering berubah,
• kurang nyaman untuk sinkronisasi berulang.

2. RSYNC — lebih rapi untuk workflow production

RSYNC sangat populer untuk deployment karena bisa melakukan sinkronisasi file dengan lebih efisien, termasuk mengecualikan folder seperti node_modules atau .next.

Contoh:

rsync -avz -e "ssh -p 2203"   --exclude 'node_modules'   --exclude '.next'   --exclude 'dist'   ./lms/ deploy@IP_VPS_ANDA:/home/deploy/lms/

Kelebihan RSYNC:

• bisa exclude file/folder yang tidak perlu,
• lebih efisien untuk update berulang,
• lebih cocok untuk workflow production yang rapi.

Kekurangan RSYNC:

• sedikit lebih teknis untuk pemula,
• tidak selalu langsung tersedia di semua environment Windows tanpa tool tambahan.

3. ZIP — aman dan mudah dipahami

Pendekatan ketiga adalah membuat arsip .zip dari source code yang sudah bersih, lalu mengupload satu file zip ke VPS, kemudian mengekstraknya di server.

Contoh alur:

zip -r lms.zip lms -x "lms/node_modules/*" "lms/.next/*"
scp -P 2203 lms.zip deploy@IP_VPS_ANDA:/home/deploy/
ssh -p 2203 deploy@IP_VPS_ANDA
cd /home/deploy
unzip lms.zip

Kelebihan ZIP:

• lebih aman untuk pemula karena file yang dikirim hanya satu arsip,
• lebih mudah dikontrol isinya sebelum upload,
• cocok kalau ingin memastikan hanya source code bersih yang terkirim.

Kekurangan ZIP:

• butuh langkah tambahan zip dan unzip,
• kurang praktis untuk sinkronisasi berkali-kali.

Untuk course ini, cara termudah untuk mulai adalah SCP. Tetapi untuk workflow yang lebih rapi dan lebih mendekati production, RSYNC biasanya lebih unggul. Sementara itu, ZIP adalah jalan tengah yang aman dan mudah dipahami oleh banyak learner.

Daftar folder yang wajib di-exclude (Node.js & Next.js)

Setelah memahami cara upload yang benar, kita juga perlu tahu folder dan file mana yang sebaiknya tidak ikut dikirim ke VPS. Ini sangat penting agar upload tetap ringan, aman, dan sesuai workflow production.

Minimal yang hampir selalu di-exclude

Untuk project Node.js atau Next.js, tiga folder ini hampir selalu menjadi daftar paling dasar:

• node_modules — berisi dependency hasil npm install di lokal
• .next — berisi hasil build Next.js
• dist — berisi hasil build untuk beberapa jenis project

Kenapa tiga folder ini sebaiknya tidak ikut di-upload?

• ukurannya sering besar,
• isinya bisa berbeda antara Windows dan Linux,
• lebih aman dibangun ulang di VPS, bukan dipindahkan mentah dari localhost.

Daftar exclude yang sering direkomendasikan

Selain tiga folder utama di atas, dalam banyak project production kita juga sering mengecualikan hal-hal berikut:

• .git — metadata repository Git, biasanya tidak dibutuhkan jika tidak deploy lewat Git langsung di server
• .env — file sensitif yang sebaiknya dibuat langsung di server
• .env.local dan file environment lokal lain — umumnya khusus untuk localhost
• coverage — hasil test coverage, tidak dibutuhkan untuk runtime aplikasi
• .cache — file cache lokal, tidak penting untuk deployment bersih
• logs atau folder log lokal — tidak perlu ikut dari laptop ke server
• tmp — folder sementara yang tidak perlu dibawa ke production
• out — hasil output tertentu dari Next.js atau static export, tergantung workflow project

Intinya, yang kita kirim ke VPS sebaiknya adalah source code bersih, bukan hasil build lokal, cache, atau file sensitif.

Peran .gitignore

Dalam banyak project modern, file .gitignore bisa menjadi panduan awal yang sangat membantu untuk menentukan apa yang sebaiknya tidak ikut dikirim ke server.

Contoh isi .gitignore yang umum untuk project Node.js / Next.js:

node_modules
.next
dist
.env
.env.local
coverage
.cache
logs
tmp
out

Kalau suatu file atau folder sudah masuk ke .gitignore, itu sering menjadi sinyal bahwa item tersebut memang tidak perlu ikut ke VPS melalui workflow upload biasa.

Namun, ada satu hal penting: SCP tidak bisa membaca .gitignore. Jadi walaupun project Anda sudah punya .gitignore, SCP tetap akan meng-copy semua file kecuali Anda sendiri yang membersihkannya atau memakai metode lain.

Kalau ingin memakai rule dari .gitignore, gunakan apa?

Kalau ingin pendekatan yang lebih production-grade, RSYNC jauh lebih cocok karena bisa membaca file exclude.

Contohnya:

rsync -avz -e "ssh -p 2203"   --exclude-from='.gitignore'   ./lms/ deploy@IP_VPS_ANDA:/home/deploy/lms/

Dengan pendekatan ini, learner tidak perlu menulis semua rule exclude satu per satu selama .gitignore project-nya memang sudah rapi.

Rule sederhana yang mudah diingat

Untuk lesson ini, biasakan prinsip berikut:

• Upload source code
• Jangan upload dependency lokal
• Jangan upload hasil build lokal
• Jangan upload file sensitif seperti .env
• Gunakan .gitignore sebagai referensi awal

Perbedaan command Linux vs PowerShell (multi-line rsync)

Untuk learner yang menggunakan Windows + PuTTY, ada satu hal penting yang sering menyebabkan error saat menulis command panjang seperti rsync, yaitu perbedaan cara membuat multi-line command.

Di Linux / macOS (bash)

Pada terminal Linux atau macOS, kita bisa memecah command ke beberapa baris menggunakan karakter di akhir baris.

rsync -avz \
  --exclude 'node_modules' \
  --exclude '.next' \
  --exclude 'dist' \
  ./lms/ deploy@IP_VPS_ANDA:/home/deploy/lms/

Karakter ini berarti “lanjut ke baris berikutnya”.

Di PowerShell (Windows)

Di PowerShell, karakter tidak berfungsi sebagai multi-line. Sebagai gantinya, PowerShell menggunakan backtick, yaitu karakter `.

rsync -avz -e "ssh -p 2203" `
  --exclude "node_modules" `
  --exclude ".next" `
  --exclude "dist" `
  ./lms/ deploy@IP_VPS_ANDA:/home/deploy/lms/

Perhatikan hal penting berikut:

• Backtick harus berada di akhir baris
• Tidak boleh ada spasi setelah backtick

Alternatif paling aman (satu baris)

Kalau masih ragu atau sering error, gunakan command dalam satu baris:

rsync -avz -e "ssh -p 2203" --exclude "node_modules" --exclude ".next" --exclude "dist" ./lms/ deploy@IP_VPS_ANDA:/home/deploy/lms/

Ini biasanya lebih aman untuk pemula karena menghindari kesalahan format multi-line.

Ringkasan perbedaan

• Linux/macOS → gunakan untuk multi-line
• PowerShell → gunakan ` untuk multi-line
• CMD Windows → tidak mendukung multi-line dengan cara ini

Memahami perbedaan ini sangat penting agar command yang terlihat benar tidak gagal hanya karena perbedaan shell.

Struktur folder yang benar di VPS untuk Node.js app

Setelah source code berhasil dipindahkan ke server, kita juga perlu memahami di mana sebaiknya project disimpan. Ini terlihat sederhana, tetapi sangat berpengaruh pada kerapian deployment, permission, dan kemudahan maintenance.

Pilihan yang aman untuk course ini

Untuk workflow yang sedang kita bangun, lokasi yang aman dan natural adalah:

/home/deploy/lms

Kenapa ini pilihan yang baik?

• Sesuai dengan user yang dipakai — kita bekerja menggunakan user deploy, jadi project disimpan di home directory user tersebut.
• Permission lebih aman — user deploy bisa membaca, menulis, dan menjalankan project tanpa harus memakai sudo terus-menerus.
• Lebih rapi untuk maintenance — semua file aplikasi berada di tempat yang jelas.
• Cocok untuk Node.js app — aplikasi tidak perlu dijalankan dari folder sistem sensitif.

Contoh struktur yang rapi

/home/deploy/
├── lms/
├── logs/
└── backups/

Dengan pola seperti ini, learner bisa lebih mudah membedakan:

• folder aplikasi utama,
• folder log,
• dan folder backup bila nanti dibutuhkan.

Kenapa tidak disarankan di /root/?

Menyimpan aplikasi di /root/ memang mungkin dilakukan, tetapi tidak disarankan untuk workflow normal. Folder ini milik user root dan terlalu sensitif untuk dipakai sebagai tempat kerja harian aplikasi.

Kalau aplikasi ditempatkan di sana, learner akan lebih sering tergoda memakai sudo atau bahkan menjalankan app sebagai root, padahal itu bukan kebiasaan yang baik untuk production.

Kenapa tidak langsung di /var/www/?

Folder /var/www/ sering dipakai untuk website berbasis web server tradisional seperti Apache atau Nginx yang langsung melayani file web. Untuk Node.js app modern, terutama yang nanti dijalankan dengan process manager seperti PM2, menyimpan code di /home/deploy/lms biasanya terasa lebih natural dan lebih mudah dikelola.

Rule sederhana yang mudah diingat

• Jalankan app sebagai user biasa, bukan root
• Simpan project di home directory user deploy
• Gunakan struktur folder yang mudah dipahami

Untuk course ini, kita gunakan pola yang sederhana dan aman:

/home/deploy/lms

Pola ini cukup bersih untuk belajar, cukup aman untuk production ringan, dan cukup rapi untuk dibawa ke workflow yang lebih enterprise di tahap berikutnya.

Kenapa rsync tidak ada di Windows (dan solusinya)

Saat mencoba menjalankan rsync di PowerShell, sebagian learner akan melihat error seperti:

The term 'rsync' is not recognized as the name of a cmdlet

Ini bukan kesalahan command. Di Windows, rsync memang tidak tersedia secara default. Berbeda dengan Linux atau macOS yang biasanya sudah memiliki rsync bawaan.

Kenapa ini terjadi?

• PowerShell dan CMD tidak menyertakan rsync secara default
• rsync adalah tool khas lingkungan Unix/Linux
• Karena itu, command yang valid di Linux bisa terlihat error di Windows

Solusi 1 — gunakan Git Bash (paling mudah)

Jika Anda sudah menginstall Git di Windows, biasanya Anda juga memiliki Git Bash. Buka Git Bash, lalu jalankan:

rsync -avz \
  --exclude 'node_modules' \
  --exclude '.next' \
  ./lms/ deploy@IP_VPS_ANDA:/home/deploy/lms/

Git Bash menyediakan environment yang lebih mirip Linux, sehingga command seperti rsync bisa digunakan dengan lebih natural.

Solusi 2 — gunakan WSL (Windows Subsystem for Linux)

Jika ingin environment yang benar-benar mirip server Linux, gunakan WSL. Setelah masuk ke WSL, install rsync:

sudo apt update
sudo apt install rsync -y

Setelah itu, jalankan command rsync seperti di Linux biasa.

Solusi 3 — gunakan SCP (alternatif paling sederhana)

Jika belum ingin menambah tool baru, gunakan scp yang sudah cukup untuk tahap awal:

scp -P 2203 -r ./lms deploy@IP_VPS_ANDA:/home/deploy/

Metode ini tidak sefleksibel rsync, tetapi cukup untuk upload pertama kali.

Ringkasan pilihan

• SCP → paling sederhana untuk mulai
• Git Bash + rsync → lebih fleksibel tanpa setup berat
• WSL + rsync → paling mendekati environment production

Untuk learner Windows + PuTTY, memahami perbedaan ini sangat penting agar tidak merasa command salah, padahal sebenarnya hanya berbeda environment.

Mapping path Windows ke WSL (biar tidak salah path)

Saat menggunakan WSL, salah satu hal yang paling sering membuat learner bingung adalah perbedaan path antara Windows dan Linux.

Contoh kasus

Di Windows, project biasanya berada di:

C:\projects\html\lms

Namun di dalam WSL, path tersebut berubah menjadi:

/mnt/c/projects/html/lms

Ini karena WSL melakukan mapping drive Windows ke dalam struktur Linux:

• C: → /mnt/c
• D: → /mnt/d

Langkah yang benar sebelum menjalankan rsync

Masuk ke folder project terlebih dahulu di WSL:

cd /mnt/c/projects/html/lms

Setelah itu, jalankan rsync dari dalam folder tersebut:

rsync -avz \
  --exclude 'node_modules' \
  --exclude '.next' \
  ./ deploy@IP_VPS_ANDA:/home/deploy/lms/

Alternatif tanpa cd

Kalau tidak ingin berpindah folder, Anda juga bisa langsung menggunakan path lengkap:

rsync -avz \
  --exclude 'node_modules' \
  /mnt/c/projects/html/lms/ \
  deploy@IP_VPS_ANDA:/home/deploy/lms/

Kesalahan yang sering terjadi

Banyak learner mencoba menggunakan path Windows langsung di WSL, seperti:

C:\projects\html\lms

Ini tidak akan bekerja di WSL. Gunakan selalu format Linux seperti /mnt/c/....

Tips performa (optional)

WSL tetap bisa membaca file dari /mnt/c, tetapi untuk project besar, akses bisa sedikit lebih lambat dibanding file yang berada langsung di dalam filesystem Linux WSL.

Untuk penggunaan lebih lanjut, Anda bisa mempertimbangkan menyimpan project di:

/home/username/lms

Namun untuk course ini, menggunakan /mnt/c/projects/html/lms sudah cukup aman dan mudah dipahami.

Ringkasan mapping

• Windows: C:\projects\html\lms
• WSL: /mnt/c/projects/html/lms

Memahami mapping ini sangat penting agar command seperti rsync tidak gagal hanya karena salah path.

Apakah folder tujuan perlu dibuat dulu?

Saat menjalankan perintah seperti rsync atau scp, learner sering bertanya apakah folder tujuan di VPS harus dibuat terlebih dahulu.

Jawaban singkat

Tidak wajib. Dalam banyak kasus, rsync akan otomatis membuat folder tujuan jika belum ada, selama user yang digunakan memiliki izin akses ke parent directory.

Contoh kasus

Jika Anda menjalankan:

rsync -avz -e "ssh -p 2203"   --exclude-from='.gitignore'   ./ deploy@IP_VPS_ANDA:/home/deploy/lms/

Jika folder /home/deploy/lms belum ada, maka biasanya akan dibuat otomatis oleh rsync, lalu file akan langsung di-copy ke dalamnya.

Kapan bisa gagal?

• Jika user tidak memiliki izin ke folder parent (misalnya mencoba menulis ke /root/)
• Jika path tujuan salah atau tidak valid

Best practice

Walaupun bisa otomatis, dalam workflow yang lebih rapi biasanya kita tetap membuat folder secara eksplisit agar struktur server lebih jelas.

ssh -p 2203 deploy@IP_VPS_ANDA
mkdir -p /home/deploy/lms

Setelah itu baru jalankan rsync. Cara ini membantu memastikan bahwa struktur folder di VPS sesuai dengan yang kita rencanakan.

Untuk course ini, kedua pendekatan aman digunakan, tetapi memahami perilaku otomatis rsync akan membantu learner menghindari kebingungan saat folder belum terlihat di server.

Update code tanpa upload ulang (rsync workflow)

Setelah upload pertama berhasil, learner sering bertanya: kalau nanti ada perubahan file, penambahan file, atau penghapusan file, apakah harus upload ulang semuanya dari awal?

Jawaban singkat

Tidak perlu upload ulang semua file. Untuk workflow yang lebih rapi, gunakan rsync lagi. Tool ini dirancang untuk melakukan sinkronisasi perubahan, bukan sekadar copy ulang seluruh folder setiap saat.

Apa yang dilakukan rsync saat dijalankan lagi?

• File yang tidak berubah biasanya tidak dikirim ulang
• File yang berubah akan dikirim ulang
• File baru akan ikut ditambahkan ke VPS

Ini membuat proses update jauh lebih efisien dibanding meng-copy ulang seluruh project dengan SCP setiap kali ada perubahan kecil.

Contoh workflow update

Kalau Anda sudah berada di folder project di WSL, misalnya:

cd /mnt/c/projects/html/lms

Lalu setelah mengubah source code di localhost, cukup jalankan lagi:

rsync -avz -e "ssh -p 2203"   --exclude-from='.gitignore'   ./ deploy@IP_VPS_ANDA:/home/deploy/lms/

Command ini bisa dipakai berulang kali setiap ada update.

Bagaimana kalau ada file yang dihapus di localhost?

Secara default, rsync tidak otomatis menghapus file di VPS hanya karena file tersebut sudah hilang di localhost. Jadi kalau Anda menghapus file di lokal, file lama itu bisa saja masih tertinggal di server.

Kalau memang ingin membuat VPS benar-benar mengikuti kondisi source terbaru di localhost, Anda bisa menambahkan option --delete:

rsync -avz -e "ssh -p 2203"   --exclude-from='.gitignore'   --delete   ./ deploy@IP_VPS_ANDA:/home/deploy/lms/

Kenapa --delete perlu hati-hati?

Karena option ini bisa menghapus file di VPS yang tidak ada lagi di folder lokal. Jadi kalau learner salah folder, salah path, atau salah project, file di server bisa ikut terhapus.

Karena itu, untuk pemula sangat disarankan melakukan preview terlebih dahulu dengan mode dry run:

rsync -avzn -e "ssh -p 2203"   --exclude-from='.gitignore'   --delete   ./ deploy@IP_VPS_ANDA:/home/deploy/lms/

Option -n berarti simulasi saja. Dengan ini learner bisa melihat apa yang akan berubah tanpa benar-benar menyalin atau menghapus file.

Kapan setelah rsync perlu menjalankan langkah lain di VPS?

Kalau perubahan Anda hanya pada file source biasa, sering kali cukup lanjut ke proses build atau restart aplikasi.

Namun kalau ada perubahan dependency, misalnya package.json atau package-lock.json ikut berubah, maka setelah rsync Anda biasanya perlu masuk ke VPS dan menjalankan:

cd /home/deploy/lms
npm install

Kalau project menggunakan build production, lanjutkan juga dengan build ulang sesuai kebutuhan project.

Kenapa workflow ini lebih baik daripada upload ulang semua?

• Lebih cepat karena hanya perubahan yang dikirim
• Lebih hemat bandwidth
• Lebih rapi untuk maintenance
• Lebih mendekati workflow engineer di dunia nyata

Itulah sebabnya, setelah upload pertama selesai, rsync lebih cocok dipakai sebagai tool update berkala, bukan hanya sebagai tool upload awal.

Best practice penting

• Jangan upload node_modules
• Upload hanya source code
• Install dependency di VPS nanti
• Test SSH dulu sebelum SCP
• Kalau memakai port custom, biasakan selalu tulis -P 2203
• Kalau memakai SSH key, simpan key dengan aman dan jangan dibagikan

Verifikasi tambahan

Pastikan folder project bisa diakses:

pwd

Dan cek file utama:

ls package.json

Kalau file ini ada, berarti project siap untuk langkah berikutnya.

Versi video

Ringkasan alur aman

ssh -p 2203 deploy@IP_VPS
scp -P 2203 -r ./lms deploy@IP_VPS:/home/deploy/
scp -P 2203 -i ~/.ssh/id_rsa -r ./lms deploy@IP_VPS:/home/deploy/
ssh -p 2203 deploy@IP_VPS
ls -la
cd lms
ls -la
du -sh lms

Kesimpulan

Upload source code adalah langkah penting sebelum menjalankan aplikasi di server.

Yang perlu dipahami bukan hanya cara upload, tetapi juga cara memilih flow yang tepat: password biasa, SSH key, atau port custom seperti 2203. Dengan begitu learner tidak mudah stuck saat command SCP terlihat benar tetapi koneksi ternyata gagal karena detail autentikasi atau port.

Di lesson berikutnya, kita akan mulai menginstall dependency dan menjalankan aplikasi LMS di server.

Clone Repo LMS

Setelah folder project di VPS siap, salah satu cara paling rapi untuk mengambil source code LMS adalah dengan clone repository menggunakan Git.

Untuk learner yang masih baru, arti clone repo sangat sederhana: mengambil salinan project dari GitHub, GitLab, atau repository lain ke dalam server VPS.

Untuk learner yang sudah terbiasa dengan workflow development, langkah ini adalah bagian normal dari deployment berbasis version control, sehingga update code ke depannya juga akan jauh lebih mudah dibanding upload manual berulang-ulang.

Kenapa clone repo lebih baik daripada upload manual?

• Lebih rapi — source code di server terhubung langsung dengan repository aslinya.
• Lebih mudah update — nanti perubahan bisa diambil lagi tanpa upload ulang semua file.
• Lebih familiar untuk production — banyak workflow deploy modern memakai Git sebagai sumber utama code.
• Lebih mudah dilacak — branch, commit, dan history project bisa dicek dengan jelas.

Kapan sebaiknya pakai clone repo?

Gunakan metode ini jika project LMS Anda memang sudah tersimpan di GitHub, GitLab, Bitbucket, atau server Git internal.

Kalau source code Anda belum ada di repository dan masih hanya tersimpan di laptop lokal, maka lesson sebelumnya tentang upload source code tetap valid. Tetapi kalau repository sudah ada, maka clone repo biasanya menjadi pilihan yang lebih natural dan lebih profesional.

Tujuan lesson ini

Di lesson ini kita akan belajar:

• cara memastikan Git sudah tersedia di VPS,
• cara install Git jika belum ada,
• cara masuk ke folder yang benar sebelum clone,
• cara clone repository dengan posisi folder yang benar dan hanya sekali,
• cara verifikasi hasil clone,
• dan cara mengatasi error-error yang paling sering muncul.

Workflow folder yang kita pakai di course ini

Sebelumnya kita sudah menyiapkan struktur folder project. Agar konsisten dengan course ini, pola yang paling aman adalah bekerja dari folder:

/var/www/lms

Lalu repository LMS kita clone ke dalam folder frontend, sehingga hasil akhirnya menjadi seperti ini:

/var/www/lms/frontend

Dengan pola ini, struktur project tetap rapi dan sesuai dengan lesson-lesson berikutnya saat kita install dependency, build, dan menjalankan aplikasi.

Langkah 1: pastikan Git sudah tersedia

Sebelum clone repository, cek dulu apakah Git sudah terinstall di VPS.

git --version

Kalau Git sudah ada, biasanya akan muncul hasil seperti:

git version 2.xx.x

Anda juga bisa cek dengan command berikut:

command -v git

Kalau Git ada, biasanya output-nya mirip seperti:

/usr/bin/git

Kalau Git belum ada

Kalau saat menjalankan git --version muncul pesan seperti command not found, berarti Git belum terinstall.

Install Git dengan langkah berikut:

sudo apt update
sudo apt install git -y

Setelah selesai, verifikasi lagi:

git --version

Kenapa verifikasi command itu penting?

Dalam course ini, setiap kali kita memakai tool baru, biasakan cek dua hal:

1. apakah tool-nya sudah ada,
2. dan apakah tool itu benar-benar bisa dijalankan.

Kebiasaan kecil ini sangat membantu, terutama untuk learner pemula, karena banyak error deployment sebenarnya hanya terjadi karena command yang dipakai belum terinstall.

Langkah 2: masuk ke folder project yang benar

Sebelum clone, pindah dulu ke folder utama project LMS:

cd /var/www/lms

Lalu cek posisi kita sekarang:

pwd

Output yang diharapkan:

/var/www/lms

Setelah itu, lihat isi foldernya:

ls -la

Ini penting supaya kita tahu apakah folder frontend belum ada, sudah ada, atau justru sudah terisi file tertentu.

Langkah 3: pilih pola clone yang sesuai

Di course ini, kita pakai satu pola yang paling aman dan paling mudah dipahami learner pemula:

cd /var/www/lms
git clone <repo-url> frontend

Artinya sangat penting:

• command git clone dijalankan dari folder /var/www/lms,
• bukan dari /var/www/lms/frontend,
• karena folder frontend akan dibuat otomatis oleh Git saat proses clone berhasil.

Contoh:

cd /var/www/lms
git clone https://github.com/username/lms.git frontend

Setelah selesai, hasilnya akan berada di:

/var/www/lms/frontend

Kalau setelah dicek ternyata folder frontend sudah terbuat, maka jangan jalankan git clone lagi. Lanjutkan ke lesson atau langkah berikutnya yang bekerja di dalam folder /var/www/lms/frontend.

Kenapa tidak boleh clone lagi?

• Karena folder project sudah ada.
• Clone ulang ke lokasi yang sama justru bisa memicu error atau membingungkan struktur folder.
• Di workflow normal, git clone dipakai hanya untuk pengambilan source code pertama kali.

Jadi, keputusan sederhananya seperti ini:

Kalau /var/www/lms/frontend belum ada  → jalankan git clone sekali
Kalau /var/www/lms/frontend sudah ada → jangan clone lagi, lanjut ke lesson berikutnya

Langkah 4: verifikasi hasil clone

Setelah clone selesai, cek isi folder utama:

ls -la /var/www/lms

Lalu masuk ke folder project:

cd /var/www/lms/frontend

Cek lagi isi project:

ls -la

Anda seharusnya mulai melihat file seperti:

• package.json
• src
• public
• .git

Kalau folder frontend sudah ada sejak awal dan Anda memang tidak melakukan clone lagi, Anda tetap bisa masuk ke folder tersebut untuk lanjut bekerja:

cd /var/www/lms/frontend
ls -la

Kalau isi project sudah terlihat normal, berarti lesson ini selesai dan Anda bisa lanjut ke lesson berikutnya.

Kalau folder .git ada, itu pertanda bahwa hasil clone benar-benar terhubung dengan repository Git.

Verifikasi tambahan untuk intermediate dan expert

Kalau ingin lebih yakin, jalankan:

git remote -v

Command ini menunjukkan repository asal yang terhubung ke project.

Anda juga bisa cek branch:

git branch -a

Dan melihat commit terbaru:

git log --oneline -n 5

Untuk learner yang sudah expert, langkah ini membantu memastikan bahwa branch dan commit yang masuk ke server memang sesuai harapan.

Bagaimana jika repository private?

Kalau repository bersifat private, clone tetap bisa dilakukan, tetapi Anda harus lolos autentikasi.

Secara umum ada dua cara yang paling sering dipakai:

• HTTPS + credential / token
• SSH key

Opsi 1 — clone via HTTPS

git clone https://github.com/username/lms.git frontend

Pada beberapa platform, password biasa sudah tidak dipakai lagi untuk Git operation. Sebagai gantinya, Anda mungkin perlu memakai Personal Access Token (PAT).

Opsi 2 — clone via SSH

git clone git@github.com:username/lms.git frontend

Cara ini biasanya lebih nyaman untuk workflow jangka panjang, tetapi membutuhkan SSH key yang sudah diset di server Git dan di VPS.

Kalau ingin clone branch tertentu

Kalau repository punya banyak branch dan Anda ingin langsung mengambil branch tertentu, gunakan:

git clone -b <branch-name> <repo-url> frontend

Contoh:

git clone -b main https://github.com/username/lms.git frontend

Kalau branch default repository memang main, command biasa tanpa -b biasanya juga sudah cukup.

Workflow paling sederhana untuk pemula

Kalau Anda ingin versi yang paling mudah diingat, alurnya seperti ini:

git --version
cd /var/www/lms
pwd
ls -la
git clone <repo-url> frontend
cd frontend
ls -la

Itu sudah cukup untuk menyelesaikan langkah clone secara aman.

Troubleshooting umum

1. Error: git: command not found

Artinya Git belum terinstall.

sudo apt update
sudo apt install git -y
git --version

2. Error: Permission denied saat membuat folder atau menulis file

Biasanya ini berarti ownership folder belum benar. Cek dulu:

ls -ld /var/www/lms

Kalau owner belum deploy, perbaiki dengan:

sudo chown -R deploy:deploy /var/www/lms

Lalu coba clone lagi.

3. Error: destination path 'frontend' already exists and is not an empty directory

Artinya folder tujuan sudah ada dan tidak kosong.

Cek dulu isinya:

ls -la /var/www/lms/frontend

Kalau folder itu memang sisa percobaan gagal sebelumnya dan aman untuk dihapus:

rm -rf /var/www/lms/frontend

Lalu clone ulang.

Jangan asal hapus kalau Anda belum yakin folder itu tidak berisi data penting.

4. Error: Repository not found

Biasanya ada beberapa kemungkinan:

• URL repository salah,
• repository private tetapi Anda belum punya akses,
• atau autentikasi gagal.

Cek lagi URL repo yang dipakai, lalu pastikan akun/token/SSH key memang punya akses ke repository tersebut.

5. Error: Authentication failed

Ini sering terjadi saat clone via HTTPS ke repo private.

Solusinya biasanya:

• gunakan Personal Access Token jika platform tidak menerima password biasa,
• atau pindah ke metode SSH key.

6. Error: Permission denied (publickey)

Ini biasanya muncul saat clone via SSH, tetapi SSH key di VPS belum terpasang atau belum didaftarkan ke GitHub/GitLab.

Cek dulu apakah key ada:

ls -la ~/.ssh

Kalau belum ada, berarti Anda memang perlu menyiapkan SSH key terlebih dahulu sebelum clone via SSH.

7. Clone sangat lambat atau terputus

Bisa disebabkan koneksi VPS, jaringan menuju provider Git, atau repository terlalu besar.

Untuk test cepat, Anda bisa pastikan VPS masih punya koneksi internet:

ping -c 4 github.com

Kalau ping gagal, masalahnya bisa jadi bukan pada Git, tetapi pada koneksi server.

Tips untuk learner expert

Kalau Anda sudah terbiasa dengan Git, beberapa verifikasi tambahan yang sering dipakai adalah:

• cek branch aktif dengan git branch --show-current,
• cek commit aktif dengan git rev-parse --short HEAD,
• cek status working tree dengan git status.

Tetapi untuk course ini, learner pemula tidak wajib menghafal semua itu. Fokus utamanya adalah memastikan source code berhasil masuk ke VPS dengan struktur yang benar.

Versi video

Kalau ingin melihat penjelasan visual dalam bentuk video, putar materi pendamping berikut:

Ringkasan alur aman

git --version
command -v git
sudo apt update
sudo apt install git -y
cd /var/www/lms
pwd
ls -la
git clone <repo-url> frontend
cd /var/www/lms/frontend
ls -la
git remote -v
git branch -a
git log --oneline -n 5

Kesimpulan lesson ini

Clone repository adalah cara yang rapi dan profesional untuk mengambil source code LMS ke VPS. Dengan Git, project di server menjadi lebih mudah dikelola, lebih mudah diverifikasi, dan lebih siap untuk workflow update berikutnya.

Untuk learner pemula, cukup pahami bahwa kita sedang “mengambil project dari repository ke server”. Untuk learner yang lebih advance, lesson ini adalah fondasi workflow deploy berbasis Git yang nanti akan sangat membantu saat update code, rollback, atau tracking branch dan commit.

Di lesson berikutnya, kita akan masuk ke tahap berikutnya: menginstall dependency project agar LMS benar-benar siap dibuild dan dijalankan di VPS.

Install dependency LMS

Setelah repository LMS berhasil di-clone dan folder /var/www/lms/frontend sudah ada, langkah berikutnya adalah menginstall seluruh dependency project.

Di lesson ini kita akan bahas bukan hanya command npm install, tetapi juga:

• apa sebenarnya dependency itu,
• kenapa Next.js membutuhkannya,
• di folder mana command harus dijalankan,
• cara mengecek apakah node dan npm sudah tersedia,
• cara install jika ternyata belum ada,
• dan troubleshooting jika proses install gagal.

Apa itu dependency?

Untuk learner pemula, dependency bisa dibayangkan sebagai bahan-bahan dan alat bantu yang dibutuhkan project agar bisa dijalankan dengan normal.

Pada project LMS berbasis Next.js, dependency biasanya berisi:

• framework utama seperti next,
• library pendukung seperti react dan react-dom,
• package tambahan lain yang dipakai project,
• serta tools build yang dibutuhkan saat deploy.

Semua daftar dependency ini biasanya didefinisikan di file package.json.

Kenapa lesson ini penting?

Walaupun source code sudah berhasil masuk ke VPS, aplikasi belum bisa langsung dijalankan begitu saja. Server masih perlu mengunduh semua package yang dibutuhkan oleh project.

Jadi secara sederhana:

• clone repo = mengambil source code,
• npm install = mengambil semua bahan yang dibutuhkan source code itu agar bisa diproses dan dijalankan.

Posisi folder yang benar sebelum menjalankan command

Command utama lesson ini dijalankan dari folder project frontend:

cd /var/www/lms/frontend

Untuk memastikan Anda benar-benar sedang berada di folder yang tepat, cek dengan:

pwd

Output yang diharapkan:

/var/www/lms/frontend

Kalau belum berada di situ, pindah dulu ke folder tersebut sebelum melanjutkan.

Langkah 1: pastikan folder frontend memang sudah ada

Sebelum install dependency, cek dulu apakah folder project hasil clone memang ada:

ls -la /var/www/lms
ls -la /var/www/lms/frontend

Kalau folder /var/www/lms/frontend belum ada, berarti Anda belum bisa lanjut ke lesson ini. Selesaikan dulu lesson clone repo sebelumnya.

Langkah 2: cek apakah file package.json ada

Masuk ke folder frontend lalu cek isi project:

cd /var/www/lms/frontend
ls -la

Pastikan ada file seperti:

• package.json
• package-lock.json atau lock file sejenis
• folder source project seperti src, public, dan lain-lain

Kalau package.json tidak ada, maka npm install tidak akan berjalan sebagaimana mestinya.

Langkah 3: cek status Node.js dan npm

Sebelum memakai command baru seperti npm install, kita perlu memastikan bahwa runtime Node.js dan npm memang sudah tersedia di VPS.

Jalankan dari mana saja boleh, tetapi agar konsisten dengan workflow lesson ini, Anda bisa menjalankannya dari folder project:

cd /var/www/lms/frontend
node -v
npm -v
command -v node
command -v npm

Interpretasinya:

• Kalau node -v menampilkan versi, berarti Node.js sudah ada.
• Kalau npm -v menampilkan versi, berarti npm juga sudah ada.
• Kalau command -v mengembalikan path seperti /usr/bin/node atau /usr/bin/npm, berarti command tersedia di sistem.

Kalau node atau npm belum ada

Kalau salah satu command gagal atau muncul error seperti command not found, install dulu Node.js LTS.

Command install ini bisa dijalankan dari folder mana saja karena sifatnya adalah instalasi sistem. Agar aman, jalankan dari home user deploy atau tetap dari session biasa Anda:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install nodejs -y

Kalau curl belum ada, install dulu:

sudo apt update
sudo apt install curl -y

Setelah instalasi selesai, cek ulang:

node -v
npm -v

Langkah 4: jalankan npm install di folder frontend

Kalau semua syarat sudah siap, masuk ke folder project lalu jalankan:

cd /var/www/lms/frontend
npm install

Command ini akan membaca package.json, lalu mengunduh seluruh dependency yang dibutuhkan project LMS Anda.

Setelah berhasil, biasanya akan terbentuk folder:

node_modules

Anda bisa verifikasi dengan:

cd /var/www/lms/frontend
ls -la
ls -ld node_modules

Apa yang dilakukan npm install di balik layar?

Untuk learner yang lebih advanced, secara umum npm install akan:

• membaca dependency dari package.json,
• mengacu ke lock file jika ada,
• mengunduh package yang diperlukan,
• menyusun folder node_modules,
• dan menyiapkan project agar bisa dibuild.

Kapan npm install dijalankan?

Dalam workflow normal, npm install biasanya dijalankan:

• saat project pertama kali selesai di-clone,
• saat ada perubahan dependency di package.json atau lock file,
• atau saat environment baru perlu menyiapkan ulang dependency project.

Kalau tidak ada perubahan dependency, Anda tidak harus menjalankannya berulang-ulang tanpa alasan.

Troubleshooting yang paling sering terjadi

1. Error: npm: command not found

Artinya npm belum ada atau instalasi Node.js belum benar.

Solusi:

node -v
npm -v
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install nodejs -y

2. Error: node: command not found

Artinya runtime Node.js belum tersedia.

Solusinya sama: install Node.js LTS terlebih dahulu, lalu verifikasi ulang.

3. Error: package.json not found

Biasanya ini terjadi karena command dijalankan di folder yang salah.

Cek folder aktif:

pwd
ls -la

Kalau ternyata Anda belum berada di /var/www/lms/frontend, pindah dulu:

cd /var/www/lms/frontend

4. Error: EACCES / permission denied saat npm install

Biasanya owner folder tidak sesuai atau folder project bukan milik user deploy.

Cek ownership:

ls -ld /var/www/lms
ls -ld /var/www/lms/frontend

Kalau perlu, perbaiki dengan:

sudo chown -R deploy:deploy /var/www/lms

Lalu ulangi:

cd /var/www/lms/frontend
npm install

5. Install sangat lama atau seperti berhenti

Sering kali ini terkait koneksi internet VPS yang lambat atau repository package yang sedang lambat diakses.

Anda bisa cek koneksi dasar misalnya dengan:

ping -c 4 registry.npmjs.org

6. Ada warning dependency

Tidak semua warning berarti gagal. Fokus dulu apakah proses install benar-benar selesai dan prompt terminal kembali normal tanpa status error fatal.

7. Error karena lock file atau sisa install sebelumnya

Untuk learner expert, kadang ada kasus dependency bentrok atau sisa install lama. Salah satu langkah yang biasa dipakai adalah membersihkan dependency lalu install ulang:

cd /var/www/lms/frontend
rm -rf node_modules
rm -f package-lock.json
npm install

Catatan: langkah ini sebaiknya dilakukan dengan sadar, terutama jika project Anda memang mengandalkan lock file tertentu.

Verifikasi akhir setelah install

Setelah npm install selesai, cek beberapa hal berikut:

cd /var/www/lms/frontend
ls -ld node_modules
npm list --depth=0

Untuk pemula, tidak perlu memahami semua isi output npm list. Cukup tahu bahwa command tersebut membantu memastikan package utama memang sudah terpasang.

Versi video

Kalau ingin melihat materi pendamping dalam bentuk video, putar video berikut:

Ringkasan alur aman

cd /var/www/lms/frontend
pwd
ls -la
node -v
npm -v
command -v node
command -v npm
npm install
ls -ld node_modules

Kesimpulan lesson ini

npm install adalah langkah yang mengubah source code hasil clone menjadi project yang benar-benar siap diproses di server.

Tanpa dependency yang terinstall, LMS belum bisa dibuild dan belum bisa dijalankan sebagai aplikasi live. Karena itu, lesson ini adalah jembatan penting antara tahap clone source code dan tahap build production.

Build production

npm run build

Kalau ada error build, maka inilah salah satu titik penting yang nanti bisa menambah atau mengubah lesson di course ini.

Test run

npm run start

Setelah build berhasil, jalankan aplikasi dan cek apakah port 3000 aktif sebelum diteruskan lewat Nginx.

Point domain ke VPS

Buat atau edit A record di DNS panel agar domain utama atau subdomain LMS mengarah ke IP VPS.

Setup Nginx Reverse Proxy

Nginx akan menerima traffic dari port 80/443 lalu meneruskannya ke aplikasi Next.js di port 3000.

server {
  listen 80;
  server_name yourdomain.com;

  location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
  }
}

Enable config

sudo ln -s ...
sudo nginx -t
sudo systemctl reload nginx

Selalu uji syntax dengan nginx -t sebelum reload.

Install Certbot

sudo apt install certbot python3-certbot-nginx -y

Generate SSL

sudo certbot --nginx

Setelah ini, LMS seharusnya bisa diakses melalui HTTPS jika DNS sudah benar.

Install PM2

npm install -g pm2

Run app

pm2 start npm --name lms -- start

Nama process bisa disesuaikan, tetapi lms cukup jelas untuk project ini.

Auto start reboot

pm2 startup
pm2 save

Monitoring

pm2 status
pm2 logs

Ini penting ketika aplikasi tidak bisa diakses atau restart berulang.

Enable Gzip

Compression membantu memperkecil response HTML, CSS, dan JS sehingga halaman terasa lebih ringan.

Nginx cache

File statis seperti image, CSS, dan JS dapat diberi cache policy yang lebih baik agar loading lebih cepat.

Security headers

Header seperti X-Frame-Options, X-Content-Type-Options, dan Referrer-Policy membantu meningkatkan keamanan aplikasi web.

Next.js production env

Pastikan environment variable production dipisahkan dari local development, misalnya untuk base URL API, domain, atau setting lain.

Basic performance tuning

Cek ukuran image, hasil build, port internal, response time, dan penggunaan memory agar deployment lebih stabil.

Backup source code

Minimal, source code harus aman di Git. Untuk server, kita juga bisa membuat backup manual atau snapshot berkala.

Backup database

Untuk frontend statis/SSR saja belum banyak yang perlu dibackup selain source dan env. Tetapi saat backend/database masuk, backup database menjadi wajib.

Monitoring uptime

Gunakan pengecekan manual maupun uptime monitor eksternal untuk memastikan domain LMS selalu bisa diakses.

Restore scenario

Backup hanya berguna kalau kita tahu cara restore. Buat checklist sederhana: source, env, service, Nginx, SSL, dan process app.

Handling real-world deployment errors

Course ini bersifat living course. Jika nanti kita menemui error nyata saat deploy LMS di VPS, maka materi, lesson, dan solusi di course ini harus ikut diperbarui agar tetap sesuai pengalaman real deployment.