AriaNg: a browser frontend for aria2, and what it does not do

The gap AriaNg fills between aria2 and a browser

aria2 is a command line download utility with an RPC interface. It handles HTTP, FTP, BitTorrent and Metalink tasks, and it exposes control over JSON-RPC or XML-RPC. What it does not ship is a graphical task list. The README states the project's purpose in one line: AriaNg is a modern web frontend making aria2 easier to use. That sentence is the whole scope. AriaNg is the control surface, aria2 is the engine, and the two talk over the RPC interface rather than sharing a process.

The audience follows from that split. If you run aria2 on a NAS, a seedbox or a small home server and you reach it from a laptop or a phone, AriaNg is aimed at you. If you run aria2 on the same desktop you browse from, AriaNg is still usable, but the value is smaller because you could also just use a native client. The README lists multi aria2 RPC host support, so one AriaNg page can point at several aria2 instances, which matters when you have more than one machine downloading.

How a static page drives a remote download engine

The README says AriaNg is written in pure html and javascript, and that it does not need any compilers or runtime environment. The repository confirms the shape of that claim: package.json lists AngularJS 1.6.10, angular-route, angular-translate, angular-websocket and echarts among its dependencies, and the source lives under src/. There is no server component in the tree. Everything the browser needs is fetched as static assets.

The data flow is therefore browser to aria2, not browser to AriaNg to aria2. AriaNg holds the RPC endpoint and secret in its own settings, opens a connection, and issues aria2 RPC methods. Task state comes back over that connection. The README notes that AriaNg uses less bandwidth because it only requests incremental data, which is consistent with a websocket-based notification channel rather than polling the full task list on a timer. Charts for download and upload speed are drawn client-side with echarts from the values aria2 reports.

Two consequences fall out of this architecture. First, the browser must be able to reach the aria2 RPC port directly. There is no proxy in the middle. Second, the RPC secret is entered in the browser and stored client-side; the README lists exporting and importing settings, which means that configuration, including the endpoint details, can be moved between machines as a file. Treat that file as a credential.

Installing AriaNg from a release or from source

The README offers three distributions. The standard version is meant for deployment in a web server and loads resources on demand. The all-in-one version packs everything into a single HTML file for local use. AriaNg Native is a separate repository for local use without a browser. Prebuilt releases are on the GitHub releases page, and the README also links a daily build archive for the standard version.

If you build from source, the README requires Node.js, NPM and Gulp, then gives the standard build as two commands. The output lands in the dist directory.

npm install
gulp clean build

For the single-file build the second command changes, and the result is again written to dist.

gulp clean build-bundle

package.json sets the Node engine to >=14, so an older Node will not satisfy the declared requirement. Once built, the standard version is a directory of static files. Serve it from any web container and open the page in a browser. The README is explicit about one trap: because the standard version loads language resources asynchronously, you may not open index.html directly on the local file system. For local use it points at the all-in-one version, a web container, or AriaNg Native.

After the page loads, the first real step is pointing it at an aria2 instance. AriaNg's settings include the RPC host, port and secret for each aria2 you want to manage. Fill those in, save, and the task list populates from the running engine. If the list stays empty, the usual cause is that aria2's RPC interface is not enabled or the browser cannot reach that port, not a fault in the page.

Task handling: sorting, filtering and the features that earn their place

The feature list is long, and the parts that matter are the ones aria2's own interface cannot give you. Tasks can be sorted by name, size, progress, remaining time or download speed. They can be searched, retried, and reordered by dragging. Files inside a task can be filtered by type, with the README naming videos, audios, pictures, documents, applications and archives, or by file extension. Multi-directory tasks get a tree view. Speed charts exist for aria2 as a whole or for a single task.

The BitTorrent side is more specific than most frontends bother with. The README mentions sorting bittorrent peers and showing health percentage and client information for peers. That is the kind of detail you want when a torrent stalls and you need to know whether peers are connecting at all.

