What I'm trying to do
Run ps5upload on a NAS (headless, no Windows/macOS desktop) and manage PS5 transfers from a browser.
The problem
The engine ships a built-in web UI at /, but it only exposes basic primitives — job status, raw Quick Transfer (manual path entry), and a few API endpoints. It's missing most of what makes the desktop app useful: the file browser, game library with cover art, package install flow, payload sender, hardware panel, and the general polish of the desktop UI.
So right now there's no good self-hosted story. You either run the desktop app (which requires Windows/macOS), or you run just the engine and get a very stripped-down experience.
Request
Would you consider building a full web frontend for the engine — something feature-equivalent to the Tauri desktop UI but running in the browser — and packaging it alongside the engine in a Docker image?
Something like:
docker run -p 19113:19113 \
-e PS5_ADDR=192.168.1.50:9113 \
-e PS5UPLOAD_ALLOW_IP=192.168.1.100 \
-v /mnt/nas/games:/nas \
ghcr.io/phantomptr/ps5upload:latest
Then http://NAS_IP:19113 opens the full app — game library, package install, file browser, payload sender — everything the desktop app does, in a browser.
Bonus: NAS app packaging
If a self-contained Docker image (or static binary + bundled web assets) exists, it becomes straightforward to package for NAS platforms. For example, fnOS (飞牛 OS, a Chinese NAS OS with ~900k installs) uses .fpk packages — an AI-assisted packaging pass on top of a working Docker image or binary would likely get it into their app center with minimal effort.
The Tauri frontend is already a web app under the hood — if the IPC calls can be replaced with direct engine HTTP calls, the same UI could run in any browser without Electron/Tauri.
No pressure — just flagging the demand in case it helps prioritize. Thanks for building this.
What I'm trying to do
Run ps5upload on a NAS (headless, no Windows/macOS desktop) and manage PS5 transfers from a browser.
The problem
The engine ships a built-in web UI at
/, but it only exposes basic primitives — job status, raw Quick Transfer (manual path entry), and a few API endpoints. It's missing most of what makes the desktop app useful: the file browser, game library with cover art, package install flow, payload sender, hardware panel, and the general polish of the desktop UI.So right now there's no good self-hosted story. You either run the desktop app (which requires Windows/macOS), or you run just the engine and get a very stripped-down experience.
Request
Would you consider building a full web frontend for the engine — something feature-equivalent to the Tauri desktop UI but running in the browser — and packaging it alongside the engine in a Docker image?
Something like:
Then
http://NAS_IP:19113opens the full app — game library, package install, file browser, payload sender — everything the desktop app does, in a browser.Bonus: NAS app packaging
If a self-contained Docker image (or static binary + bundled web assets) exists, it becomes straightforward to package for NAS platforms. For example, fnOS (飞牛 OS, a Chinese NAS OS with ~900k installs) uses
.fpkpackages — an AI-assisted packaging pass on top of a working Docker image or binary would likely get it into their app center with minimal effort.The Tauri frontend is already a web app under the hood — if the IPC calls can be replaced with direct engine HTTP calls, the same UI could run in any browser without Electron/Tauri.
No pressure — just flagging the demand in case it helps prioritize. Thanks for building this.