AlistHelper: a Flutter tray app that starts and stops alist and openlist for you

What AlistHelper does that the alist binary does not

alist and openlist are server programs. You download a binary, run it, and it listens; starting it at boot, keeping it in the tray and changing its launch flags are all things you arrange yourself. AlistHelper is a Flutter desktop application whose stated purpose is to simplify that: it manages alist or openlist, letting you start and stop the program from a GUI. The README lists automatic launching, minimizing to the system tray, automatic startup on boot with an optional silent startup mode, quick access to version and administrator information, and adjustable startup parameters. It also supports rclone management, which the README describes as mounting alist or openlist as a hard drive.

The README's own comparison table puts alist, alisthelper and a paid alist desktop side by side. Against the plain alist binary it claims boot startup, silent startup, accompanied startup, a GUI, a system tray, startup parameters and HTTP proxy as features alist does not have out of the box. Against the paid option, the difference it draws is startup parameters and HTTP proxy, which the table marks as unsupported there. That table is the project's own marketing, not a benchmark, but it does state clearly where the author thinks the value sits: not in serving files, but in the process around the server.

The architecture: a Flutter shell around a binary you supply

The repository layout is a standard Flutter desktop project: lib/ for Dart source, macos/, windows/ and linux/ platform folders, assets/, and pubspec.yaml with build.yaml for code generation. The README says the app is developed using Flutter, and the primary language is Dart. The i18n directory, lib/i18n, holds strings_<locale>.i18n.json files plus _missing_translations_<locale>.json files, and translations are regenerated with build_runner. That tells you the UI text is generated code, not hand-written constants, which matters if you plan to patch a string.

The important architectural fact is negative: this program does not include the binary files for alist. The README states that plainly, and it is the single constraint that shapes everything else. AlistHelper is a supervisor and a settings surface. It launches an executable that you obtained elsewhere, passes it startup parameters, and reflects its state back to you. Nothing in the repository description suggests it downloads, verifies or updates that executable for you. If your alist binary is missing or in the wrong place, the GUI has nothing to control.

rclone support follows the same pattern. AlistHelper manages rclone, and the mounting feature depends on rclone being available; the README does not describe bundling it either.

Installing AlistHelper and starting alist for the first time

There are two paths. End users take a build from the releases page, which the README links through its download badge. The project publishes Windows and macOS builds; the README says it is currently available on Windows and macOS, and that you can build it for Linux but with no official support yet.

If you prefer to build it yourself, the README's run instructions assume Flutter is already installed. Fork the repository, then from the project root run the three commands it gives. The first fetches Dart dependencies, the second runs the code generator that produces the i18n and other generated sources, and the third launches the app:

flutter pub get
dart run build_runner build
flutter run

Before any of that is useful, place an alist or openlist binary on the machine, since AlistHelper does not ship one. Then open the app and use its start control to launch the program, and its stop control to shut it down. The README describes exactly this pair of actions as the core of the app. From the settings surface you can edit the startup parameters before launching, which is how you pass the flags your alist deployment needs, and you can enable startup on boot, optionally silently. The README also mentions quick access to version and administrator information, which is where you read back the initial admin credentials alist prints on first run.

The README does not document the exact parameter syntax, the location where AlistHelper expects the binary, or a step-by-step first-run walkthrough in English. It points to a wiki, and that wiki is in Simplified Chinese. Budget time for that if you do not read Chinese.

Where AlistHelper is the wrong tool

The clearest limitation is stated by the project itself: no official Linux support. The linux/ directory exists and the README says you can build for Linux, but that is a build target, not a supported product. If your alist instance lives on a headless Linux server, this application is aimed at a different situation entirely, and the tray and boot-startup features it is built around make little sense there.

The second limitation is the missing binary. Anyone expecting a single download that yields a running file server will be disappointed. You assemble two pieces: the server, from its own release channel, and this GUI. That also means version drift between the two is your problem. The README does not describe how AlistHelper detects, updates or validates the alist binary it launches, so if alist changes its command-line interface, the startup parameters field is where you will notice.

Third, release cadence. The most recent release is tagged beta, dated 2026-03-13, while the last numbered release, v0.2.0, is dated 2024-12-22, and v0.1.5 before that in 2024-03. A beta tag on the newest artifact is a signal to read the release notes rather than assume stability. The repository is not archived and the last push was on 2026-03-13, so it is not abandoned, but the gap between numbered releases is long enough that you should treat the beta channel as the live one.

Finally, the documentation is thin in English. The README covers features and contribution rules well and operational detail poorly. The wiki is the place the project sends you, and it is in Simplified Chinese.

AlistHelper against running the alist binary directly

The honest alternative is not another GUI. It is a service manager you already have: a systemd unit on Linux, a launchd plist on macOS, or Task Scheduler on Windows, each pointed at the alist binary with your flags. That approach gives you boot startup and restart-on-failure with no extra dependency, and it is the thing the README's comparison table means when it says plain alist needs manual configuration for startup at boot, silent startup and HTTP proxy. The difference is not capability so much as who writes the configuration. A service manager asks you to write it once in a text file; AlistHelper asks you to click through a GUI and stores the equivalent for you, and adds a tray icon and a way to read back version and admin information.

If your reason for wanting a GUI is mounting rather than supervising, the relevant comparison is rclone on its own. AlistHelper manages rclone, but rclone is a complete command-line tool with its own mount subcommand, and the README's mounting feature is a front end for it. Running rclone directly is more work and more transparent. AlistHelper's value there is convenience, not capability.

The paid alist desktop application appears in the README's table as the other GUI option, at 8 dollars or 50 yuan, with boot startup and silent startup but without startup parameters or HTTP proxy. If you need to pass custom flags or route through a proxy, that is the concrete line the author draws between the two.

Licence, maintenance and what an upgrade actually costs

AlistHelper is GPL-3.0. That is a copyleft licence, and it governs the application code in this repository. It does not govern the alist or openlist binary you supply, which carries its own licence from its own project. If you redistribute a build of AlistHelper, or ship a modified one, the GPL-3.0 obligations attach to that build. This is a description of the licence identifier in the repository, not legal advice; read the LICENSE file and get proper counsel if redistribution is on your roadmap.

Upgrade cost splits in two. Upgrading AlistHelper itself is a download, or a rebuild if you compiled it. Upgrading alist or openlist is entirely separate and outside this application's documented scope, because the README says the binaries are not included. The repository gives no migration notes for either side, and the README does not document rollback. Keep the previous binary and the previous AlistHelper build until you have confirmed the pair works.

Contributing has its own cost, and the README is specific about it. Code should follow the Dart Style Guide, all changes should be covered by tests, and pull requests target the master branch. Translation work is routed through lib/i18n, either by filling in _missing_translations_<locale>.json for an existing language or editing strings_<locale>.i18n.json, followed by dart run build_runner build. The README warns that fields decorated with @ are not meant to be translated. That is a more concrete contribution path than most small projects offer, and it is the cheapest way to improve the English experience if the Chinese-only wiki is your blocker.

Editorial conclusion

AlistHelper fits people who already run alist or openlist on a Windows or macOS desktop and want tray control, boot startup and editable launch parameters without writing a service unit by hand. Skip it if you need official Linux support, a bundled binary, or a documented upgrade path: the README points to a Simplified Chinese wiki, the latest release is tagged beta, and the repository does not describe how it updates the alist binary it launches. Before adopting it, verify that you can download the alist or openlist binary separately, that the startup parameters field accepts the flags your deployment needs, and that rclone is present if you intend to mount anything.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Xmarmalade/alisthelper on GitHub