rusty-psn: pulling console game updates from Sony's update API

Updates, not game content

rusty-psn is described as a simple tool to grab updates for PS3, PS4 and PS Vita games directly from Sony's servers, using their updates API. It is available for both Linux and Windows, in both GUI and CLI alternatives.

The scope is the update service, and that distinction matters for reading everything else. A patch file is what Sony's update service serves to a console that owns the game, and the project is a client for that service rather than a way to obtain software the store does not already offer. Nothing in the README describes downloading game content, installing titles or bypassing anything on a console, and the tool's own name and structure are consistent with that framing.

The value proposition is automation and reach. A console will download its own updates, but slowly, on a schedule it chooses, one title at a time, with progress shown on a television. A tool like this can fetch the same updates on a schedule, keep a local copy, and work across three console families with one command.

The default branch is `dev`, which tells you something about the workflow: this is a project where the released binaries are cut from a development branch rather than from a long-lived stable trunk.

Two front ends over one core

The Cargo.toml shows the split clearly in its feature flags:

[features]
default = ["egui"]
cli = ["clap", "dialoguer", "indicatif", "clearscreen"]
egui = ["rfd", "eframe", "egui-notify", "notify-rust"]

The `egui` feature is the default and brings in `eframe` 0.32.1 with the `persistence` feature, `rfd` for native file dialogs, and the two notification crates `egui-notify` and `notify-rust`. The `cli` feature brings in `clap` 4.5.43 with the derive feature, `dialoguer` for interactive prompts, `indicatif` for progress bars, and `clearscreen`.

That is a sensible split for a tool that has to run in two very different places. The GUI needs a windowing stack and a notification system; the CLI needs argument parsing, prompts, and progress output. The `persistence` feature on eframe means the desktop application remembers its state between runs, which is why the GUI has settings at all rather than being a single-purpose window.

The `indicatif` and `dialoguer` combination is the detail that matters for scripting. A progress bar writes to a terminal, and for a download tool running unattended that is either noise or, depending on the invocation, the only signal you get that work is happening. A tool that downloads several gigabytes over a residential connection needs to say so.

Both front ends are shipped as separate binaries, so the release assets are six zips, GUI and CLI for Windows, Linux and macOS universal.

The dependency list is the protocol

Reading the Cargo.toml tells you how the update API is actually spoken to, and it is a more informative list than the README's feature description.

The HTTP layer is `reqwest` 0.13.5 with `default-features = false` and the `rustls` feature, so there is no OpenSSL dependency in the tree and TLS is handled by rustls. On top of that sit `hmac` 0.12.1 and `sha2` 0.10.9 for the request signing, `sha1_smol` 1.0.1 for the older digest the update service uses, and `hex` 0.4.3 to encode the resulting bytes.

The response side is `quick-xml` 0.38.1 and `serde_json` 1.0.142. Both formats are needed because Sony's update service returns manifest documents in XML while the metadata around them comes back as JSON.

The rest of the list is ordinary application plumbing. `tokio` with the `rt`, `io-util`, `macros` and `fs` features is the async runtime, and `poll-promise` bridges the callback style of the platform APIs into it. `dirs` 7.0.0 finds the standard cache and config locations. `bytesize` 2.0.1 formats sizes for display, `copypasta` puts text on the clipboard, and `sanitise-file-name` 1.0.0 makes downloaded filenames safe on the filesystems the tool might meet.

The `serde` dependency is present with `derive` and `default-features = false`, and `log` with `flexi_logger` handle logging.

Putting it together: this is a tool that signs HTTP requests, verifies digests of what it downloads, parses XML manifests and JSON metadata, and writes files with sanitised names into a cache directory. Every one of those steps is in the dependency list, which means the important behaviour is in the crates rather than in the README.

Installing the binaries and the Linux GUI dependencies

The install path is a zip from the releases page. You go to the latest release and pick from the Assets section: `rusty-psn-egui-windows.zip`, `rusty-psn-egui-linux.zip` or `rusty-psn-egui-macos-universal.zip` for the GUI, and `rusty-psn-cli-windows.zip`, `rusty-psn-cli-linux.zip` or `rusty-psn-cli-macos-universal.zip` for the command line version.

After downloading, you extract it and run the executable. For the macOS egui builds the README recommends moving the extracted bundle into the Applications folder, which is the usual way to register a macOS application bundle.

The Linux GUI builds need system libraries, and the README gives the lists. On Ubuntu:

sudo apt-get install libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev \
libspeechd-dev libxkbcommon-dev libssl-dev

On Fedora:

dnf install clang clang-devel clang-tools-extra speech-dispatcher-devel \
libxkbcommon-devel pkg-config openssl-devel libxcb-devel

And the Arch Linux entry carries its own caveat in the README, which reads as an admission: Arch Linux (guesswork from looking at Ubuntu's package, my terminal history doesn't go that far). The command it gives is `sudo pacman -S libxcb libxkbcommon`.

That comment is worth taking at face value. The xcb packages are the X11 client libraries egui draws with, and `libspeechd-dev` is the speech-dispatcher development package, which is there because the tool speaks the game name aloud as part of the update flow. The Fedora list also pulls in clang, which suggests the egui backend needs a C toolchain present.

