Samodzielne hostowanie pulpitu zdalnego poradnik 2026

Jeśli wyszukasz "self-hosted remote desktop", trafisz na tuzin poradników kończących się na docker compose up -d. Instalacja to najprostsza część i faktycznie zajmuje około 30 minut. Ten przewodnik obejmuje ją w całości — a potem omawia część, która decyduje, czy w ogóle powinieneś to zrobić: ile kosztuje utrzymanie po zakończeniu tutoriala.

Krótka odpowiedź

Hostuj samodzielnie, gdy wymóg Cię do tego zmusza. Użyj relay zarządzanego, gdy nic tego nie wymaga. Brzmi to lakonicznie, więc oto właściwy test:

• Hostuj samodzielnie jeśli: pisemny obowiązek zgodności wymaga, by ruch sesji nie przechodził przez infrastrukturę stron trzecich; obsługujesz sieci izolowane fizycznie lub inaczej ograniczone, do których zewnętrzny relay jest nieosiągalny; albo przepisy o lokalizacji danych wskazują jurysdykcję, w której musisz pozostać.
• Użyj relay zarządzanego jeśli: Twój powód to dowolna wersja „Wolę uruchomić to sam”. To prawdziwe preferencje, ale też stała praca operacyjna — sprawdź rachunek poniżej, zanim się na to zgasisz.

Warto wyraźnie rozgraniczyć, z czego wybierasz, bo to nie są dwa różne produkty. Tenvo jest AGPL-3.0, a relay zarządzany uruchamia tę samą architekturę hbbs/hbbr, którą instaluje ten przewodnik. Wybór dotyczy tego, kto obsługuje maszynę, a nie tego, co robi oprogramowanie.

Na początek: co relay faktycznie może zobaczyć

To ma znaczenie przed wszystkim, bo zwykle jest to powód, dla którego ludzie sięgają po self-hosting — i zwykle jest opisywane błędnie.

W bezpośrednim połączeniu peer-to-peer sesja przebiega end-to-end między dwoma urządzeniami. Gdy nie da się ustalić bezpośredniego połączenia — symetryczny NAT, ścisłe zapory korporacyjne — sesja jest przekazywana przez relay i TLS kończy się na relayu. Kto obsługuje ten relay, jest więc w pozycji, by zobaczyć przekazywany ruch. Nie będziemy twierdzić inaczej w przypadku naszych usług.

To cecha protokołu, a nie tego, kto płaci za serwer. Uruchomienie relaya u siebie nie szyfruje niczego, czego nie szyfrowałby relay dostawcy; zmienia kto zajmuje tę pozycję. Jeśli w Twoim obowiązku zgodności jest zapisane, kto może ją zajmować, self-hosting jest prawidłowym wyborem i reszta tego przewodnika jest dla Ciebie. Jeśli tego nie ma nigdzie na piśmie, bierzesz na siebie pracę operacyjną, by rozwiązać problem, którego nie masz.

Co budujesz

Dwie usługi:

• hbbs (rendezvous server): obsługuje początkowe uzgadnianie. Oba klienty łączą się z nim krótko, by się odnaleźć, wymienić klucze publiczne i sprawdzić, czy bezpośrednie P2P jest możliwe. Nasłuchuje na TCP/UDP 21115-21117.
• hbbr (relay server): przenosi sesję, gdy bezpośrednie P2P zawiedzie. Nasłuchuje na TCP 21117 (i UDP w niektórych scenariuszach).

Relay włącza się tylko wtedy, gdy P2P nie działa — powszechne przy NAT konsumenckim, rzadkie w sieci lokalnej. Nawet samodzielnie hostując, płacisz za pasmo VPS tylko za sesje, które faktycznie wymagają relayowania.

Krok 1: Wybierz VPS

Pasmo to zasób, który się liczy. CPU i RAM są minimalne, ponieważ relay przekazuje bajty zamiast je przetwarzać.

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centres) — najlepszy stosunek ceny do pasma.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — dobra użyteczność, regiony US/EU.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — najlepszy przy scenariuszach wysokiego pasma.

Wybierz region blisko klientów, którzy będą się łączyć. Ruch przez relay zależy od czasu okrążeń (round-trip), więc to najskuteczniejsza dźwignia, jaką masz na odczuwalne opóźnienie — i, jak opisano poniżej, to rzecz, w której pojedynczy VPS wypada najgorzej.

