IYUUPlus reseeds a private tracker library by talking to your downloader

The seeding library, without the manual copy and paste

IYUUPlus is built around a problem that private tracker users know well. You seed a release on one site, and the same release may exist on other sites under a different torrent file. Copying the info hash from one client to another by hand, site by site, is tedious enough that most people simply do not do it, and the ratio they would otherwise earn goes unclaimed.

The project describes itself as an automatic reseeding tool for most domestic private tracker sites, and the features it lists around that core are the ones that scale the practice up: downloader clustering, multiple disk slots, multiple download directories, and connecting to remote downloaders. Those four are what turn a manual chore into something a server can run.

The application itself is broader than the reseeding script. It runs in PHP-CLI mode with a resident process, and the README lists the web interface, reseeding, transfer, downloading, scheduled URL visits and dynamic domain name updates as the integrated functions, plus a plugin mechanism. The client is fully open source and described as transparent in behaviour, with the source available to customise.

The audience is specific. This is a tool for someone running a long-lived seeding box, and the documentation site at doc.iyuu.cn is where the operating details live.

The reseed loop touches your client, not the tracker

The mechanism is described precisely enough to be worth walking through, because the detail matters for how much trust the design asks of you.

IYUUAutoReseed is a private tracker reseeding script written in PHP. It runs either on a schedule or as a resident process, and at a set frequency it calls the API of the transmission or qBittorrent client. It extracts the info hashes of the torrents currently being seeded, and submits them to the reseeding server API. The data returned from that API is used to assemble torrent links, which are then submitted back to the downloader. The downloader itself goes to the site, downloads the torrent, verifies it and seeds it.

Two properties follow from that flow. The first is that the script does not interact with the tracker servers at all during reseeding. The README states this as a safety argument: the script only pushes torrent links to the downloader, and the downloader does the talking to the site. It goes further and says that in theory no site and no technology can detect that IYUUAutoReseed was used.

The second property is the one that requires trust. The tool is not self-contained. The information about which torrent corresponds to which release lives in a server API, and that service is not part of this repository. The client is open source; the knowledge base it consults is not.

PHP 8.3 with a long list of mandatory extensions

The runtime requirement is stated bluntly: a minimum PHP version of v8.3.0, with the latest stable release recommended. The list of extensions that must be enabled is given as configuration, and it is longer than most people expect:

extension=curl
extension=fileinfo
extension=gd
extension=mbstring
extension=exif
extension=mysqli
extension=openssl
extension=pdo_mysql
extension=pdo_sqlite
extension=sockets
extension=sodium
extension=sqlite3
extension=zip

The extensions tell you what the application does. GD and exif point at image handling and metadata, mbstring at multibyte text, zip at archive extraction, sodium and openssl at cryptography, sockets at the outbound connections to the downloader and the service, and both pdo_mysql and pdo_sqlite at the database layer, which is why the configuration carries a flag for running without MySQL.

The stack behind those extensions is pinned in a table. Workerman 5.1.3 provides the long-running process, Webman 1.6.14 is the application framework on top of it, and WebmanAdmin 0.6.30 supplies the admin interface. The listed PHP version is 8.3.24 and MySQL 5.7.26, with Layui 2.8.12 and Vue 3.4.21 for the interface layer.

The repository layout matches that stack and shows the extension points. There is an app directory, a plugin directory, a process directory for the resident worker, a config directory, a database directory with phinx.php for migrations, a docker directory, a public directory for the web root, and a runtime directory. A vendor directory is committed, and start.php, boot.php and bootstrap.php are the usual Webman entry points. There are also windows.bat and windows.php files and a gg.sh shell script, so the same application is expected to run on Windows as well as on a Unix host.

The .env file is the whole configuration contract

Configuration lives in a .env file, and the repository ships .env.example as the template. It is short enough to read in one go, and every key tells you something about a decision the installer has to make:

APP_DEBUG=false
APP_ENV=prod

DB_CONNECTION=mysql
DB_HOST={{DB_HOST}}
DB_PORT={{DB_PORT}}
DB_DATABASE={{DB_DATABASE}}
DB_USERNAME={{DB_USERNAME}}
DB_PASSWORD={{DB_PASSWORD}}

The service credentials and switches come next in the same file:

CONFIG_NOT_MYSQL=0
IYUU_LISTEN_IPV6=0
IYUU_TOKEN={{IYUU_TOKEN}}
IYUU_APPID={{IYUU_APPID}}
IYUU_SECRET={{IYUU_SECRET}}
CLOUD_ACCESS_TOKEN=
CLOUD_SN=
CLOUD_DEBUG=0

The three placeholders in double braces for the service credentials, IYUU_TOKEN, IYUU_APPID and IYUU_SECRET, are what tie the installation to the reseeding service, and the file has to be filled in before the application can do its main job. CLOUD_ACCESS_TOKEN and CLOUD_SN are the optional cloud channel, and CLOUD_DEBUG switches on its diagnostics.

