TrguiNG replaces transmission-remote-gui with a Tauri app and a servable web build

A rewrite of transmission-remote-gui on Tauri

TrguiNG is described as a rewrite of the transgui project, and the README links that upstream repository directly.

The stack is stated plainly. The frontend is written in TypeScript with React and the Mantine component library, and the backend for the app is written in Rust. The application framework is Tauri.

That combination is the interesting part. A remote GUI for a torrent daemon is a case where the web frontend was always the easy half and the packaging was the annoying half. Transmission's own RPC interface is HTTP and JSON, so a browser can talk to it, but a desktop client still wants a native window, a system tray, file dialogs and a binary the user can download and run. Tauri gives you a Rust process hosting the application with a web view, which is a different distribution story from Electron and a different size story as well.

The repository layout confirms the split. There is src for the frontend, src-tauri for the Rust side, src-svg for SVG assets, webpack.common.mjs with dev and prod variants, postcss and eslint configs, a ci directory and an update_version.sh script.

The licence is GNU Affero General Public License v3, with LICENSE.txt at the root. That is the licence to look at carefully if you plan to expose the web build to users of your daemon, because the AGPL's network use clause is what makes the web delivery mode meaningful.

Two ways to run it, and they are not the same program

The README says you can use the program in two ways: as a native Windows, Linux or Mac app, and as a web GUI served by Transmission itself by setting the TRANSMISSION_WEB_HOME environment variable to point to the TrguiNG web assets.

That second mode is the distinctive one. Transmission supports custom web interfaces, and the mechanism is a single environment variable pointing at a directory of static assets that the daemon will serve over its transmission/web/ endpoint. The whole deployment is: download the web archive from the releases page, unpack it somewhere the user running the daemon can read, and set the variable.

For Debian the README gives the concrete steps. Download the latest trguing-web-xxxx.zip from the releases page, unpack it anywhere and make sure the user transmission runs under, by default debian-transmission, has read permissions. Then edit the systemd unit file at /etc/systemd/system/multi-user.target.wants/transmission-daemon.service and add the environment line to the Service section.

Environment=TRANSMISSION_WEB_HOME=/path/to/extracted/trguing/zip

Then reload the unit file with sudo systemctl daemon-reload and restart the service with sudo systemctl restart transmission-daemon.

The web mode has a real consequence for anyone running Transmission behind a reverse proxy or on a shared host. Whatever the daemon serves at that endpoint is reachable by anyone who can reach the daemon, and the daemon's RPC is typically authenticated with a single username and password. Putting a rich web interface in front of that is convenient and it is also a much more valuable target than the daemon's built-in interface was.

Note also what the web mode does not give you, which the next section covers.

Multi-server tabs and torrent creation exist only in the native app

The feature list calls out its differentiators, and two of them are explicitly marked native app only.

The first is a multi tabbed interface for concurrent server connections. The second is torrent creation with fast multithreaded hashing. Both are marked native app only in the README's own list.

That is a coherent division. A tabbed multi-connection client is a desktop pattern, since a browser tab model already exists and each connection would need its own authentication state anyway. Torrent creation with multithreaded hashing is a native concern because the hashing is CPU intensive and benefits from access to every core, and because the result has to be written somewhere the user chooses.

So the web build is a better remote control, and the native build is a full management client. If your use case is watching a single remote seedbox, the web build covers it. If your use case is running several boxes at once and creating torrents locally, you need the desktop app.

The rest of the differentiators are shared: powerful torrent filtering options, support for the latest Transmission features including labels, bandwidth groups and sequential download, and a dark and white theme.

There is also a planned item that tells you about the upstream API's limits. Better bandwidth groups support is planned, pending an API being ready, and the README links the Transmission issue about it. Bandwidth groups exist in the daemon but the interface to them is not settled, which is why the feature is on the planned list rather than the shipped one.

Compiling needs Node, Rust and a geoip database

The build prerequisites are listed as Node.js 20 or later, rust 1.92 or later, and a Geoip lookup database in mmdb format that you put in src-tauri.

The database is fetched from the project's own releases.

wget -nv -O src-tauri/dbip.mmdb "https://github.com/openscopeproject/TrguiNG/releases/latest/download/dbip.mmdb"

The README also points at db-ip.com for the latest database, naming the ip-to-country-lite download.

The build itself is two commands.

$ npm install
$ npm run build

That produces an optimized bundle in dist and a release binary in the src-tauri/target/release folder, with the installer package in src-tauri/target/release/bundle.

The README is precise about what the binary contains. It is statically linked and embeds all necessary assets except for the geoip database, and it is completely self sufficient and can be used as a portable executable, but for geoip lookup to work you need to install the app with the provided installer.

That is an unusual split, and worth understanding before you distribute it. The country lookup data cannot be embedded because it is too large to bake into a binary, so it sits next to the app on disk. A portable copy of the executable will run, and it will not resolve peer countries, unless you install it properly so the database lands where the app looks for it.