Krok 2: Skonfiguruj serwer

Uruchom świeży VPS z Ubuntu 22.04 lub Debian 12. Zaloguj się przez SSH jako 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

Nie pomijaj zapory. Domyślna konfiguracja udostępnia tylko potrzebne porty; wszystko inne powinno być zablokowane.

Krok 3: Uruchom hbbs + hbbr przez Docker

Utwórz plik /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

Zamień your-server.example.com na rzeczywistą nazwę hosta, następnie uruchom:

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

hbbs wypisuje klucz publiczny przy pierwszym uruchomieniu. Zapisz go z logów (id_ed25519.pub w wolumenie data) — klienci używają go, by zweryfikować, że łączą się z Twoim relayem, a nie z impostorem.

Krok 4: Skonfiguruj DNS

Wskaż rekord A dla relay.yourdomain.com na IP VPS. Sama nazwa hosta działa również, ale hostname jest znacznie łatwiejszy w utrzymaniu, jeśli kiedykolwiek migrujesz.

Krok 5: Wskaż klientom Twój relay

Część, którą większość poradników pominie. Każdy klient potrzebuje trzech wartości:

• ID server = relay.yourdomain.com:21116
• Relay server = relay.yourdomain.com:21117
• Public key = zawartość pliku data/id_ed25519.pub z Twojego VPS

Na Windows, macOS i Linux:

1. Otwórz klienta Tenvo lub RustDesk.
2. Ustawienia → Sieć → ID/Relay server.
3. Wprowadź powyższe trzy wartości i zapisz.
4. Uruchom klienta ponownie.

Indykator statusu powinien w kilka sekund zmienić się na zielony. Jeśli pozostaje czerwony, sprawdź reguły zapory i czy klucz publiczny zgadza się dokładnie — najczęstszą przyczyną jest dodatkowy znak nowej linii na końcu.

Krok 6: Dodaj TLS

Postaw reverse proxy przed portami relaya. Caddy to najkrótsza ścieżka:

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

Caddy wystawi i odnowi certyfikat Let's Encrypt za Ciebie. Zaktualizuj klientów, by korzystali z portu 443 z włączonym TLS — to także przepuści połączenia przez restrykcyjne firewalle wychodzące, które pozwalają tylko na 443.

Krok 7: Zrób kopię kluczy

Katalog data/ zawiera parę kluczy rendezvous servera. Jeśli go zgubisz, każdy klient trzeba będzie przekonfigurować z nowym kluczem publicznym — ręcznie, na każdej maszynie.

# 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/

Przechowuj kopię offline. Jeśli VPS zostanie kiedykolwiek skompromitowany, chcesz odtworzyć usługę na świeżym serwerze z tymi samymi kluczami, aby istniejący klienci dalej działały bez zmian.

Scenariusze awaryjne, które tutoriale pomijają

Klienci nie mogą dotrzeć do relaya. Prawie zawsze to zapora. Sprawdź ufw status, sprawdź, czy grupa bezpieczeństwa dostawcy chmury pozwala te same porty, i uruchom nc -vz relay.yourdomain.com 21116 z klienta, by potwierdzić osiągalność.

Wszystko przełącza się na relay. Symetryczny NAT i ścisłe zapory korporacyjne zmuszają każdą sesję przez relay. Wydajność zwykle pozostaje, ale rachunek za pasmo staje się teraz główną pozycją zamiast wyjątku.

Relay pada i nie wraca. Dockerowe restart: unless-stopped obejmuje typowe przypadki. Nie obejmuje pełnego dysku, zabicia przez OOM czy paniki jądra — na to potrzebujesz monitoringu, który otaguje stronę, a tą osobą jesteś Ty.

Certyfikat wygasa. Automatyczne przy Caddy. Przy nginx + certbot to zadanie cron, o którym musisz pamiętać, że go posiadasz; certbot.eff.org ma oficjalny przewodnik.

Rachunek, którego tutoriale nie pokazują

€4 VPS to najtańsza pozycja na fakturze i cytowanie jej jako kosztu self-hostingu to ten sam trik, co podanie ceny zakupu auta jako kosztu jazdy. Reszta to:

• Jesteś na wezwanie dla własnego relaya. Gdy padnie o 2 rano, dostęp zdalny jest tym, czego już nie będziesz miał, by to naprawić.
• Łatanie OS, na zawsze. Publicznie wystawiony serwer to serwer, za który odpowiadasz utrzymaniem aktualizacji.
• Opieka nad kluczami. Utrata data/ oznacza ręczną rekonfigurację każdego klienta. Ta kopia zapasowa to teraz coś, co musisz faktycznie weryfikować, a nie tylko zaplanować.
• Odnawianie certyfikatu. Automatyczne do dnia, w którym takie nie będzie.
• Jeden region, jedna maszyna. Pojedynczy VPS to jedna lokalizacja i brak failoveru. Klienci po drugiej stronie świata płacą za to opóźnieniem; jeśli maszyna padnie, wszyscy padną.

Pasmo to jedyny koszt, który naprawdę łatwo oszacować. Przybliżone wartości na jedną relayed sesję:

• Niska jakość, praca tekstowa: ~50 KB/s = 180 MB/godzinę
• Średnia, typowa praca biurowa: ~200 KB/s = 720 MB/godzinę
• Wysoka, praca wideo i grafika: ~1 MB/s = 3.6 GB/godzinę

20 TB/miesiąc z Hetzner CX22 wystarcza na około 5 500 godzin sesji w wysokiej jakości. Dla osoby indywidualnej lub małego zespołu ten limit zwykle nie jest ograniczeniem — i właśnie o to chodzi. Jeśli powodem self-hostingu miało być pasmo, to słaby argument. Wiążące ograniczenia to cztery punkty powyżej.

Co robi relay zarządzany inaczej

Ta sama architektura, inny operator. Flota relayów jest wieloregionowa, a nie jeden VPS, więc klienci łączą się z czymś bliskim sobie zamiast blisko Ciebie. Jest monitorowana przez osoby, dla których to praca. Materiały kluczy, łatanie i odnawianie certyfikatów przestają być Twoim problemem. Gdy coś psuje się o 2 rano, osoba powiadomiona to nie Ty.

To, co daje subskrypcja: Free at $0, Lite at $2.99/mo, Pro at $7.99/mo — zobacz pricing, co znajduje się w każdym progu, lub the business plans, jeśli wdrażasz to w zespole. W zestawieniu z €4 VPS i własnym harmonogramem dyżurów, rachunek dla większości osób nie wypada na korzyść self-hostingu.

Kiedy self-hosting jest naprawdę właściwy

Jest właściwy, gdy obowiązek to wymienia: prace regulowane, gdzie ruch nie może przechodzić przez infrastrukturę stron trzecich, sieci izolowane lub ograniczone, gdzie zewnętrzny relay jest nieosiągalny, albo przepisy o lokalizacji danych, które wiążą Cię z jurysdykcją. W takich przypadkach koszt operacyjny nie jest narzutem, tylko wymogiem, i ten przewodnik to dokładnie to, czego potrzebujesz.

Ważne jest też, że opcja w ogóle istnieje. Tenvo jest AGPL-3.0, a stos serwerowy jest open source, więc relay zarządzany to wygoda, którą kupujesz, a nie blokada, którą akceptujesz. Jeśli przestaniemy być warci opłaty, wyjście to powyższy przewodnik — o to chodzi w jego publikacji. Zobacz how the managed build compares to plain RustDesk, albo how the security model works.

Podsumowanie

1. VPS w regionie najbliższym Twoim klientom.
2. Docker, UFW i kontenery hbbs/hbbr.
3. Rekord DNS A wskazujący na VPS.
4. Trzy wartości konfiguracyjne w każdym kliencie: ID server, relay server, public key.
5. Offline'owa kopia data/, którą rzeczywiście kiedyś przywróciłeś.
6. TLS przez Caddy i monitoring, który Cię powiadamia.

30 minut na postawienie; nieokreślony czas na utrzymanie. Jeśli wymóg stawia Cię w tej roli, powyższe kroki to cała praca. Jeśli nic tego nie wymaga, zacznij od relay zarządzanego — download the client, i wróć na tę stronę, gdy formularz zgodności sprawi, że to będzie istotne.