Self-hosted remote desktop: the honest 2026 guide

Cari self-hosted remote desktop dan Anda akan menemukan selusin tutorial yang berhenti di docker compose up -d. Instalasi adalah bagian yang mudah, dan memang memakan waktu sekitar 30 menit. Panduan ini membahasnya secara lengkap — lalu membahas bagian yang menentukan apakah Anda seharusnya melakukannya sama sekali: berapa biaya untuk menjaga layanan tetap hidup setelah tutorial selesai.

Jawaban singkat

Jalankan sendiri bila ada persyaratan yang memaksa. Gunakan relay yang dikelola bila tidak ada. Kedengarannya singkat, jadi ini ujiannya:

• Jalankan sendiri jika: ada kewajiban kepatuhan tertulis yang menyatakan lalu lintas sesi tidak boleh melewati infrastruktur pihak ketiga; Anda mengoperasikan jaringan terisolasi (air-gapped) atau jaringan terbatas di mana relay eksternal tidak dapat dijangkau; atau aturan residensi data menetapkan yurisdiksi yang harus Anda patuhi.
• Gunakan relay yang dikelola jika: alasan Anda adalah versi dari "Saya lebih suka menjalankannya sendiri." Itu memang preferensi yang sah, dan juga berarti pekerjaan operasional berkelanjutan — lihat tagihan di bawah sebelum Anda mendaftar.

Perlu jelas apa yang Anda pilih, karena ini bukan dua produk berbeda. Tenvo berlisensi AGPL-3.0 dan relay yang dikelola menjalankan arsitektur hbbs/hbbr yang sama seperti yang dipasang panduan ini. Pilihannya adalah siapa yang mengoperasikan server, bukan apa yang dilakukan perangkat lunaknya.

Pertama: apa yang sebenarnya dapat dilihat relay

Ini penting sebelum hal lain, karena biasanya itu alasan orang memilih self-hosting sejak awal — dan biasanya dijelaskan secara keliru.

Pada koneksi peer-to-peer langsung, sesi berjalan end-to-end antara kedua perangkat. Ketika koneksi langsung tidak dapat dibuat — symmetric NAT, firewall perusahaan yang ketat — sesi akan direlay, dan TLS terminasi terjadi di relay. Siapa pun yang mengoperasikan relay tersebut berada dalam posisi untuk melihat lalu lintas yang direlay. Kami tidak akan mengatakan sebaliknya tentang milik kami.

Itu adalah sifat protokol, bukan siapa yang membayar server. Menjalankan relay sendiri tidak mengenkripsi sesuatu yang tidak akan dienkripsi oleh relay vendor; yang berubah adalah siapa yang menempati posisi itu. Jika jawaban Anda atas "siapa yang diizinkan menempati posisi itu" tertulis dalam kewajiban kepatuhan, self-hosting adalah jawaban yang benar dan sisa panduan ini untuk Anda. Jika tidak tertulis di mana pun, Anda mengambil pekerjaan operasional untuk menyelesaikan masalah yang sebenarnya tidak Anda miliki.

Apa yang sedang Anda bangun

Dua layanan:

• hbbs (rendezvous server): menangani handshake awal. Kedua klien terhubung kepadanya sebentar untuk menemukan satu sama lain, bertukar public keys, dan menentukan apakah P2P langsung mungkin. Mendengarkan pada TCP/UDP 21115-21117.
• hbbr (relay server): membawa sesi ketika P2P langsung gagal. Mendengarkan pada TCP 21117 (dan UDP untuk beberapa skenario).

Relay hanya terpakai saat P2P tidak bekerja — umum pada consumer NAT, jarang pada pengaturan LAN yang sama. Jadi meskipun di-host sendiri, Anda hanya membayar bandwidth VPS untuk sesi yang benar-benar membutuhkan relaying.

Langkah 1: Pilih VPS

Bandwidth adalah sumber daya yang penting. CPU dan RAM minimal, karena relay meneruskan byte, bukan memprosesnya.

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centres) — rasio harga-ke-bandwidth terbaik.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — UX bagus, region US/EU.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — terbaik untuk skenario bandwidth tinggi.

Pilih region dekat dengan klien yang akan terhubung. Lalu lintas relay bergantung pada waktu bolak-balik (round-trip), jadi ini adalah pengungkit terbesar pada latensi yang dirasakan — dan, seperti dibahas di bawah, hal yang paling buruk ditangani oleh satu VPS.