For development, two commands run in parallel.

$ npm run webpack-serve
$ npm run tauri-dev

Webpack watches changes in src and refreshes the app view, and Tauri watches changes in src-tauri and rebuilds and restarts the app as needed. The package.json scripts back this up, with tauri-dev mapped to tauri dev, build to tauri build, build-bin to tauri build -b, and separate webpack serve, dev, prod and bundle analyzer scripts.

Weekly builds versus tagged releases

There are two distribution channels and they serve different purposes.

The releases page carries the tagged versions. The recent ones are v1.5.1 Sweeping the crew cabins from 2025-12-08, v1.5.0 Swapping the keel in open sea from 2025-10-26, and v1.4.0 Dropping the jib from 2024-10-09. The naming convention is nautical, which is a small thing but it makes a changelog easier to scan.

Separately, weekly builds of the current development version are available from the GitHub build workflows. The instruction is to pick the latest successful run and scroll down to the artifacts section.

That is worth understanding for a client that talks to a daemon. TrguiNG is a frontend for Transmission's RPC interface, and the daemon version determines which RPC features exist. The README states that Transmission v2.40 or later is required, and it separately notes support for the latest Transmission features such as labels, bandwidth groups and sequential download. A weekly build of the frontend paired with an older daemon is exactly the combination where a missing RPC method shows up as a broken button rather than an error message.

The practical pairing is to match the frontend build to the daemon version you actually run, and to read the changelog between releases before upgrading, since the frontend can start depending on a newer RPC method than your daemon provides.

The repository also has an update_version.sh script at the root and a ci directory, which is the release plumbing.

Where TrguiNG is the wrong tool

The first limitation is the version floor. Transmission v2.40 or later is required, and the README does not describe behaviour against older daemons. If you are pinned to an older Transmission, this client is simply not available to you.

The second is the feature split between the two delivery modes. Multi-server tabs and torrent creation with multithreaded hashing are native only, so a team that wants to administer several seedboxes from a browser will find that the web build does not do it.

The third is that this is a Transmission client, not a torrent client in general. It speaks the Transmission RPC interface, so it cannot manage rtorrent, qBittorrent, Deluge or anything else. For a user with one of each, the answer is one GUI per daemon, which is the reason the original transgui project existed and the reason several rewrites of it exist.

The fourth is the security surface of the web mode, which is worth repeating. The web assets are served by the daemon itself, so exposing the daemon to a network exposes the GUI as well, and the GUI is designed to start torrents and change server settings. Transmission's own interface is minimal by comparison. If the daemon sits behind a reverse proxy with authentication, the web build inherits that protection. If it does not, the web build is a much better target than the daemon's built-in page.

The fifth is the geoip database dependency, which is a runtime wart rather than a build one. The binary is self sufficient except for that file, so a portable copy of the executable runs but cannot resolve peer countries, and you need the provided installer to get the database in the right place.

How it compares with the original transmission-remote-gui

The original transgui project is the baseline, since TrguiNG is explicitly a rewrite of it rather than a fork in name only.

The difference in approach is the application framework. The original was built on GTK with Python, which meant shipping a Python runtime and GTK bindings and dealing with platform packaging. TrguiNG puts a Rust backend under a Tauri shell with a React and Mantine frontend, and the README describes the Rust side as the backend for the app.

That changes three practical things. The binary is statically linked and self sufficient, so distribution is a download rather than a dependency negotiation. The interface is built from React components with Mantine, so it looks and behaves like a modern web application rather than a desktop toolkit from the previous decade, which is why it has a dark and white theme rather than a fixed palette. And the frontend is a normal TypeScript web app, so it can also be built as static assets, which is what makes the TRANSMISSION_WEB_HOME mode possible at all.

That last point is the structural difference worth dwelling on. A GTK application cannot be served to a browser, because GTK is not a web technology. Once the client is a web application, running it inside a desktop shell and serving it over HTTP are the same artefact in two different hosts, and you get the web mode almost for free. The rewrite did not add a feature so much as unlock a deployment option.

The cost is that the native-only features exist because the native host can do things the browser cannot, and they were not ported to the web build. So the two modes are not equivalent, and the README is upfront about which is which.

Editorial conclusion

TrguiNG fits a Transmission user who wants a maintained desktop client with tabbed multi-server connections and torrent creation with fast multithreaded hashing, and it fits anyone whose Transmission daemon already serves a custom web interface and wants the same UI in a browser. It does not fit someone on Transmission older than 2.40, and it does not fit a multi-server administrator who expects the web build to carry the native features, since the multi-tabbed interface and torrent creation are marked as native app only. Before adopting, confirm your Transmission version, decide which of the two delivery modes you actually want because they do not have the same feature set, and check the releases page for the current build, since the latest tagged release is v1.5.1 from 2025-12-08 while weekly builds of the development version come from the build workflows.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. openscopeproject/TrguiNG on GitHub
4. README
5. Releases