# aria2 documents a monthly release cadence and has not cut a release since November 2023

> aria2 is a C++ command-line downloader covering HTTP, FTP, SFTP, BitTorrent and Metalink, and its README is unusually precise about dependencies and version policy. It is just as precise about the gap: the newest release is 1.37.0 from 2023-11-15 while the last commit is 2026-06-25, and the tree holds no general Linux or Windows install path.

**aria2/aria2** — aria2 is a lightweight multi-protocol & multi-source, cross platform download utility operated in command-line. It supports HTTP/HTTPS, FTP, SFTP, BitTorrent and Metalink.

- Repository: https://github.com/aria2/aria2
- Website: https://aria2.github.io/
- Stars: 42,805 · Forks: 3,937
- Language: C++
- License: GPL-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/aria2-aria2

## A monthly release schedule with no release since 2023-11-15

The version policy is specific. Versions are MAJOR.MINOR.PATCH, MINOR updates ship on the 15th of every month, a release is skipped when nothing changed since the last one, the feature and documentation freeze lands 10 days before release day for translation teams, an issue is opened around the 5th to announce the upcoming release, PATCH releases appear between regular ones for security issues, and the MAJOR number stays at 1.

Then look at what actually shipped. 1.37.0 is dated 2023-11-15. Before it, 1.36.0 is dated 2021-08-21 and 1.35.0 is dated 2019-10-06. A monthly cadence has produced three releases across roughly seven years.

Two consequences follow. The skip clause is carrying that entire sentence, and a user waiting on the 15th gets no signal that a month came and went. And because PATCH releases are reserved for security issues, a non-security fix has no documented route to a release: what is written here is a calendar, not a queue.

## You do not pick the crypto library, the build host does

Five SSL and crypto configurations are named: OpenSSL, GnuTLS with libgcrypt, GnuTLS with libnettle, Apple TLS on OSX, and Windows TLS on Windows. Which one you get is settled by precedence rather than by you. Apple TLS is preferred on OSX, GnuTLS has precedence over OpenSSL, Schannel is preferred on Windows, and libnettle has precedence over libgcrypt. The configure switches exist to demote a winner, not to pick one.

Those switches come in pairs. Forcing OpenSSL means passing `--without-gnutls --with-openssl`, forcing libgcrypt means `--without-libnettle --with-libgcrypt`, and preferring Expat means `--without-libxml2` because libxml2 has precedence. libxml2 gates two separate features, Metalink and XML-RPC, so that one switch moves both.

For a reproducible build this matters. Two hosts with different libraries installed produce different binaries from identical source, and the flags that would pin the choice are the ones you find here rather than in a flag reference. On OSX, Apple TLS also wins the checksum side unless you add `--without-appletls`.

## With no optional libraries, checksums fall back to md5 and sha1

The dependency table marks BitTorrent and Checksum as needing nothing, with libnettle, libgmp, libgcrypt, OpenSSL or the platform TLS listed as optional. A note then covers the case where none of the optional pieces are present: an internal implementation supporting only md5 and sha1 is used.

That fallback is what makes the Metalink story delicate. Metalink version 4 under RFC 5854 and Metalink version 3.0 are both listed, and one named feature is validating chunks of data automatically using Metalink's chunk checksums, with a separate line for chunk checksum validation in Metalink. A manifest can name hashes stronger than the two your build can check, and nothing at download time announces the downgrade.

The same asymmetry shows up elsewhere. JSON-RPC over WebSocket needs libnettle, libgcrypt or OpenSSL, and unlike Checksum it gets no fallback row in the table at all, so a build with no crypto library loses that transport without a documented substitute.

## Dockerfiles for Android, MinGW and Raspberry Pi, none for a server

The tree carries three Dockerfiles: Dockerfile.android, Dockerfile.mingw and Dockerfile.raspberrypi. There is no general purpose Linux image definition, and no compose file or publish workflow for a server deployment.

The three that exist map neatly onto the awkward targets, an ARM handheld, a Windows cross-compile, and a single board computer, so the split reads as deliberate. It is also the whole set of recipes on offer. A team putting aria2 into a container on x86 has to write the build itself, dependency choices included, because nothing in the repository does that part.

The surrounding tooling is modest in the same direction. Continuous integration is a single .travis.yml, and release automation is makerelease and makerelease-osx.mk, which says the packaging path was built around producing a desktop bundle rather than publishing containers.

## Four READMEs and none of them is the general build

The top level holds README, README.rst, README.android and README.mingw, next to android-config, android-release, mingw-config, mingw-release, mingw-build-memo and osx-package/. The build instructions that do exist live in configure.ac, m4/, Makefile.am and doc/.

Platform knowledge is duplicated on purpose. Every target in the list above gets a config directory, a release directory and a README, and three of them also get a Dockerfile. The general case, building against the ordinary system libraries of a mainstream Linux distribution, has no platform file and no README of its own. What is left is configure.ac and the online manual.