Langkah 2: Siapkan server

Buat VPS baru dengan Ubuntu 22.04 atau Debian 12. SSH sebagai root.

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

Jangan lewatkan firewall. Konfigurasi default hanya membuka port yang diperlukan; sisanya harus dikunci.

Langkah 3: Jalankan hbbs + hbbr melalui Docker

Buat /opt/tenvo-relay/docker-compose.yml:

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"
      - "21116:21116/tcp"
      - "21116:21116/udp"
      - "21118:21118/tcp"
    command: hbbs -r your-server.example.com:21117
    volumes:
      - ./data:/root
  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    restart: unless-stopped
    ports:
      - "21117:21117/tcp"
      - "21119:21119/tcp"
    command: hbbr
    volumes:
      - ./data:/root

Ganti your-server.example.com dengan hostname yang sebenarnya, lalu jalankan:

cd /opt/tenvo-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

hbbs mencetak public key pada startup pertama. Simpan dari log (id_ed25519.pub di volume data) — klien menggunakannya untuk memverifikasi mereka terhubung ke relay Anda dan bukan peniru.

Langkah 4: Konfigurasikan DNS

Arahkan A record untuk relay.yourdomain.com ke IP VPS. IP langsung juga bekerja, tetapi hostname jauh lebih mudah dikelola jika Anda perlu migrasi nanti.

Langkah 5: Arahkan klien ke relay Anda

Bagian yang sering dilewati kebanyakan panduan. Setiap klien membutuhkan tiga nilai:

• Server ID = relay.yourdomain.com:21116
• Server relay = relay.yourdomain.com:21117
• Kunci publik = isi dari data/id_ed25519.pub dari VPS Anda

Di Windows, macOS dan Linux:

1. Buka klien Tenvo atau RustDesk.
2. Pengaturan → Jaringan → Server ID/Relay.
3. Masukkan ketiga nilai di atas dan simpan.
4. Restart klien.

Indikator status seharusnya berubah hijau dalam beberapa detik. Jika tetap merah, periksa aturan firewall dan bahwa kunci publik cocok persis — newline di akhir biasanya penyebabnya.

Langkah 6: Tambahkan TLS

Letakkan reverse proxy di depan port relay. Caddy adalah jalur tercepat:

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy menerbitkan dan memperbarui sertifikat Let's Encrypt untuk Anda. Perbarui klien agar menggunakan port 443 dengan TLS diaktifkan — ini juga membantu menembus firewall keluar yang hanya memperbolehkan 443.

Langkah 7: Cadangkan kunci

Direktori data/ menyimpan pasangan kunci server rendezvous. Kehilangannya berarti setiap klien harus dikonfigurasi ulang dengan kunci publik baru — secara manual, di setiap mesin.

# Local backup
rsync -avz vps:/opt/tenvo-relay/data/ ~/tenvo-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/tenvo-relay/data/id_ed25519* ~/tenvo-keys/

Simpan secara offline. Jika VPS pernah dikompromikan, Anda ingin membangun ulang pada mesin baru dengan kunci yang sama, sehingga klien yang ada terus bekerja tanpa berubah.

Mode kegagalan yang diabaikan tutorial

Klien tidak dapat menjangkau relay. Hampir selalu masalah firewall. Periksa ufw status, periksa bahwa security group penyedia cloud mengizinkan port yang sama, dan jalankan nc -vz relay.yourdomain.com 21116 dari klien untuk memastikan keterjangkauan.

Semuanya jatuh kembali ke relay. Symmetric NAT dan firewall perusahaan yang ketat memaksa setiap sesi melalui relay. Performa tetap terjaga, tetapi tagihan bandwidth Anda sekarang menjadi cerita utama bukan pengecualian.

Relay mati dan tidak kembali. Opsi Docker restart: unless-stopped menutup kasus umum. Ia tidak menutup kasus disk penuh, OOM kill, atau kernel panic — untuk itu Anda perlu monitoring yang memberi notifikasi kepada seseorang, dan orang itu adalah Anda.

Sertifikat kedaluwarsa. Otomatis di Caddy. Pada nginx + certbot itu menjadi cron job yang harus Anda ingat; certbot.eff.org punya panduan resmi.

Tagihan yang tidak ditunjukkan tutorial

VPS €4 adalah baris termurah di faktur, dan mengutipnya sebagai biaya self-hosting sama dengan mengutip harga beli mobil sebagai biaya mengemudi. Sisanya:

