-
Notifications
You must be signed in to change notification settings - Fork 2
Architecture and Build
English | 简体中文
Starry is a reproducible source overlay, not a permanent fork of the complete RustDesk Server tree. It keeps the official server revision explicit, patches only HBBS-related source paths, and uses the unmodified upstream HBBR contract.
RustDesk client
|-- API HTTPS --------------------> optional third-party API
|-- native 21116 or WSS /ws/id ---> Starry HBBS
| | selects one Relay
|-- P2P, native 21117, or /ws/relay -> bundled unmodified HBBR
| Component | Starry change | State/role |
|---|---|---|
| HBBS | Yes | Peer registration, rendezvous, Secure TCP negotiation, persistent WSS signalling, Geo evaluation, and Relay allocation. |
| HBBR | No | Carries relayed remote-control data. The release may bundle a convenience build from the same pinned official revision. |
| Control Agent | Separate Starry binary | Linux-only least-privilege management API for one local HBBS; mTLS/service JWT remotely and a bounded loopback protocol locally. |
rustdesk-utils |
No | Convenience upstream utility artifact. |
| API | Not included | Login, address book, device/admin data; select and secure independently. |
| Client | Not included | Chooses native or WebSocket and performs P2P/HBBR data exchange. |
The separation matters operationally. API success does not prove an HBBS handshake. HBBS registration does not prove HBBR reachability. HBBR health does not prove a two-client desktop session.
| Path | Purpose |
|---|---|
scripts/apply_overlay.py |
Verifies unique upstream source anchors, copies Starry modules/tests/config template, and injects integration points. |
overlay/src/starry_config.rs |
Strict schema, defaults, cross-field validation, artifact generation, and atomic configuration state. |
overlay/src/geo_relay.rs and geo_relay/
|
MMDB readers/updater, fact extraction, expression compiler, and ordered Relay selection. |
overlay/src/secure_tcp.rs |
Client-compatible native Secure TCP negotiation, authenticated key exchange, and framed encrypted transport. |
overlay/src/websocket_signal.rs and websocket_signal/
|
/ws/id admission, persistent registration/session routing, resource limits, effective client IP, and Relay health. |
overlay/src/connection_auth.rs |
Ed25519 JWT/JWKS/introspection verification and bounded metrics/cache state. |
overlay/src/relay_observer.rs and allocation_explain.rs
|
Immutable runtime snapshots and the shared pure allocation-decision core. |
overlay/src/local_control.rs |
Bounded loopback STARRYCTL/1 framing and legacy local-command compatibility. |
overlay/src/control_agent.rs and control_agent/
|
mTLS/RBAC Control API, local client, durable config transactions, audit, history, rollback, and recovery. |
overlay/tests/ |
Real-process WebSocket/mixed, connection-auth, local-control, and Control Agent/fault integration tests. |
config/ |
Full schema example plus deployable feature profiles. |
docker/Dockerfile |
Runtime image containing the release binaries; default command starts Starry HBBS. |
The application script requires exactly one match for every structural anchor.
If official source changes invalidate an anchor, the build stops. CI applies
the overlay twice; the second pass must be idempotent and the patched tree must
pass git diff --check.
- HBBS obtains both effective public client addresses. For WSS, forwarded headers are accepted only from configured trusted proxy CIDRs.
- The requested transport produces an eligibility set: native-online, WSS-health-verified, or their intersection for mixed mode.
- Geo readers extract only the facts required by compiled rules.
- Rules run in document order; optional symmetry exchanges client A and B.
- The first eligible Relay in a matching rule's list wins.
- If no rule selects, official-style round-robin runs over the eligible set.
- No eligible WSS/mixed Relay produces an empty allocation instead of an knowingly incompatible endpoint.
Native relay eligibility remains based on the official online Relay mechanism.
WSS eligibility comes from normal DNS/TCP/TLS, certificate hostname/chain, and
an exact WebSocket Upgrade to /ws/relay.
- Serde denies unknown fields at every schema level.
- Numeric limits, unique values, URL structure, CIDRs, Origins, and all Relay cross-references are validated before activation.
- Missing/empty/invalid Starry configuration keeps official-compatible behaviour; a partially parsed policy is never applied.
- Reload is document-atomic: a complete valid document becomes active; an empty/invalid one disables Starry and does not retain the previous Starry state. Partial policy is never applied.
- MMDB replacement uses a temporary file, structural/readability checks, and atomic replacement; the last readable file is retained on failure.
- Management commands are intended only through loopback
21115inside the HBBS namespace. - WSS registration has frame, queue, session, per-IP, timeout, and rate limits.
These controls reduce configuration and exposure errors; they do not replace host hardening, secret management, monitoring, backups, or real-client testing.
The canonical procedure is the GitHub Actions workflow. For local audit or development on a supported Linux build host:
git clone https://github.com/q1ngyang/rustdesk-server-starry.git
cd rustdesk-server-starry
git init _upstream
git -C _upstream remote add origin \
https://github.com/rustdesk/rustdesk-server.git
git -C _upstream fetch --depth 1 origin 1.1.16
git -C _upstream checkout --detach FETCH_HEAD
git -C _upstream submodule update --init --recursive --depth 1
python3 scripts/apply_overlay.py _upstream
python3 scripts/apply_overlay.py _upstream
git -C _upstream diff --check
cargo metadata --manifest-path _upstream/Cargo.toml \
--format-version 1 >/dev/null
cargo test --manifest-path _upstream/Cargo.toml --locked --lib -j 1
cargo check --manifest-path _upstream/Cargo.toml --locked --bins -j 1
cargo test --manifest-path _upstream/Cargo.toml --locked \
--test websocket_signal -j 1 -- --nocapture
cargo test --manifest-path _upstream/Cargo.toml --locked \
--test mixed_relay -j 1 -- --nocapture
cargo build --manifest-path _upstream/Cargo.toml --locked --release --binsReplace 1.1.16 only with a reviewed official release reference. Official
RustDesk Server build prerequisites and Rust toolchain requirements also apply.
An overlay anchor failure is a request to review upstream changes, not an error
to bypass with a broad search-and-replace.
The resulting hbbs contains Starry changes. hbbr and rustdesk-utils are
the unmodified upstream sources compiled from the same checkout.
The workflow resolves the official ref and constructs
<upstream>-patch-v<PATCH_VERSION>. Before publication it performs:
- Compose static validation;
- exact shallow upstream checkout and recursive submodules;
- twice-applied overlay/idempotency and dependency-lock checks;
- Rust formatting, all library tests, and all server-binary checks;
- real-process WSS registration and cross-transport signalling tests;
- mixed WebSocket/native traffic through the bundled unmodified HBBR;
- static Linux
amd64builds; - installation and command-level runtime checks for amd64 Debian packages under the digest-pinned Debian test image;
- a
linux/amd64container smoke test; and - assembly of the exact downloadable candidate, including source/final-tree SPDX SBOMs, deterministic archives, build inputs, and verified checksums.
Only the separately approved publication job has write permissions. It signs
the candidate checksums and SBOM with GitHub/Sigstore artifact attestations,
attaches the portable bundles, then pushes the linux/amd64 image with
OCI provenance and SBOM and creates or updates the GitHub Release.
ARM remains best-effort source compatibility, and the Windows build is an experimental non-blocking check. Neither enters the patch-v1.2.0 candidate.
A successful candidate build does not itself change a Release, attestation store, or GHCR package. Deployment acceptance remains the operator's responsibility.
The GHCR image contains hbbs, hbbr, and rustdesk-utils for convenience.
Its default command runs:
hbbs --starry-config=/root/starry/config.yaml
The recommended Compose files use one pinned Starry image tag for both HBBS
and HBBR. This prevents independently updated images from drifting while the
command boundary still makes the modification scope explicit: hbbs contains
the overlay and bundled hbbr remains unmodified upstream code.
Release checksums cover downloadable assets. Portable Sigstore bundles and GitHub artifact attestations bind the downloadable subjects to their build and SBOM assertions. Image digests, OCI provenance, and OCI SBOM describe the container supply chain; verify them according to your own trust policy.
When changing either upstream or patch version:
- review upstream source and protocol changes;
- update
PATCH_VERSIONonly for a Starry feature/fix release; - re-run the overlay against the exact candidate source;
- update both release-note languages, changelog, image examples, and upgrade notes;
- verify all published examples and relative links;
- review generated Release/GHCR descriptions; and
- obtain explicit publication approval after the final documentation diff is reviewed.
This is an unofficial community project and is not affiliated with RustDesk, MaxMind, any MMDB provider, or any AI service provider. MMDB files are not included. Operators must select lawful data sources and follow their licences. Parts of the code and documentation were generated or revised with AI assistance; they receive no separate warranty and remain under the repository's licensing terms.
- 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 规则:进阶
- 运维与完整验证
- 常见问题排查
- 版本升级与回滚
- 架构与构建