Architecture

Architecture

Phone app or Decky panel → site API → launch plan and device queue
                                ↓
                          library HTTP API

Deck user service → poll and dispatch → stream runner or local install
                                            ↓
                              WebDAV → rclone VFS cache → umu / Proton

Layer	Role and boundary
Companion and queue	The web app and Decky panel expose the library and job status. The site authenticates queue requests and stores queue state in configured Redis. Steam store search supplies catalog metadata. Game files come from the user's storage. Queue · Store · Decky backend
Library and planning	The site's relay forwards a small set of library API operations. The planner uses the file list to distinguish a ready executable folder from installable archives or installers. Disc images and media are excluded by the documented contract. Storage API · Planner
Deck dispatch	The Python daemon runs as a user service. It polls jobs and dispatches the relevant launcher. Installable content takes the local installation path, which needs enough local disk space. Daemon · Install runner
Streamed execution	rclone mounts the selected game folder read-only with a local VFS cache. If available, fuse-overlayfs puts writes in a local layer. umu and Proton run the game on the Deck. Stream runner
Profiling and recovery	A startup profile tracks byte ranges so later launches can reuse measured demand. The daemon contains cache maintenance and post-session handling. Its resume hook waits for networking and checks stale mounts. Profile implementation · Resume hook
Save handling	The daemon has a Ludusavi integration. Save behavior depends on the title and detection path. Save integration

The phone and Decky panel are controllers. The actual game process and rendering run on the handheld. Remote storage serves bytes, so the launch depends on I/O latency, cache state, and the game's read pattern.