Kenapa LLM lokal Ada tiga alasan praktis menjalankan LLM di server sendiri. Pertama, privasi: prompt dan dokumen yang Anda tempel tidak dikirim ke penyedia pihak ketiga. Kedua, biaya: tidak ada tagihan per token, yang ada hanya biaya VPS yang memang sudah Anda bayar. Ketiga, kendali: modelnya tetap sama dari hari ke hari, tidak berubah diam-diam karena update penyedia. Komprominya juga harus jujur. Model lokal yang muat di VPS murah tidak sepintar model frontier seperti GPT-5 atau Claude. Untuk tugas seperti merangkum dokumen, menulis draf, menjawab pertanyaan umum, dan membantu coding sederhana, model 7–8 miliar parameter sudah sangat bisa dipakai. Untuk riset mendalam atau penalaran berlapis, model API tetap unggul. Anggap LLM lokal sebagai asisten harian, bukan pengganti segalanya. Syarat server Pilih VPS dengan RAM yang cukup, karena model bahasa berjalan di RAM (atau VRAM kalau ada GPU, tapi sebagian besar VPS murah tidak punya GPU). Patokan kasar untuk model terkuantisasi (fo...

Kenapa VPN sendiri, bukan VPN gratisan? WiFi publik itu nyaman tapi rawan: siapa pun yang satu jaringan berpotensi mengintip trafik yang tidak terenkripsi. VPN gratisan memang menyelesaikan satu masalah, tapi sering menimbulkan masalah lain — ada yang mencatat log, menyuntikkan iklan, atau membatasi kecepatan sampai tidak bisa dipakai. VPN pribadi di VPS sendiri menyelesaikan ketiganya: Anda yang memegang servernya, tidak ada pihak ketiga yang mencatat, dan kecepatannya hanya dibatasi oleh spesifikasi VPS dan koneksi internet Anda. WireGuard adalah pilihan yang masuk akal untuk ini: kodenya kecil, konfigurasinya satu file per perangkat, dan performanya jauh lebih ringan dibanding OpenVPN di VPS spek kecil. Biaya tambahannya praktis nol kalau Anda sudah punya VPS yang menganggur. Satu VPS 1 vCPU dan 1 GB RAM sanggup melayani beberapa perangkat sekaligus untuk pemakaian harian. Yang dibutuhkan VPS dengan Ubuntu 24.04 dan akses root atau sudo. Port UDP 51820 yang bisa dibuka di firew...

Kenapa Immich, bukan sekadar folder foto Menyimpan foto di folder VPS memang bisa, tapi tidak enak dipakai: tidak ada thumbnail, tidak bisa cari berdasarkan wajah atau lokasi, dan tidak ada aplikasi HP yang sinkron otomatis. Immich menutup semua celah itu. Tampilannya mirip Google Photos: timeline, album, pencarian, pengenalan wajah, peta lokasi, dan aplikasi Android/iOS untuk backup otomatis dari HP. Bedanya, semua berjalan di server Anda sendiri. Tidak ada yang memindai foto untuk iklan, tidak ada batas storage gratis, dan biayanya hanya sewa VPS plus disk yang Anda pakai. Kekurangannya juga perlu disebut di depan: Anda yang jadi adminnya. Kalau server mati atau disk rusak dan tidak ada backup, foto hilang. Jadi artikel ini tidak berhenti di install — backup adalah setengah dari isinya. Yang perlu disiapkan Spesifikasi realistis untuk pemakaian keluarga kecil (1–3 pengguna, puluhan ribu foto): VPS dengan minimal 2 CPU dan 4 GB RAM. Kalau ada video 4K yang perlu di-transcoding, 4...

Kenapa Vaultwarden, Bukan Sekadar File Catatan Menyimpan password di catatan HP atau spreadsheet adalah cara tercepat kehilangan akun. Sekali HP hilang atau file bocor, semua akun ikut terancam. Password manager menyelesaikan ini dengan satu master password yang mengunci brankas terenkripsi. Bitwarden resmi memang bisa di-self-host, tapi kebutuhan sumber dayanya besar untuk VPS kecil. Vaultwarden adalah implementasi ulang server Bitwarden yang kompatibel dengan aplikasi dan ekstensi Bitwarden resmi, tapi cukup berjalan dengan RAM ratusan MB. Praktisnya: Anda tetap memakai aplikasi Bitwarden di HP dan browser, hanya saja servernya milik Anda sendiri. Satu hal yang wajib dipahami sejak awal: Vaultwarden menyimpan brankas terenkripsi, tapi keamanan tetap bergantung pada Anda. Master password yang lemah atau hilang berarti brankas tidak bisa dibuka siapa pun, termasuk Anda. Tidak ada tombol "lupa password" di server sendiri. Persiapan Yang dibutuhkan: VPS Ubuntu 24.04 denga...

Kenapa kombinasi ini Menjalankan node app.js langsung dari terminal itu rapuh: begitu terminal ditutup atau server reboot, aplikasi ikut mati. PM2 menyelesaikan sisi proses — ia menjaga aplikasi tetap jalan, me-restart saat crash, dan menghidupkannya lagi setelah reboot. Nginx menyelesaikan sisi akses — ia menerima trafik dari internet (port 80/443) lalu meneruskannya ke aplikasi yang berjalan di port internal seperti 3000. Keduanya sudah teruji bertahun-tahun dan tidak butuh panel tambahan. Asumsi di artikel ini: Anda sudah punya VPS Ubuntu 24.04 dengan akses root atau sudo, dan sebuah domain yang diarahkan (record A) ke IP VPS. Contoh aplikasi memakai port 3000 dan domain app.contoh.com — ganti sesuai punya Anda. 1. Pasang Node.js Ubuntu 24.04 membawa Node.js 18 di repositori bawaan, tapi versi itu sudah tua untuk banyak proyek modern. Lebih aman memakai Node.js 22 LTS dari NodeSource: sudo apt update && sudo apt install -y curl curl -fsSL https://deb.nodesource.com/se...

Kenapa repot-repot pakai GitHub Actions? Alur deploy manual itu kelihatannya cepat: git pull di server, restart service, selesai. Masalahnya muncul saat Anda lupa langkah, salah server, atau deploy sambil mengantuk. Tiga kali deploy manual, tiga kali pula hasilnya bisa berbeda. GitHub Actions mengubah deploy menjadi satu alur yang sama setiap kali: kode yang lolos push ke main selalu sampai ke server dengan cara yang sama, dan lognya bisa dibuka ulang kapan pun. Tidak perlu panel hosting, tidak perlu biaya tambahan — runner gratis GitHub sudah cukup untuk deploy proyek kecil sampai menengah. Pola yang dipakai di sini sederhana: rsync untuk mengirim file, SSH untuk menjalankan perintah di server, dan systemd untuk menjaga aplikasi tetap hidup. Tidak ada Docker, tidak ada alat deploy khusus. Kalau suatu hari Anda pindah ke alat lain, konsepnya tetap sama. Gambaran alurnya Anda push ke branch main . GitHub Actions checkout kode, lalu rsync ke VPS. Sebelum file baru ditimpa, salinan...

Masalah yang Diselesaikan Gateway Begitu aplikasi Anda memakai lebih dari satu penyedia model AI, konfigurasi mulai menyebar. Setiap aplikasi menyimpan base URL dan API key masing-masing penyedia, dan setiap kali ada model yang diganti atau key yang dirotasi, semua aplikasi harus diubah satu per satu. Belum lagi soal pencatatan: tanpa titik pusat, Anda tidak tahu aplikasi mana yang paling banyak menghabiskan kuota. Gateway menyelesaikan ini dengan satu pola sederhana: aplikasi hanya mengenal satu endpoint, yaitu gateway Anda. Gateway yang memutuskan request diteruskan ke penyedia mana, berdasarkan nama model yang diminta. Aplikasi tidak pernah memegang key penyedia secara langsung. Arsitektur Singkatnya Alurnya begini: Aplikasi Anda → https://gateway-domain-anda/v1 → Gateway → Penyedia A / Penyedia B / Penyedia C Gateway melakukan empat hal: Autentikasi — memeriksa API key yang dikirim aplikasi. Routing — memetakan nama model ke upstream yang tepat. Forwarding — meneruskan re...