Belajar Zellij - Remote Development & SSH Workflow

#Pendahuluan

Di episode 18 kalian menguasai manajemen banyak session di satu mesin. Sekarang kita melepas batas mesin: episode 19 membahas Remote Development & SSH Workflow — membawa workspace Zellij ke server yang jauh dan menjadikannya tempat kerja yang permanen, tidak peduli seberapa buruk koneksi di antara kalian.

Ini adalah episode yang menguji alasan klasik orang memakai multiplexer: survive SSH disconnect. Ketika kalian bekerja langsung di terminal tanpa multiplexer dan koneksi terputus, proses foreground ikut mati — build kehilangan konteks, editor menutup paksa, dan sepuluh menit pekerjaan menguap begitu saja. Dengan Zellij di server, proses tetap berjalan di balik layar, dan kalian cukup connect ulang lalu attach kembali ke titik persis di mana kalian berhenti. Ini bukan kenyamanan — ini syarat dasar untuk operasional server yang serius.

Kita akan membahas alur kerja lengkap: menjalankan Zellij di server remote, perilaku attach dan detach yang tahan putus, mosh untuk koneksi lambat dan berpindah jaringan, jump host atau bastion untuk jaringan berlapis, fitur remote sessions 0.44 yang memungkinkan attach lintas mesin tanpa SSH, serta best practice yang menjaga seluruh alur tetap aman dan mulus. Di akhir episode, kalian akan nyaman bekerja di server mana pun seolah-olah ia ada di laptop kalian.

#Menjalankan Zellij di Server Remote

Prinsip pertama yang harus dipahami: Zellij berjalan di tempat binary-nya berada. Kalian menjalankan Zellij di server, bukan di laptop — server yang menahan proses, dan laptop hanyalah layar yang menempel. Jadi langkah pertama adalah memasang Zellij di server (metode instalasi dari episode 0 berlaku), lalu memulai session melalui SSH.

Sebelum mulai, pastikan Zellij terpasang dan berfungsi di server. Verifikasi sekali dengan zellij --version di server, lalu jalankan zellij setup --check untuk memastikan environment terminal server mendukung fitur yang kalian butuhkan. Langkah verifikasi singkat ini menyelamatkan kalian dari sesi debugging yang membingungkan di tengah server produksi.

Perhatikan satu detail penting: gunakan flag -t pada SSH untuk memaksa alokasi pseudo-terminal, karena Zellij adalah aplikasi interaktif yang butuh TTY. Pola yang paling umum adalah attach atau create:

Mulai atau attach session di server remote

ssh deploy@db01 -t "zellij attach -c dev"

Perintah di atas masuk ke server db01, lalu menjalankan zellij attach -c dev di sana. Jika session dev belum ada, ia dibuat; jika sudah ada, kalian langsung menempel padanya. Ucapan -c yang sama seperti di episode 18 — pola "ada atau buat" yang membuat perintah ini aman dijalankan berulang kali.

Kalian juga bisa membawa layout per proyek ke remote. Jika layout disimpan di ~/.config/zellij/layouts/ server, pemanggilannya persis seperti di mesin lokal:

Mulai session remote dengan layout

ssh admin@app1 -t "zellij -s ops -l server-admin"

Sekali layout tersimpan di server, session remote bisa di-resurrect menggunakan mekanisme episode 17 — semuanya berjalan di sisi server tanpa bergantung pada mesin kalian.

Satu catatan: pastikan server memakai versi Zellij yang sama dengan mesin lokal, atau setidaknya satu versi major yang sama. Client dan server Zellij bertukar data secara terus-menerus; perbedaan versi yang besar bisa membuat attach gagal atau memunculkan perilaku tak terduga. Jika kalian mengelola konfigurasi Zellij lewat dotfiles (pola yang akan kita bahas di episode 27), sinkronkan juga versi binary-nya agar pengalaman di server identik dengan di lokal.

#Attach & Detach yang Tahan Terhadap Koneksi Putus