• Anda bertugas untuk relay Anda sendiri. Ketika relay mati jam 2 pagi, akses jarak jauh — yang biasanya Anda gunakan untuk memperbaikinya — tidak tersedia.
• Patching OS, terus-menerus. Server publik di internet adalah server yang menjadi tanggung jawab Anda untuk terus dipatch.
• Penjagaan kunci. Kehilangan data/ berarti Anda mengonfigurasi ulang setiap klien secara manual. Cadangan itu sekarang harus benar-benar Anda verifikasi, bukan sekadar dijadwalkan.
• Perpanjangan sertifikat. Otomatis sampai hari ketika tidak lagi otomatis.
• Satu region, satu mesin. Satu VPS berarti satu lokasi dan tanpa failover. Klien di sisi lain dunia membayar itu dalam latensi round-trip; jika mesin turun, semua turun.

Bandwidth adalah satu-satunya biaya yang benar-benar mudah diperkirakan. Perkiraan kasar per sesi yang direlay:

• Kualitas rendah, pekerjaan berisi teks: ~50 KB/s = 180 MB/jam
• Sedang, kerja kantor umum: ~200 KB/s = 720 MB/jam
• Tinggi, kerja video dan desain: ~1 MB/s = 3.6 GB/jam

20 TB/bulan pada Hetzner CX22 menutup kira-kira 5.500 jam sesi relayed kualitas tinggi. Untuk individu atau tim kecil batas itu hampir tidak pernah menjadi kendala — itulah poinnya. Jika bandwidth adalah alasan Anda ingin self-host, itu bukan alasan yang baik. Kendala utama adalah empat butir di atas.

Apa yang dilakukan relay yang dikelola sebagai gantinya

Arsitektur sama, operator berbeda. Armada relay bersifat multi-region bukan satu VPS, jadi klien tersambung ke sesuatu yang dekat dengan mereka daripada dekat dengan Anda. Ia dimonitor oleh orang yang pekerjaannya memang itu. Material kunci, patching dan perpanjangan sertifikat berhenti menjadi masalah Anda. Ketika sesuatu rusak jam 2 pagi, orang yang dipanggil bukan Anda.

Itulah yang dibeli langganan: Free di $0, Lite di $2.99/mo, Pro di $7.99/mo — lihat harga untuk isi tiap tingkatan, atau rencana bisnis jika Anda menerapkan di seluruh tim. Dibandingkan dengan VPS €4 plus jadwal on-call Anda sendiri, hitungannya tidak mendekati untuk kebanyakan orang.

Kapan self-hosting benar-benar pilihan yang tepat

Itu pilihan tepat ketika suatu kewajiban menentukannya: pekerjaan yang diatur di mana lalu lintas tidak boleh melewati infrastruktur pihak ketiga, jaringan terisolasi atau terbatas di mana relay eksternal tidak dapat dijangkau, atau aturan residensi yang memaksa Anda berada di yurisdiksi tertentu. Dalam kasus tersebut biaya operasional bukan overhead, melainkan persyaratan, dan panduan ini persis yang Anda butuhkan.

Juga penting bahwa opsi itu ada sama sekali. Tenvo berlisensi AGPL-3.0 dan stack server bersifat open source, jadi relay yang dikelola adalah kemudahan yang Anda beli, bukan penguncian yang Anda terima. Jika suatu hari kami tidak lagi berguna, jalan keluarnya adalah panduan di atas — itulah tujuan menerbitkannya. Lihat bagaimana build yang dikelola dibandingkan dengan RustDesk biasa, atau bagaimana model keamanan bekerja.

Ringkasan

1. VPS di region terdekat dengan klien Anda.
2. Docker, UFW, dan container hbbs/hbbr.
3. Sebuah A record DNS yang mengarah ke VPS.
4. Tiga nilai konfigurasi pada setiap klien: Server ID, server relay, kunci publik.
5. Cadangan offline dari data/ yang benar-benar pernah Anda pulihkan sekali.
6. TLS via Caddy, dan monitoring yang memberi notifikasi kepada Anda.

30 menit untuk menyiapkan; kepemilikan berlangsung tanpa batas. Jika suatu kewajiban menempatkan Anda di kursi itu, langkah-langkah di atas adalah keseluruhan pekerjaan. Jika tidak, mulailah dengan relay yang dikelola — unduh klien, dan kembali ke halaman ini pada hari ketika formulir kepatuhan membuatnya relevan.