Self-hosted remote desktop on a $5 VPS: setup guide

This guide walks through a practical “self host remote desktop vps” setup you can run on a $5 VPS — SSH keys, firewall, WireGuard, TLS. First, the honest test: self-host when a requirement forces you to — a written compliance obligation, an isolated network, a data-residency rule. When nothing forces you to, a managed relay works out cheaper once you count the whole bill: on-call, patching, key custody, certificate renewal, one region and no failover. The full arithmetic is in Self-hosted remote desktop: the honest 2026 guide.

Why a $5 VPS is a sensible starting point

For remote desktop use cases (single user, occasional sessions), a low-end VPS is often sufficient. Common $5-ish plans (for example, a 1 vCPU / 1GB RAM / 25GB SSD droplet) on providers such as DigitalOcean, Vultr or Linode handle a single concurrent session, headless server agents, and a lightweight relay or VPN.

This guide uses Ubuntu 22.04 LTS (stable, widely supported) and assumes the VPS will be reachable over the public internet. If your needs include GPU, multi-monitor high-FPS streaming, or many concurrent users, you’ll need a bigger plan — a dedicated workstation for the heavy end, and the managed Tenvo relay for the connectivity, so a single $5 box in one region isn’t the bottleneck.

Plan: what you’ll run and ports to expect

The minimal architecture here:

• VPS (Ubuntu 22.04) with public IP
• SSH for management (key-only)
• WireGuard as the secure tunnel (optional but recommended)
• Remote-desktop server (we’ll use Tenvo as an example agent) running as a systemd service
• Optional domain + Let's Encrypt TLS and nginx reverse proxy for web-based clients

Expected resource usage: the agent and VPN will sit under 500MB RAM when idle; bandwidth during an active session runs about 50 KB/s (180 MB/hour) for text-heavy work, ~200 KB/s (720 MB/hour) for general office use, and ~1 MB/s (3.6 GB/hour) for video or design work — roughly 0.4–8 Mbps depending on codec and screen activity. Budget: $5/month VPS + domain (~$10/year) if you want TLS. If you prefer no public ports, see Remote Desktop Without Port Forwarding Explained.

Step 1 — provision the VPS and lock down access

Create a $5 VPS with Ubuntu 22.04. When creating the instance choose SSH key authentication (you can add your public key in the provider console). Example providers offer similar plans: DigitalOcean 1GB/1vCPU ($5), Vultr 1GB ($5), Linode Nanode ($5). The exact SKU varies, but the network and CPU specs are comparable.

Initial hardening commands (run as root or a sudo user):

apt update && apt upgrade -y
adduser adminuser
usermod -aG sudo adminuser
ufw allow OpenSSH
ufw enable

Edit /etc/ssh/sshd_config to disable password auth and root login (set PasswordAuthentication no and PermitRootLogin no). Restart SSH: systemctl restart sshd. This prevents brute-force attempts against your VPS.

Step 2 — firewall, fail2ban, and rate limits

Keep the firewall minimal. If you plan to use WireGuard put only the WireGuard UDP port in the public rules; if you run the remote agent directly you may need one TCP port. Example UFW rules:

ufw allow 22/tcp          # SSH
ufw allow 51820/udp       # WireGuard (if used)
ufw allow 8443/tcp        # optional remote desktop web port
ufw enable

Install fail2ban to automatically ban repeated attempts and reduce noise: apt install -y fail2ban. Use the default jail for sshd and tune ban times to your risk tolerance.

Step 3 — secure networking options: direct ports, VPN, or reverse relay

Three practical network patterns:

• Open port to the internet: simplest but higher attack surface. Use TLS and strong auth if you expose an app port.
• WireGuard tunnel: the most secure straightforward option if you are running the box yourself. Create a private network between your client device and the VPS; only the WireGuard port is public.
• Relay/Reverse-connect: the client makes an outbound connection to a rendezvous server, so no inbound ports are needed on either end — useful behind NAT and without a VPN. This is what the managed Tenvo relay does, on a multi-region fleet instead of one VPS. Note that when a session falls back to the relay, TLS terminates there, so whoever operates the relay is in a position to see that traffic — yours or ours. Background on the pattern: Self-Hosted Remote Desktop: Why, How, and What Breaks.

WireGuard quickstart (server on VPS):

apt install -y wireguard iproute2
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
# create /etc/wireguard/wg0.conf and include keys + peers
systemctl enable --now wg-quick@wg0

WireGuard config specifics depend on your client platform; there are many tutorials and client apps for Linux, macOS, Windows, Android, and iOS. Using WireGuard means the remote desktop traffic is directly routed over an encrypted tunnel — no public app port required on the client machine.

