Archived

This repository has been archived on 2026-08-04. You can view files and clone it, but cannot push or open issues or pull requests.

Adam Moussa 9f18ecab50

Add RustDesk Server Pro self-hosted relay stack

Scaffold the CDK stack for a self-hosted RustDesk Server Pro relay so
remote support no longer depends on the public RustDesk rendezvous/relay
infrastructure.

Single ARM64 EC2 (SSM-managed, no SSH) runs hbbs+hbbr in Docker. The
server key pair and DB live on a standalone RETAINed EBS volume so they
survive instance replacement (clients keep trusting the same key). Relay
ports are public; the Pro admin console (21114) is restricted to the
office VPN + VPC. IMDSv2 is enforced and the data dir is locked to root.
EIP + rustdesk.seahaven.com give clients a stable address.

2026-06-28 16:47:32 -04:00

3.1 KiB

Raw Blame History

RustDesk Server — Runbook

Operational procedures for the rustdesk-server stack. Account 328440206208, us-east-1.

Access

The instance is SSM-managed (no inbound SSH):

aws ssm start-session --target <instance-id> --region us-east-1

Find the instance: aws ec2 describe-instances --filters Name=tag:Name,Values=rustdesk-server.

The data volume (read this before any redeploy)

All durable state — the id_ed25519 server key pair and the sled database — lives on the standalone EBS volume rustdesk-data, mounted at /var/lib/rustdesk, attached at /dev/xvdf.

It is declared as a separate ec2.Volume with RemovalPolicy.RETAIN, not an inline blockDevice. This is deliberate: an inline data volume gets replaced whenever CloudFormation replaces the instance, which would destroy the server key and force every client to re-trust the host.
userdata/bootstrap.sh mounts the existing filesystem and only runs mkfs when blkid reports the device is blank, so reattaching to a fresh instance preserves data.
Before any change that may replace the instance (AMI bump, instance-type change), confirm a recent EBS snapshot exists and that the key pair is mirrored to rustdesk/server-key-pair.

Instance replacement

A replaced instance reattaches the same RETAINed volume and remounts it without reformatting, so the server key and DB are preserved. After replacement:

Confirm docker compose ps shows hbbs and hbbr healthy (cd /opt/rustdesk).
Confirm clients still connect without re-accepting a new key.

Server key pair

hbbs generates /var/lib/rustdesk/id_ed25519 (private) and id_ed25519.pub (public) on first boot. The public key is the fingerprint clients must trust.

Mirror after first deploy / after any intentional rotation. Read the key with fileb:// so it never lands in process argv (ps//proc), shell history, or the terminal (which SSM session logging would capture):

sudo aws secretsmanager put-secret-value \
  --secret-id rustdesk/server-key-pair \
  --secret-string fileb:///var/lib/rustdesk/id_ed25519 \
  --region us-east-1

Run this from an environment that holds secretsmanager:PutSecretValue — the instance role only has GetSecretValue, so either configure operator credentials on the box first, or pull the key off the host over SSM (without echoing it) and push it from your workstation. Never cat the private key to the terminal.

To rotate the key (forces all clients to re-trust): stop the containers, delete id_ed25519*, restart, re-mirror, redistribute the new public key.

Restore from snapshot

Create a volume from the desired snapshot in us-east-1a.
Detach the current rustdesk-data volume (stop the instance first).
Attach the restored volume at /dev/xvdf, tag Name=rustdesk-data, start the instance.
Verify the key pair and DB are present and containers come up healthy.

Pro license

Activated in the web console (http://rustdesk.seahaven.com:21114). Keep the key in rustdesk/pro-license.

Logs

cd /opt/rustdesk && docker compose logs -f hbbs hbbr

3.1 KiB Raw Blame History