Setelah session berjalan di server, kalian menempel padanya lewat SSH seperti biasa. Ketika kalian menekan Ctrl+o lalu d untuk detach, atau bahkan ketika koneksi tiba-tiba mati tanpa sempat detach, yang terjadi sama: client Zellij terputus dari server, tetapi server dan semua proses di dalam session tetap hidup di server. Inilah jantung remote development dengan Zellij.

Kembali ke pekerjaan tinggal dua langkah: SSH lagi, lalu attach:

Connect ulang dan attach kembali

ssh deploy@db01
zellij attach dev

Setelah attach, kalian berada persis di tempat berhenti: pane yang sama, tab yang sama, dan proses yang terus berjalan selama kalian pergi. Tidak ada state yang hilang di sisi aplikasi — jika kalian menjalankan tail -f pada log, baris-baris baru terus mengalir walaupun layar kalian sempat hilang.

Note

Bedakan dua kondisi yang hasilnya berbeda: detach eksplisit (Ctrl+o lalu d) dan koneksi putus. Pada detach eksplisit, kalian memutus client secara bersih; pada koneksi putus, SSH client kalian mati tetapi server Zellij di sisi remote mendeteksi client hilang dan melanjutkan hidup. Keduanya sama-sama aman untuk proses — tetapi detach eksplisit lebih terprediksi, terutama saat kalian ingin memastikan tidak ada output yang terbuang saat client merespons sinyal jaringan.

Untuk membuat koneksi SSH lebih tahan, ulangi pelajaran episode 0: aktifkan ControlMaster dan ServerAliveInterval di ~/.ssh/config sehingga handshake tidak berulang dan koneksi mati terdeteksi cepat. Kombinasi SSH yang kokoh di bawah dan Zellij yang persistent di atas adalah pasangan ideal untuk remote development.

#mosh untuk Koneksi Lambat

SSH adalah pilihan default, tetapi pada jaringan yang lambat, tidak stabil, atau sering berpindah (misalnya hotspot seluler), SSH bisa terasa menyakitkan. Di sinilah mosh (mobile shell) unggul. Mosh dirancang untuk koneksi buruk: ia menyinkronkan layar secara incremental, mempertahankan koneksi saat IP berubah (roaming), dan tetap responsif meski latensi tinggi. Zellij berjalan sempurna di dalam mosh, karena mosh hanya menyediakan transport terminal, dan Zellij mengelola session di atasnya.

Masuk server dengan mosh lalu attach

mosh deploy@db01
zellij attach dev

Instalasi mosh bervariasi per distro — berikut perbandingannya:

sudo apt install mosh

Perlu dicatat bahwa server tempat kalian connect juga harus memasang mosh (paket mosh-server). Mosh berkomunikasi lewat UDP pada rentang port 60000 sampai 61000 — pastikan firewall mengizinkannya.

Pola kerja yang paling mulus adalah: mosh ke server, lalu mulai Zellij di dalamnya. Setiap kali koneksi patah — pindah dari WiFi ke hotspot, masuk lift, atau sekadar mengunci laptop — mosh menahan sesi di sisi client, dan ketika koneksi pulih, kalian langsung kembali pada layar yang sama, bahkan dengan riwayat scrollback yang tetap utuh. Karena Zellij berjalan di server, sesi kerja benar-benar tidak bergantung pada stabilitas jaringan client.

Important

Mosh bukan pengganti SSH untuk semua kasus. Ia tidak mendukung port forwarding dan tunnel TCP seperti SSH, sehingga untuk akses web server atau database di balik server, tetap gunakan SSH. Bagi kalian yang memakai Zellij sebagai lapisan session (seperti kita), mosh adalah pasangan transport yang sangat nyaman: Zellij menangani persisten session, mosh menangani koneksi yang patah-patah. Untuk koneksi yang benar-benar kritis dan aman, kombinasikan keduanya — SSH untuk tunnel, mosh untuk terminal interaktif.

#Jump Host & Bastion

Banyak infrastruktur produksi tidak mengekspos server aplikasi langsung ke internet. Server hanya bisa dijangkau lewat satu titik masuk yang disebut bastion atau jump host. Di jaringan seperti ini, kalian SSH ke bastion dulu, baru ke server tujuan. Zellij tetap bekerja tanpa perubahan — karena sesungguhnya kalian hanya membutuhkan TTY di server tujuan.

