newTrackon watches public BitTorrent trackers for uptime

A fork of an abandoned tracker monitor

newTrackon watches the status and health of open and public BitTorrent trackers, and it also lets anyone submit new trackers to be added to the list. The project is a fork of Trackon, which the README describes as abandoned, by Uriel. That lineage explains both the shape of the code and the narrow purpose. This is not a general purpose tracker and not a client for downloading anything. It is a monitoring service for the tracker infrastructure itself, of the kind that torrent clients draw from and torrent operators care about the uptime of. The audience is therefore two groups. The first is anyone running a public tracker who wants to know when it stops answering. The second is anyone who depends on a set of public trackers and wants a live view of which of them are currently usable, with the option to contribute new ones to the list.

The startup check demands both IPv4 and IPv6

This is the first thing that will stop you, and it is easy to miss. By default newTrackon needs IPv4 and IPv6 internet connectivity, and the application will not start without both. The two arguments that get you past it are --ignore-ipv6 and --ignore-ipv4, each of which skips the corresponding detection check. The full argument list is short, run.py takes an optional --address and --port for the Flask server plus those two ignore flags, and nothing else. The reason for the check is easy to infer from what the service does. Trackers are announced over both address families, and a monitor that can only reach one of them will report half the network as down, which is worse than not reporting at all. The cost of that design is a deployment detail. A VPS with a single IPv4 address, a container network without IPv6, or a laptop on a network that has no IPv6 route will all hit the same wall, and the fix is a flag, but the default behaviour is to refuse to run rather than to warn.

Running the container in one command

The Docker path is the shortest route to a running service, and the image is published under the corralpeltzer/newtrackon name.

docker run -d -p 8080:8080 corralpeltzer/newtrackon --address=0.0.0.0

After that the main page is at http://localhost:8080 in your browser. The compose file in the repository does the same thing with a named volume for the data directory, so tracker state survives a container replacement.

services:
  newtrackon:
    container_name: newtrackon
    ports:
      - 8080:8080
    volumes:
      - newtrackon_data:/app/newTrackon/data
    image: corralpeltzer/newtrackon:latest

The Dockerfile behind the image is short and shows the shape of the deployment. It starts from python:3.14-alpine, copies the source to /app/newTrackon, installs curl with apk and the Python dependencies with pip, then creates a dedicated system user named newtrackon, chowns the data directory to it and switches to it with USER. The data path is declared as a VOLUME, and the service listens on 8080 with an ENTRYPOINT of python run.py. The result is a container that runs as an unprivileged user with no shell script in the entry path, which is the right shape for something that will be exposed to the internet.

Installing with pip or uv and running run.py

The Python route is documented just as plainly. You clone the repository, make sure you have a working Python environment, install the dependencies, and start the entry script.

pip install .

or with uv, which syncs the locked environment from the uv.lock file in the repository root.

uv sync

Then the service starts with the same script the container runs.

python3 run.py

The main page is at http://localhost:8080 either way. There is a version wrinkle here that the documentation leaves slightly unclear. The README asks for a working Python 3.13 environment, while the packaging metadata in pyproject.toml declares requires-python as ==3.14.*, and the container image is built on python:3.14-alpine. The package metadata is the binding constraint for an install, so a 3.13 interpreter will not satisfy it, and the discrepancy is most likely a stale line in the README. Check which interpreter you have before you spend time on a failed install.

The Makefile runs four linters before the test suite

The repository carries a Makefile that shows how the project is checked, and it is worth reading because the toolchain is unusually broad for a small service. The default goal is check, which creates a virtual environment through uv if one does not exist and then runs ruff check, ruff format, basedpyright, ty check and djlint over the Jinja templates in newtrackon/tpl/. The template linter is run with --reformat, so the check target rewrites your templates rather than only reporting on them. The test target runs pytest over the tests directory with coverage measured against the newtrackon package, using --cov-report=term-missing so uncovered lines are named. The dev dependency group in pyproject.toml matches that list and adds freezegun for time control in tests and pytest-cov. Ruff itself is configured with a line length of 130, fix enabled and unsafe fixes enabled, and an extended rule selection covering pyupgrade, quote style, logging format, error handling and ruff specific rules. The project also carries a renovate.json5 for dependency updates, so the pinned versions in the metadata move on a schedule.

Tracker data lives in a directory, not in a database

The repository layout makes the persistence model plain. There is a data directory at the top level, the application package sits in newtrackon/, templates are in newtrackon/tpl/, utility scripts are in utils/, and the tests are in tests/. The compose file mounts a named volume at /app/newTrackon/data, which is the same path the Dockerfile declares as a VOLUME, and the setuptools configuration in pyproject.toml excludes data* from package discovery, so the data directory is not shipped inside the Python package. That is a small but meaningful design decision. The tracker list and the state the monitor keeps about it live on disk in a directory you can mount, back up and inspect with ordinary file tools, and there is no database service to run, no schema to migrate and no connection string to protect. It also means the list of monitored trackers is data rather than configuration, which is what allows the submission feature to exist at all, since a submitted tracker has to be written somewhere that survives a restart. The trade-off is that a large tracker set means a large directory of files, and there is no documented indexing scheme.

A project with commits but no releases

The maintenance picture is mixed and the mix matters. The repository is not archived, and the last push was on 2026-09-23, so the code is being worked on. But there are no GitHub releases, and the version in the packaging metadata reads 1.0.0, so there is no tag to pin against and no changelog of published versions to read. There is a TODO.txt in the root, which is a sign of an active, informal project rather than a finished one. The licence is MIT, with the licence text in a LICENSE.txt file, and the maintainer invites pull requests and issue reports and gives a contact address. The README also names two related projects worth knowing about if you use trackers this way, electromagnet, a Chrome extension that adds stable trackers to magnet links as you browse, and transmission-trackers, a small Python app and Docker image that runs alongside transmission to update the trackers on your public torrents. Neither is a dependency of newTrackon, but they show the two ways people maintain a tracker list, by browser extension and by client side hook, and newTrackon is the one that tells you whether the trackers are alive.

Editorial conclusion

Adopt newTrackon if you run a public tracker list or need uptime data on the open trackers you already use, and you can give the container both an IPv4 and an IPv6 address or pass the ignore flags. Skip it if your network is IPv4 only, since the default start-up check will refuse to launch until you add --ignore-ipv6, and skip it if you need a released artifact, because the repository publishes no GitHub releases. Before deploying, decide whether the tracker list ships with the image or is loaded from the data/ directory, confirm the Python version your environment provides, because the packaging metadata requires 3.14 while the README asks for 3.13, and read the MIT licence in LICENSE.txt before you expose the submission endpoint publicly.

Frequently asked questions

Official sources

1. CorralPeltzer/newTrackon on GitHub
2. Issues
3. License: MIT
4. Project website
5. README