The consequence is that a build failure on a normal Linux host is yours to diagnose. The dependency table tells you which library gates which feature, but it does not say where configure searches for it or what the failure looks like when the search comes up empty.

## SFTP and cookie support have no opt-out, unlike BitTorrent and Metalink

Exactly two features can be removed at configure time, and both flags are given: `--disable-bittorrent` and `--disable-metalink`. Nothing else in the table carries a switch.

SFTP is the sharp case, because its dependency libssh2 is listed with no optional marker at all. HTTPS and Checksum can fall back to the platform, and BitTorrent and Metalink can be turned off, but there is no way to drop SFTP. The same holds for gzip and deflate, which need zlib, async DNS, which needs c-ares, cookie loading in the Firefox3, Chromium and Mozilla formats, which needs libsqlite3, and XML-RPC, which needs libxml2 or Expat.

So on a host without libssh2 the SFTP code is not switched off, it is simply absent, and no configure flag makes that visible. You find out by building and reading what was skipped, not by asking the build system what it left out.

## The RPC interface exists, the interface does not

aria2 is described as operated in command-line, and nothing here is a graphical front end. What does exist is a control surface for something else to drive: a JSON-RPC interface over HTTP and WebSocket, an XML-RPC interface, and the ability to run as a daemon process. Two binding examples sit in the tree, libaria2ex.cc and libaria2wx.cc.

The gap is worth stating plainly, because the questions aimed at this project mostly ask for a graphical download manager, a web UI, a browser extension and a file manager integration. None of that ships here, and it would not be a small addition, since it means speaking JSON-RPC over HTTP or WebSocket to a daemon whose own options are described in the online manual rather than in the file.

The embedding path carries its own condition. libaria2 is a C++ library, the project began on C++98 and C++03 and is migrating to C++11, and the current source requires a C++11 aware compiler. Holding that from another language means holding that ABI.

## No warranty, and the first section says exactly that

The opening section is a disclaimer rather than a description. The program comes with no warranty, and you must use it at your own risk. Licensing is GPL-2.0, with COPYING in the tree and a separate LICENSE.OpenSSL alongside it for the bundled TLS code.

Documentation is thin by design rather than by neglect, and the file says where the rest lives: the online manual at https://aria2.github.io/manual/en/html/, with Russian and Portuguese translations under the ru and pt paths, and the project page at https://aria2.github.io/.

The command count across the whole file is one, and it fetches the source:

```bash
$ git clone https://github.com/aria2/aria2.git
```

No invocation, no option, no configuration file sample. Everything a user needs sits one click past this file, which is fine if you follow the links and awkward if you are working from a mirror with no outbound access.

## Conclusion

Use aria2 when you genuinely need several protocols in one binary, want HTTP and BitTorrent pulling the same file at once, or need a JSON-RPC daemon that a frontend you already own can drive. Skip it if you need a graphical download manager, because none ships here and the RPC surface is the whole integration story. Before you commit, check the two dates that matter more than the feature list: the newest tag is 1.37.0 from 2023-11-15 and the newest commit is 2026-06-25, so decide whether a package you did not build is acceptable to you. Then confirm your build has libssh2, since SFTP has no opt-out switch, and read which TLS library configure actually selected.

## FAQ

### What is aria2 used for?

For downloading files over HTTP(S), FTP, SFTP, BitTorrent and Metalink, from multiple sources and protocols at once, with segmented downloading aimed at your maximum bandwidth. It can pull the same file from HTTP(S), FTP or SFTP and from BitTorrent simultaneously, uploading what it takes from the HTTP side into the swarm.

### Is aria2 free?

It is licensed GPL-2.0. The repository carries COPYING, and a separate LICENSE.OpenSSL covers the OpenSSL code.

### Is aria2 safe to use?

The file opens with a disclaimer: the program comes with no warranty and you must use it at your own risk. On the protocol side it can verify a peer using a given trusted CA certificate in HTTPS, and it supports client certificate authentication in HTTPS.

### how to use aria2

The README carries no usage command. Its one command clones the source, and it directs you to the online manual at https://aria2.github.io/manual/en/html/ with Russian and Portuguese translations for everything else.

### how to install aria2 on windows

No installer or binary step is given. The tree holds README.mingw, mingw-config, mingw-release, mingw-build-memo and Dockerfile.mingw, and on Windows an SSL implementation based on the native Windows capabilities is preferred unless configure is run with `--without-wintls`.

## Sources

- [aria2/aria2 on GitHub](https://github.com/aria2/aria2)
- [License: GPL-2.0](https://github.com/aria2/aria2/blob/master/LICENSE)
- [Project website](https://aria2.github.io/)
- [README](https://github.com/aria2/aria2/blob/master/README.md)
- [Releases](https://github.com/aria2/aria2/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aria2-aria2