Cara modern untuk melompati bastion adalah ProxyJump (-J). Perintah berikut masuk ke server-db01 melalui bastion.example.com dalam satu hop:

Untuk kenyamanan jangka panjang, simpan konfigurasi ini di ~/.ssh/config alih-alih mengetiknya setiap kali:

~/.ssh/config - jump host untuk remote Zellij

Host db01
    HostName server-db01.example.com
    User deploy
    ProxyJump bastion.example.com
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m
    ServerAliveInterval 60
    ServerAliveCountMax 3

Setelah konfigurasi ini, perintah ssh db01 -t "zellij attach -c ops" sudah cukup — SSH menangani seluruh rangkaian hop. Catatan penting: jalankan Zellij di server tujuan, bukan di bastion. Bastion sebaiknya hanya menjadi jalur lalu lintas, bukan tempat proses berjalan.

Tip

Saat menembus beberapa hop, perhatikan autentikasi key. Jika key kalian hanya ada di laptop, gunakan agent forwarding (ssh -A) agar bastion tidak perlu menyimpan private key. Namun jangan nyalakan -A secara global — aktifkan hanya untuk host yang memang kalian percaya, karena agent forwarding berarti setiap proses di server itu bisa meminjam identitas SSH kalian. Ini keseimbangan klasik antara kenyamanan dan keamanan di jaringan berlapis.

#Remote Sessions 0.44: Attach Lintas Mesin

Sejak versi 0.44, Zellij menawarkan pendekatan baru untuk remote: terminal-to-terminal attach over HTTPS. Ini bukan SSH — ini memanfaatkan web server bawaan Zellij (yang diperkenalkan di 0.43) sehingga sebuah session di server bisa di-attach dari terminal di mesin lain hanya dengan URL, lengkap dengan autentikasi token.

Alurnya: di server, mulai web server Zellij dengan zellij web, bagikan session, dan buat token login. Dari laptop, attach langsung ke session remote dengan URL-nya:

Attach session remote lewat HTTPS

zellij attach https://zellij.internal:8443/ops --token ops-token-123

Jika kalian hanya ingin mengamati tanpa bisa mengirim input, gunakan mode read-only:

Pantau session remote secara read-only

zellij watch ops

zellij watch melekat pada session dalam mode read-only — output terlihat, input tidak bisa dikirim. Fitur ini populer untuk demonstrasi, screencast, dan inspeksi kejadian produksi tanpa risiko mengubah keadaan server.

Manajemen token dilakukan lewat CLI zellij web: buat token dengan --create-token, buat token read-only dengan --create-read-only-token, daftar token dengan --list-tokens, dan cabut dengan --revoke-token. Token hanya ditampilkan sekali saat dibuat — simpan di tempat aman, karena jika hilang, kalian harus mencabut dan membuat ulang. Sebagian besar operasi ini juga bisa dilakukan dari share plugin, yang akan kita bedah lengkap di episode 20.

Warning

Remote sessions membuka terminal server ke jaringan — ini berarti membuka pintu berbahaya jika dikonfigurasi sembrono. Web server Zellij mewajibkan HTTPS saat melayani non-localhost, dan token harus dijaga seperti kunci server. Praktik yang disarankan: jangan pernah memaparkan port web server langsung ke internet tanpa reverse proxy dan firewall, putar token secara berkala dengan zellij web --revoke-token, dan batasi hanya session yang memang perlu di-share. Untuk sebagian besar kasus, SSH tetap jalur paling aman — gunakan remote sessions ketika SSH tidak praktis, misalnya melintasi batas jaringan yang ketat.

#Best Practice Remote Development

Agar seluruh alur remote terasa profesional, terapkan beberapa praktik berikut secara konsisten:

