-
Notifications
You must be signed in to change notification settings - Fork 2
Multi Node Deployment
English | 简体中文
Use this topology when one Starry HBBS centre must allocate several HBBR nodes. Each HBBS and HBBR uses the same pinned Starry image tag. HBBR remains unmodified upstream code, but this version lock avoids compatibility problems caused by independent image updates. An account/API service is optional and remains independent.
flowchart LR
A[Client A] -->|register and signal| S[Starry HBBS centre]
B[Client B] -->|register and signal| S
S -->|selected Relay address| A
S -->|selected Relay address| B
A <-->|native 21117 or WSS /ws/relay| R1[Starry-image HBBR 1]
B <-->|native 21117 or WSS /ws/relay| R1
S -. optional account layer .-> API[Third-party API]
S --> R2[Starry-image HBBR 2]
S --> R3[Starry-image HBBR N]
HBBS chooses a Relay; HBBR carries the session. The API does neither.
Example-only names:
| Role | Name | Public paths |
|---|---|---|
| Centre HBBS | id.example.com |
21116/TCP+UDP; optional wss://id.example.com/ws/id
|
| API | api.example.com |
optional HTTPS 443/TCP
|
| Relay 1 | relay-1.example.com |
21117/TCP; optional wss://relay-1.example.com/ws/relay
|
| Relay 2 | relay-2.example.com |
same |
Every WSS URL must use a hostname covered by its certificate. Do not replace a failed certificate-matching name with an IP or disable verification.
- The centre generates
id_ed25519andid_ed25519.pub. - The private key stays only in the protected centre data and its backups.
- Clients receive the public-key content.
- Relay-only nodes receive only that same public key through the HBBR
KEYsetting. - A community API that needs the server identity mounts only
id_ed25519.pub, read-only.
Never copy the centre private key to every Relay.
Use:
cd /opt/rustdesk-center
cp /path/to/repository/examples/center/.env.example .env
cp /path/to/repository/examples/center/compose.bootstrap.yaml .
mkdir -p data/server
docker compose --env-file .env -f compose.bootstrap.yaml config --quiet
docker compose --env-file .env -f compose.bootstrap.yaml up -d
test -s data/server/id_ed25519
test -s data/server/id_ed25519.pubBack up the identity before continuing. Confirm a basic native client registration against this HBBS.
Start from config.geo-basic.yaml or config.websocket.yaml. The complete
candidate pool belongs in relay_servers:
relay_servers:
- relay-1.example.com:21117
- relay-2.example.com:21117Every Geo rule may reference only entries in that pool. Rule order and each rule's Relay order are strict priority, not round-robin.
If WebSocket Signal is enabled, relay_health.endpoints must cover this pool
exactly:
websocket_signal:
enabled: true
relay_health:
endpoints:
- relay: relay-1.example.com:21117
url: wss://relay-1.example.com/ws/relay
- relay: relay-2.example.com:21117
url: wss://relay-2.example.com/ws/relayDo not enable it until both exact paths return a valid TLS/WebSocket Upgrade and the real client acceptance path is ready.
Use:
On each Relay:
mkdir -p /opt/rustdesk-relay/data
cd /opt/rustdesk-relay
cp /path/to/repository/examples/relay/compose.yaml .
cp /path/to/repository/examples/relay/.env.example .envPaste the one-line centre public key into RUSTDESK_PUBLIC_KEY. Then:
docker compose --env-file .env -f compose.yaml config --quiet
docker compose --env-file .env -f compose.yaml up -d
docker compose --env-file .env -f compose.yaml logs --tail 100 hbbrThe optional Relay tuning values belong to the unmodified upstream HBBR in the pinned Starry image, not to the Starry HBBS overlay:
| Environment variable | Example | Unit and effect |
|---|---|---|
RELAY_SINGLE_BANDWIDTH |
128 |
Mb/s cap for one Relay session |
RELAY_TOTAL_BANDWIDTH |
1024 |
Mb/s aggregate cap for the HBBR process |
RELAY_LIMIT_SPEED |
32 |
Mb/s cap after a session is downgraded |
RELAY_DOWNGRADE_START_CHECK |
1800 |
Seconds before downgrade eligibility |
RELAY_DOWNGRADE_THRESHOLD |
0.66 |
Average-use fraction of the single-session cap that triggers downgrade eligibility |
These are explicit example limits. Size them for the node and verify the effective values in HBBR startup logs.
Open 21117/TCP. When WebSocket is required, install a certificate-valid
Nginx /ws/relay and expose 443/TCP; keep backend 21119/TCP private.
Use examples/center/compose.yaml
in the same Compose project and data paths as the bootstrap file:
cp /path/to/repository/examples/center/compose.yaml .
docker compose --env-file .env -f compose.bootstrap.yaml down
docker compose --env-file .env -f compose.yaml config --quiet
docker compose --env-file .env -f compose.yaml up -dDo not leave the bootstrap HBBS and full-stack HBBS running as two projects.
The full Starry reference intentionally contains only the HBBS/HBBR data
plane. A compatible third-party API can be added separately; the recommended
implementation is
q1ngyang/rustdesk-api-kessoku.
Follow the Kessoku Wiki
for its current version and deployment requirements. The dedicated joint
deployment page is still in preparation and will be linked from
Account/API Integration.
Do not mount Starry private keys into an API container.
- Centre WSS:
center.example.conf - Every Relay:
relay.example.conf
The generic API example is not a Kessoku proxy contract. Follow the API project's own Wiki for its public and internal listeners.
See Reverse Proxy and TLS before enabling WebSocket Signal.
- Every Relay HBBR process is running and its public port is reachable.
- Centre
relay-serverslists the expected allocation pool after the health refresh interval. -
test-georeturns the intended first online Relay for representative IP pairs. - Disable one priority Relay and prove ordered failover, then restore it.
- When WSS is enabled,
websocket-statusshows the correct per-Relay native and WSS state. - Complete native, WSS, and mixed real-client sessions and correlate the same Relay UUID in the evidence.
- Test API login separately, then repeat Secure TCP and remote control while logged in.
An HBBS-to-HBBR reachability result is not client-to-Relay latency or packet loss. Do not market centre ping as endpoint path quality.
- Documentation home
- Getting started
- Docker image usage
- Docker deployment
- Native deployment
- Multi-node deployment
- Reverse proxy and TLS
- Client configuration
- Account/API integration
- Configuration reference
- Connection authentication
- Control Agent
- GEO rules: basics
- GEO rules: advanced
- Operations and verification
- Troubleshooting
- Upgrade and rollback
- Architecture and build
- 文档主页
- 快速开始
- Docker 镜像使用
- Docker 部署
- 原生部署
- 中心与 Relay 多节点部署
- 反向代理与 TLS
- 客户端配置
- 账户与 API 服务接入
- 配置参数详解
- 连接认证
- Control Agent
- Geo 规则:入门
- Geo 规则:进阶
- 运维与完整验证
- 常见问题排查
- 版本升级与回滚
- 架构与构建