Step 4 — install the remote desktop server (Tenvo example)

Be precise about what goes on the VPS: not a desktop agent, but the rendezvous and relay pair — hbbs and hbbr — which brokers the handshake and carries the session when a direct connection can’t be made. Tenvo is AGPL-3.0 and runs that same stack, so you can host it yourself; the working Docker install, ports, keys and client config are written out step by step in Self-hosted remote desktop: the honest 2026 guide. The desktop clients themselves come from the download page. The systemd sketch below is a generic pattern for whichever service you end up running.

Example: installing a generic remote agent as a systemd service (replace the binary and flags with the agent you choose):

mkdir -p /opt/remote-relay
# scp or wget your chosen server binary to /opt/remote-relay/relay-server
chown root:root /opt/remote-relay/relay-server
chmod +x /opt/remote-relay/relay-server

cat >/etc/systemd/system/remote-relay.service <<'EOF'
[Unit]
Description=Remote desktop relay
After=network.target

[Service]
ExecStart=/opt/remote-relay/relay-server
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now remote-relay.service

Configure the agent with a strong key or password and, if supported, restrict which client public keys are allowed. If you use WireGuard, configure the agent to bind to the WireGuard interface or to the loopback address so it's not reachable via the public IP.

TLS, domain, and reverse proxy (optional)

If you have a web-based client (or an admin UI), put nginx in front and use Let's Encrypt for TLS. Practical certbot commands on Ubuntu 22.04:

apt install -y nginx certbot python3-certbot-nginx
# create nginx site for example.com and proxy_pass to localhost:8443
certbot --nginx -d example.com

Keep the TLS certificate auto-renewal cron active (certbot sets this up). If you use a domain, point an A record to your VPS IP and use the domain in your client configurations. TLS protects web UIs and browser-based clients; it doesn't replace strong agent authentication.

Testing and verification

Basic checks:

• SSH: attempt a password login — it should fail.
• WireGuard: bring up the client and ping the VPS WireGuard IP.
• Agent: connect from your client to the agent over the WireGuard interface or TLS endpoint; verify latency and audio/video quality.
• Logs: check journalctl -u remote-relay -f (whatever you named the unit above) and /var/log/nginx/error.log while connecting.

Measure bandwidth and CPU during a session. If you observe high CPU on the VPS, reduce the encoding quality, lower frame rate, or move the session broker to a more capable instance.

Maintenance: updates, backups, and monitoring

Schedule OS updates and reboot windows during low-use periods. Use unattended-upgrades for security patches but test major upgrades manually. Snapshot your VPS disk via the provider before risky changes, and store a copy off-site for recovery.

Monitoring tips: enable basic monitoring in your provider console (most show CPU, bandwidth, and disk) and consider a simple alerting setup (email on out-of-disk or high CPU). Keep your SSH keys rotated yearly and revoke any lost keys immediately.

When this isn't the right choice

Self-hosting on a $5 VPS is a fine fit for a lab box, or when a requirement leaves you no choice. For personal use and small teams it is usually the more expensive option once your own time is on the invoice. It’s also not the right call if you need:

• Low latency for clients spread across regions, or any kind of failover — one $5 VPS is one location and one box. The managed Tenvo relay runs the same hbbs/hbbr stack on a multi-region fleet: Free $0, Lite $2.99/mo, Pro $7.99/mo, against $5 for the VPS plus your own on-call rota, patching and certificate renewal. For a team, see the business plans.
• GPU-accelerated streaming or many simultaneous users — those need larger instances or dedicated hardware.

For security-minded readers, also read our deeper piece on securing remote access: Remote Desktop Security: What You Need to Know. For the hosted-versus-self-hosted arithmetic in full — bandwidth, on-call, key custody, certificate renewal — see Self-hosted remote desktop: the honest 2026 guide.

Wrap up and next steps

Technically this is straightforward: use SSH keys, lock the box down with a firewall, prefer WireGuard so fewer application ports are exposed, and run the service under systemd. What the steps above don’t show is the standing cost — you are the on-call rota, the patching schedule, the key custody and the certificate renewal, on one box in one region with nothing to fail over to. Worth it when a compliance obligation, an isolated network or a residency rule requires it. Not worth it otherwise.

So: if a requirement obliges you to self-host, spin up the $5 VPS, follow the steps above, and use Self-hosted remote desktop: the honest 2026 guide for the working hbbs/hbbr install and the full running-cost breakdown. If nothing obliges you, skip the box: download the client and start on the managed relay — Free $0, Lite $2.99/mo, Pro $7.99/mo at pricing, or business plans for a team.