Praktik	Alasan
Zellij di server, bukan di laptop	Proses menempel pada server; laptop bisa mati kapan saja
Nama session konsisten per server	`zellij attach -c nama` menjadi idempotent dan mudah diingat
`ControlMaster` + `ServerAliveInterval`	Handshake tidak berulang, putus terdeteksi cepat
mosh untuk jaringan tidak stabil	Roaming dan responsivitas tinggi pada latensi buruk
Bastion hanya untuk lalu lintas	Jangan menjalankan proses di jump host
SSH untuk tunnel, Zellij untuk session	Masing-masing alat melakukan yang terbaik

Selain itu, biasakan memeriksa kondisi server sebelum attach: zellij ls di server memberi gambaran session yang sedang berjalan dan yang bisa di-resurrect — kombinasi dari pelajaran episode 17 dan 18 yang kini bekerja di konteks remote. Jika kalian bekerja di banyak server, pertimbangkan juga memakai keybinding remap (episode 9) untuk membedakan konteks lokal dan remote.

Kombinasi praktik di atas membuat remote development tidak lagi terasa seperti menambal koneksi yang rapuh. Alur yang saya rekomendasikan: satu nama session tetap per server (ops, dev, release), satu cara masuk yang konsisten (mosh untuk kerja interaktif, SSH untuk tunnel), dan kebiasaan zellij ls sebelum attach. Dengan begitu, berpindah dari laptop ke server produksi dan kembali lagi menjadi rutinitas yang sama mulusnya dengan berpindah tab.

#Kesalahan Umum (Common Pitfalls)

Menjalankan Zellij di laptop, bukan di server. Jika proses berada di laptop, koneksi putus tetap memutuskan pekerjaan. Pastikan zellij dijalankan di server tujuan — verifikasi dengan zellij ls di server, bukan di mesin lokal.
Lupa flag -t pada SSH. Tanpa pseudo-terminal, aplikasi interaktif seperti Zellij gagal memulai. Selalu sertakan -t saat menjalankan Zellij lewat perintah SSH.
Menjalankan Zellij di bastion. Bastion yang memegang proses berarti pekerjaan bergantung pada sesi shell di jump host. Jalankan Zellij di server tujuan; biarkan bastion hanya melewatkan koneksi.
Memaparkan web server Zellij tanpa HTTPS dan token. Remote sessions 0.44 menuntut HTTPS dan autentikasi token. Mengabaikannya berarti membuka terminal server ke siapa pun yang bisa menjangkau port-nya.
Menganggap mosh bisa menggantikan SSH untuk tunnel. mosh tidak meneruskan port TCP. Untuk tunnel dan akses layanan, tetaplah pada SSH — gunakan mosh hanya untuk terminal interaktif.

#Penutup

Di episode 19 ini kalian telah membawa Zellij melampaui batas mesin. Kita memulai dengan menjalankan Zellij di server remote, memahami mengapa attach dan detach tahan terhadap koneksi putus, lalu memilih transport yang tepat: mosh untuk jaringan buruk, jump host untuk jaringan berlapis, dan remote sessions 0.44 untuk attach lintas mesin tanpa SSH. Kita tutup dengan best practice yang menjaga seluruh alur tetap aman dan terprediksi.

Poin yang harus kalian bawa:

Zellij berjalan di server; laptop hanyalah layar.
Detach dan koneksi putus tidak menghentikan proses di server.
mosh unggul untuk koneksi lambat dan berpindah jaringan; SSH tetap untuk tunnel.
Bastion adalah jalur, bukan tempat proses berjalan.
Remote sessions 0.44 mengharuskan HTTPS dan token; jangan pernah memaparkannya telanjang ke internet.

Ingat, series Belajar Zellij terdiri dari 28 episode yang saling membangun. Kini kalian bisa bekerja di server mana pun dengan workspace yang persisten. Berikutnya, saatnya berbagi: bagaimana kalau orang lain ikut menonton atau ikut bekerja dalam session yang sama — dari terminal mereka sendiri, atau bahkan dari browser? Di episode 20 selanjutnya kita membahas Multiplayer & Web Client: share plugin, izin read dan write, alur pair programming, dan mengakses session dari browser tanpa instalasi apa pun. Sampai jumpa di episode 20!