The settings page claims full support for aria2 settings, which is a broad claim and worth testing against your aria2 version rather than assuming. Dark theme, download finished notifications, multi-language support and a URL command line API round out the list. The URL command line API is the one to note for scripting: it lets a link carry a task into AriaNg rather than requiring you to type it into the form.

Where AriaNg is the wrong tool

The most common misunderstanding is treating AriaNg as a download manager. It is not one. The README's own description calls it a frontend, and the repository contains no download engine. Install AriaNg without aria2 running somewhere and you get an interface with nothing behind it. Every download, every BitTorrent peer connection and every file write is aria2's work.

The second limitation is reachability. Because the browser talks to aria2 directly, an aria2 RPC port exposed to a network is exposed to anyone who can reach it and knows the secret. AriaNg does not add a layer that changes that. If your aria2 host is on the public internet, the security question is about how you expose the RPC endpoint, and AriaNg is not part of the answer.

Third, the standard version's asynchronous language loading rules out the simplest deployment people try first: downloading the archive and double-clicking index.html. The README warns about this directly. You either serve it over HTTP, take the all-in-one build, or use AriaNg Native.

Finally, the frontend stack is AngularJS 1.6.10, a line that reached end of life long before this project's recent releases. That does not make AriaNg unusable, but it does mean the browser code is built on a framework that no longer receives upstream fixes, and contributors working on the UI inherit that constraint.

AriaNg against a native desktop client

The natural alternative is a desktop program that bundles aria2 and its own interface into one application, which is what the AriaNg Native repository does for the no-browser case. The difference is architectural rather than cosmetic. A browser-based AriaNg keeps the engine and the interface on separate machines, so the download runs on the server and the window can be closed. A bundled desktop client puts both on the machine you are sitting at, which is simpler to set up and harder to use as a always-on download box.

That trade-off decides the choice more than any feature list. If your downloads should continue when your laptop sleeps, the split architecture is the point. If you want one installer and no RPC configuration, the bundled approach is less work. AriaNg's multi-host support has no equivalent in a single-machine client, and a single-machine client does not need it.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-12. Releases are spaced months apart: 1.3.12 in December 2025, 1.3.13 in January 2026, and 1.3.14 in June 2026. That cadence suggests a project in maintenance rather than one adding large features, and the README's feature list reads as settled.

Upgrade cost is low by design. The standard version is a directory of static files, so replacing it is a file copy, and the all-in-one version is a single HTML file. Settings can be exported and imported, which means a rebuild or a move to another host does not require re-entering every aria2 endpoint by hand. The main upgrade friction is the build toolchain: rebuilding from source needs Node.js at the version package.json declares, plus Gulp, and the dependency list pins several AngularJS packages at 1.6.10 while pulling others from a git URL, which makes a clean install dependent on that remote being reachable.

AriaNg is MIT licensed. In practical terms that permits reuse and redistribution with the licence and copyright notice retained. What it does not do is grant anything regarding aria2 itself, which is a separate project with its own licence, so a deployment that ships both needs to account for both. Nothing here is legal advice; read the LICENSE file in the repository.

Editorial conclusion

AriaNg suits people who already run aria2 and want a task list, file filters, speed charts and a settings page without editing JSON-RPC calls by hand, especially when the aria2 host is a headless box and the browser is somewhere else. It does not suit anyone looking for a download manager that works on its own, since AriaNg has no engine and no download code at all; if aria2 is not installed and reachable over RPC, AriaNg shows an empty page. Before adopting it, confirm the aria2 host has RPC enabled, that the browser can reach that host directly, and that you have chosen between the standard version, the all-in-one file and AriaNg Native, because the standard build loads language resources asynchronously and will not run from a local file path.

Frequently asked questions

Official sources

1. License: MIT
2. mayswind/AriaNg on GitHub
3. Project website
4. README
5. Releases