The CLI builds do not need these, because they do not open a window.

The Docker image ships the released CLI, not a source build

There is a supplied Dockerfile for running the CLI on Linux or macOS, and the build and run commands are:

docker build . -t rusty-psn
docker run --rm -v ${PWD}/pkgs:/rusty-psn/pkgs rusty-psn

The volume mount is the point. It maps a host directory to `/rusty-psn/pkgs` inside the container, which is where the downloaded packages land. Without that mount the downloads disappear when the container exits, since the tool runs with `--rm`.

The Dockerfile itself shows an approach that is unusual and worth noting:

FROM amd64/ubuntu:jammy
WORKDIR /rusty-psn

RUN apt-get update && \
    apt-get install -y curl openssl unzip

RUN curl -sL https://github.com/RainbowCookie32/rusty-psn/releases/latest/download/rusty-psn-cli-linux.zip -o rusty-psn-cli-linux.zip && \
    unzip rusty-psn-cli-linux.zip && \
    rm rusty-psn-cli-linux.zip && \
    chmod +x rusty-psn

ENTRYPOINT [ "/rusty-psn/rusty-psn" ]

The image does not compile the project. It downloads the released CLI zip from the latest release at image build time, unpacks it and makes it the entrypoint. So the container is a packaging convenience rather than a reproducible build, and the version you get is whatever the latest release was when the image was built.

The base image is explicitly `amd64/ubuntu:jammy`, so the image is x86-64 only. On an ARM machine you would need to build for that platform yourself. The `curl`, `openssl` and `unzip` packages are the only things installed beyond the base, which keeps the image small, and there is no build toolchain because nothing is compiled.

Edition 2018 and a version that moves quickly

One line in the Cargo.toml is worth a second look: `edition = "2018"`. The crate is otherwise built on current dependencies, with reqwest 0.13.5, tokio 1.47.1, clap 4.5.43 and eframe 0.32.1, so the edition declaration is likely about compatibility with the toolchains the project intends to support rather than about the code style.

The version is 0.7.1 and the release history shows how fast this is moving: v0.6.0 on 2026-08-03, then v0.7.0 on 2026-10-19 and v0.7.1 on 2026-10-20, with the last push on the same day as the newer tag. Two releases inside two days, after a two month gap.

That pattern tells you the project is responding to something on Sony's side, since the update API is the moving target and a change there breaks clients. The cost of that is on the adopter: a 0.x crate with releases this close together is not something you pin once and forget, and the semantics of a minor bump can change what the tool does with a particular title.

The repository layout is small and conventional for a Rust binary: `src/`, `Cargo.toml`, `Cargo.lock`, a `Dockerfile`, a `resources/` directory, a `.rustfmt.toml`, and a `.github/` directory. A committed `Cargo.lock` alongside a binary crate is the right call, since the lock file is what makes a release reproducible.

There is also no configuration file described anywhere in the README. Everything the tool needs comes from the update API, and the only inputs are the console identity details you supply.

MIT terms and what the project does not promise

The licence field on the repository says MIT, and there is a LICENSE file at the top level. MIT is the permissive end of the spectrum and imposes no obligation on anyone who uses this tool, which is the expected choice for a client for a public API.

What the project does not promise is worth stating as clearly as what it does. There is no mention in the README of a GUI feature list beyond the screenshots, no description of the CLI commands or flags, and no documentation of how the tool authenticates or what it does when the API returns an error for a title. The README is a download and run guide with screenshots, which is a reasonable thing for a small utility but a thin thing for a tool that talks to a proprietary service.

That thinness is also the honest limit on any recommendation. You cannot tell from the documentation whether the tool handles a revoked entitlement, a suspended account, or a region-locked title, because those cases are not described. Anyone planning to run this in a scheduled job should try it interactively first and watch what happens with a title the console does not own, rather than assuming the behaviour.

On maintenance, the picture is good in the ways that matter for a tool built on top of somebody else's service. The last push was on 2026-10-20, the current tag v0.7.1 was published the same day, and the project is versioned and released rather than distributed as a loose script. A CHANGELOG or release notes for each tag would make the rapid cadence easier to follow, and the README does not point at one.

For a tool this specific, the summary is simple: it does one job, it does it with a small Rust dependency tree and no native TLS stack, and it is being updated at the pace the service it talks to demands.

Editorial conclusion

Adopt rusty-psn if you maintain consoles and want a scriptable way to fetch game updates from Sony's update API instead of relying on each console's built-in download flow, and you are comfortable with the signing and entitlement model that API imposes. Skip it if you need anything beyond updates, since the project is scoped to the update service, or if you need a Linux distribution package, since the documented install is a zip from the releases page. Verify first which release you are running, since v0.7.0 and v0.7.1 landed within a day of each other, and confirm the Docker route works on your architecture, because the supplied Dockerfile is built `FROM amd64/ubuntu:jammy`. The licence field on the repository says MIT, and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. RainbowCookie32/rusty-psn on GitHub
4. README
5. Releases