SyncTV is an open-source, MIT-licensed Rust platform for real-time synchronized video watching, combining media provider integration, livestreaming, HTTP and gRPC APIs, and Kubernetes-ready horizontal scaling for self-hosters, operators, and developers who run their own viewing rooms.

What it is

SyncTV is a Rust implementation of a real-time synchronized video watching platform, built on the Tokio runtime with Axum for HTTP and gRPC for APIs. It stores durable state in PostgreSQL, optionally uses Redis for shared state, cache, rate limiting, and cluster coordination, and exposes HTTP REST, public gRPC, WebSocket, management gRPC, metrics, RTMP, and STUN runtime surfaces. The codebase is MIT-licensed, with 2,489 stars, 244 forks, and 21 open issues on GitHub. Documentation is served from an Astro Starlight site at docs.syncs.tv in English and Simplified Chinese, and a native client is distributed through SyncTV App releases and supported app stores.

The problem it solves is fragmentation. Watching something together across separate media providers, a livestreaming relay, and room-state synchronization normally means stitching together several unrelated tools. SyncTV replaces that combination with one service that holds room playback state, pulls or accepts the media stream, and serves it back to every participant at once. It also covers cross-node live relay, so a room can continue to work when the operator runs more than one instance and the publisher connects to a different node than the viewer.

Key capabilities

• Synchronized room playback with real-time state updates across connected clients.
• Media providers for Bilibili, Twitch, YouTube, Douyin, TikTok, Huya, Douyu, AcFun, CCTV, Alist, Cloudreve, Emby/Jellyfin, FNOS, QNAP, Synology, Nextcloud, Seafile, TrueNAS, direct URLs, and livestream sources.
• WHIP and RTMP publishing with WHEP, HLS, and HTTP-FLV playback.
• External WHEP, RTSP, RTMP, and HTTP-FLV pull with cross-node live relay.
• Runtime surfaces for HTTP REST, public gRPC, WebSocket, management gRPC, metrics, RTMP, and STUN.
• PostgreSQL-backed durable storage with optional Redis for shared state, cache, rate limiting, and cluster coordination.
• Docker Compose and Helm deployment templates, a built-in management CLI, and optional OpenAPI/Swagger UI.

Who uses it and how

• Individual self-hosters who deploy a single node with the Docker Compose template and keep PostgreSQL as the only required backing service.
• Kubernetes operators who deploy the Helm chart and enable Redis to coordinate state, caching, and rate limiting across replicas.
• Teams that ingest live sources through WHIP or RTMP publishers and distribute playback through WHEP, HLS, or HTTP-FLV, including cross-node relay when viewers land on a different instance from the publisher.
• Households and small groups that already run Emby/Jellyfin, Nextcloud, Synology, QNAP, TrueNAS, Seafile, or Cloudreve and want those libraries played back inside shared rooms rather than copied elsewhere.
• Developers writing clients against the HTTP REST, public gRPC, and WebSocket surfaces, often alongside the native client from SyncTV App releases, with deployment and roadmap questions raised in the SyncTV Telegram discussion.

Getting started

The README points to the full documentation at docs.syncs.tv and ships Docker Compose and Helm deployment templates for running the service, with PostgreSQL required and Redis optional. The native client is available from the client downloads guide or SyncTV App releases, and store builds are distributed through the supported app stores.

How it compares

No comparable project is named in the facts, so SyncTV stands alone in this registry. The media sources it lists, such as Emby/Jellyfin, Nextcloud, Synology, and TrueNAS, are systems it plays from rather than alternatives to it, and no paid product list is provided for a licence, hosting, or cost comparison.

When to use it — and when not to

Running SyncTV means operating PostgreSQL, and adding Redis if shared state, cache, rate limiting, or cluster coordination across nodes is wanted, along with whatever network exposure the RTMP, STUN, public gRPC, and media relay surfaces require. Anyone unwilling to run a database and manage those inbound ports should not pick it, and operators should expect to configure access control around the public gRPC and streaming endpoints themselves. The README is brief and defers most operational detail to the documentation site, and with 21 open issues the project still carries unresolved reports that a prospective self-hoster should review first.