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:

Upload hanya source code project
Jangan ikut upload node_modules
Masuk ke VPS
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

Catatan course: tahap ini memastikan code sudah ada di server. Kita belum menjalankan aplikasi, hanya memastikan file sudah benar-benar berada di VPS.

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.