Two switches deserve attention. CONFIG_NOT_MYSQL set to 0 means MySQL is in use, and the presence of pdo_sqlite in the extension list suggests the alternative is available. IYUU_LISTEN_IPV6 set to 0 means the listener is IPv4 only, which matters if you intend to reach the web interface over a network that is IPv6, and the nginx configuration later in the README does not mention IPv6 at all.

Because this file holds a token, a secret and a database password, the deployment should keep it out of version control and readable only by the service account. The repository includes a .gitignore, and the .env.example file uses placeholders rather than real values, which is the right starting point.

Behind nginx, the web interface and the websocket port

The README includes a ready nginx reverse proxy configuration, and reading it tells you how the application is shaped for the network. Two locations are defined. The first proxies the whole site to a local port:

location ^~ / {
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_http_version 1.1;
  proxy_set_header Connection "";
  if (!-f $request_filename){
    proxy_pass http://127.0.0.1:8787;
  }
}

The second is a specific path proxied to a different port with websocket upgrade headers:

location /app/d9422b72cffad23098ad301eea0f8419
{
  proxy_pass http://127.0.0.1:3131;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "Upgrade";
  proxy_set_header X-Real-IP $remote_addr;
}

The path is an opaque hash, which is the project's way of keeping the live update channel off the main port and behind a hard-to-guess route. The websocket headers on that route mean the interface expects a persistent connection, which fits a process that reports downloader status.

The first block's if statement checks whether the requested file exists before proxying, so static assets under the public directory are served by nginx directly and only dynamic requests reach the application on port 8787. A deployment that skips this and proxies everything to 8787 still works but gives up the static file handling.

The README also points at the interface development documentation at doc.iyuu.cn and invites other developers to build on the API, mentioning mobile apps, binary packages, a Windows GUI and browser extensions as examples of what the interface allows.

The disclaimer tells you exactly where the risk sits

The repository carries a disclaimer that is more specific than most open source projects manage, and it is worth reading as a technical document rather than as boilerplate.

It states that using IYUUAutoReseed or IYUUPlus is itself very safe, that the script does not produce any interaction with the tracker servers during reseeding, and that it only pushes torrent links to the downloader, which then fetches them from the site. The claim that follows is that in theory no site and no technology can detect that you used the tool.

Then the risks are enumerated, and none of them is about the tool. The first is that you should not skip verification by hand, because a ban from that is unrelated to IYUU. The second is that official first-release resources, and any other first-release resource, cannot be reseeded before the release goes out, so a ban for cheating on your own part is also unrelated to IYUU. The third is that losses caused by using the tools are not the responsibility of IYUU, and readers who do not accept the terms should delete the downloaded source.

Read as an engineer, the disclaimer is saying three concrete things. The tool does not touch tracker authentication, so it cannot be the thing that trips a site rule. It does not help with the case where being early is the problem. And the downloader still talks to the site directly, which means the account's behaviour is what the account is judged on.

One limitation is not in the disclaimer. The supported downloaders are listed as exactly two, transmission and qBittorrent, so a client outside that list is simply not covered.

MIT licensed, tagged on two hosts, and actively developed

The licence field on the repository says MIT, with a LICENSE file at the root, so the code can be read, modified and redistributed with only a notice attached. Since the application runs on your own hardware and talks to your own downloader, there is no service to sign up for.

The project is not archived and the last push was on 2026-08-26, so the code is being worked on. Releases are published as tags on two hosts rather than as GitHub releases, with a domestic mirror on Gitee at gitee.com/ledc/iyuuplus-dev/tags and the international one on GitHub at github.com/ledccn/iyuuplus-dev/tags. The repository also carries a .version file, which is how the application knows which build it is.

The default branch is master. A docker directory and a .dockerignore are present, so a container deployment is a supported path, and the documentation site is the primary interface for setup.

The README also lists the ways to get in touch: several QQ groups of a thousand to two thousand members, the issue tracker, and a blog. Two contributors are credited by name, hxsf and DDS-Derek.

For a tool in this category, the sensible first step is not to deploy it against your real account. The repository ships an example configuration and a docker setup, and the documentation site describes the setup in full, and starting from a test setup on a machine with a small seeding library is a better way to learn the configuration keys than reading them on a production box.

Editorial conclusion

IYUUPlus suits a private tracker user with a large seeding library who wants reseeding handled automatically and can run a PHP service alongside a downloader, either on a NAS or a small server. It is the wrong tool for someone with a handful of torrents, for a client other than transmission or qBittorrent, and for anyone unwilling to accept that the seeding service is a third party the code depends on. Before you deploy it, read the disclaimer in the repository in full, because the project is explicit that account bans come from skipping verification or from first-release resources rather than from the tool, fill in the IYUU_TOKEN, IYUU_APPID and IYUU_SECRET values in the .env file, and check the version tags on Gitee or GitHub, since the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. ledccn/iyuuplus-dev on GitHub
3. License: MIT
4. Project website
5. README