# aria2-static-builds: prebuilt aria2 binaries with OpenSSL linked in

> This repository publishes aria2 builds for GNU/Linux and Windows that have OpenSSL statically linked, so you do not need a toolchain or a working build of the download manager itself. The catch is that it is a mirror of release artefacts rather than a project, and the upstream releases it tracks have not moved since 1.37.0 in 2025.

**dmesg00/aria2-static-builds** — aria2 static builds for GNU/Linux & Windows (with OpenSSL). 

- Repository: https://github.com/dmesg00/aria2-static-builds
- Stars: 734 · Forks: 111
- Language: Shell
- License: GPL-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dmesg00-aria2-static-builds

## A build mirror, not a fork of aria2

This repository is a set of static builds of aria2 for GNU/Linux and Windows, with OpenSSL. It is not a fork of the download manager and it does not contain aria2's source code, and the distinction shows up in the release page immediately, because the source code links point at the upstream project's own releases rather than at this repository.

The source tarballs offered alongside the binaries are the upstream aria2 1.37.0 tar.bz2, tar.gz and tar.xz, downloaded from the aria2 project's release page. So the chain is clear. The upstream project produces the source, this repository compiles it and packages the results.

The repository itself is minimal in the way you would expect from a build mirror. The top level has a LICENSE.txt, a README.md, a build-scripts/ directory and a certs/ directory. There is no source tree to read and no library to depend on, which is the point.

The licence file is GPL-2.0, matching the licence of the project it builds. The primary language of the repository is shell, which is the build scripts.

The release history is where the caveat lives. Version 1.36.0 was tagged on 2021-08-27, 1.35.0 on 2019-10-10, and the most recent is 1.37.0 from 2025-08-07. The last push to the repository was on 2026-06-06. So the artefacts are recent enough for a tool that does not change often, and the gap between upstream releases is simply the gap in aria2 itself rather than a gap in this mirror's maintenance.

What you get in exchange for not building is a binary that already has its dependencies linked in, which for a container image or an embedded device is often the whole point.

## Eight Linux packages for four architectures and three formats

The 1.37.0 release publishes eight GNU/Linux artefacts, which is three packaging formats across three architectures, plus two Windows archives.

The tarball versions are the generic ones, described as Generic Linux x86, Generic Linux x86_64 and Generic Linux ARM32, with the ARM build named for the Raspberry Pi. The .deb packages are the Debian and Ubuntu x86, x86_64 and ARM32 builds. The .rpm packages cover RedHat and Fedora on x86 and x86_64, with no RPM for ARM.

The naming convention is consistent and worth reading once, because it tells you the whole layout. Every artefact carries the version, the platform, the architecture, a build number and the format, so a file named aria2-1.37.0-linux-gnu-64bit-build1.deb is the Debian package for 64-bit x86 on build 1, and the same name with .tar.bz2 is the generic tarball for the same architecture.

The Windows side is two 7z archives, 32-bit and 64-bit. The Windows note in the README says this version includes a manifest for Windows 10, contributed by eladkarako, and there is a note that an error with the bcrypt.dll library on Windows XP has been fixed.

There is also a ca-certificates.crt file in the release, which is the piece that makes HTTPS work on Windows and is the subject of its own section further down.

The point of having all three Linux formats is that you can install the artefact that matches your distribution's package manager rather than unpacking a tarball into a directory and hoping the paths work.

## Installing on Linux and on Windows

The Linux instructions are three commands, and the archive name is templated on the architecture:

```shell
      $ tar jxvf aria2-1.37.0-linux-gnu-[arch]-build1.tar.bz2
      $ cd aria2-1.37.0-linux-gnu-[arch]-build1
      $ sudo make install
```

The make install step is the reason these are called static builds in practice, because the tarball ships with a makefile that installs the binary and its supporting files. The [arch] placeholder is where you substitute x86, x86_64 or arm-rbpi to match the artefact you downloaded.

The Windows instructions are manual. You unzip the package with 7-zip or Winrar, copy the files to a folder such as C:\Program Files\aria2, and then add that folder to your PATH variable so the binary is callable from a command prompt.

That last step is the one people forget. Without it, aria2c is not found, and the error message suggests a broken download rather than a missing PATH entry. There is no installer and no registry work, which is consistent with the approach of the project, and it means an unprivileged or portable setup is possible by putting the folder somewhere and pointing PATH at it.

The README links a search for how to add a folder to PATH on Windows, which is a small sign of the audience for these instructions.

## The Windows certificate path is the one real gotcha

To perform downloads using HTTPS on Windows, the ca-certificates file is necessary, and the reason is a difference between the platforms rather than a bug.

The Linux binaries read the certificates from /etc/ssl/certs/ca-certificates.crt by default. The Windows binaries have no such standard location, so the path has to be defined. The README explains two ways to do it.

The permanent way is to put a line in the aria2.conf file, which for a normal user is at C:\Users\<user>\.aria2\, and on Windows XP is at C:\Documents and settings\<user>\.aria2\. The line to add is:

```shell
ca-certificate=C:\Program Files\aria2\certs\ca-certificates.crt
```

The manual way is to pass it on the command line for a single invocation:

```shell
C:\PATH\> aria2c --ca-certificate=<PATH-TO-CERTIFICATE> <URL>
```

And there is a third option the README mentions, which is to disable certificate checking altogether:

```shell
C:\PATH\> aria2c --check-certificate=false <URL>
```

That last option is worth naming as the wrong default. It makes HTTPS work, and it removes the protection that certificates provide, so it is appropriate for a local test against a self-signed server and nothing else.

The ca-certificates.crt file in the release is the companion to all of this, and the path in the configuration example points at it inside the aria2 install folder, which means you copy the certs into the same tree as the binary rather than leaving them in the release directory.

## What is statically linked, and what the build depends on

The README lists the external libraries the builds use, and this is where the OpenSSL claim comes from.

The list is zlib, expat, c-ares, sqlite, OpenSSL and libssh2. Those are aria2's real dependencies rather than its optional ones, and in these builds they are linked in rather than expected to be found on the system.

The practical consequence is that a binary from this repository runs on a system with none of those development packages installed, which is the entire reason a static build exists. It also means the binary carries its own copy of the TLS stack, so the OpenSSL version inside it is whatever it was at build time, not whatever your distribution ships, and it will not pick up a system security fix to OpenSSL.

That last point is the trade-off of the whole approach and it is the one to hold onto. A self-contained binary is portable and predictable, and it is also a TLS implementation that only changes when the mirror rebuilds it.

The zlib dependency is there for the compression of downloaded content, expat is the XML parser, c-ares is the DNS resolver, sqlite is the session and download tracking store, and libssh2 gives you the SFTP support. So the feature set of the binary is the full aria2 feature set rather than a reduced build.

The upstream links are collected at the end of the README, pointing at the aria2 homepage, the aria2 documentation and the aria2 source code on GitHub, so the documentation you read is the upstream documentation, which is the right one.

## Where these builds are the wrong choice

The first wrong case is a system that already has aria2. Every mainstream Linux distribution packages aria2, and that package is built against your distribution's libraries, so it receives security updates with the rest of your system and it is one apt or dnf command rather than a tarball and a make install. Installing this build on such a machine adds a second, frozen copy of the same tool.

The second is a current aria2. The newest upstream release these builds cover is 1.37.0 from 2025-08-07, and the mirror does not follow upstream automatically, so if a newer aria2 has been released since, these artefacts are behind. The README does not describe a build cadence or an upstream watch, so the maintenance relationship is informal.

The third is a hardened or audited environment. A binary you did not build from source, delivered as a release asset, with a TLS stack baked in, is difficult to audit. Some organisations accept that for a tool like a download manager on a throwaway machine, and many will not accept it on a server that handles credentials.

The fourth is a platform other than Linux x86, x86_64, ARM32 or Windows. There is no macOS build, no 64-bit ARM Linux build, and no RPM for ARM, so a modern ARM server or an Apple Silicon machine is not covered.

The alternative worth weighing is building aria2 yourself, which is a well documented process and gives you the same static result with your own compiler flags and your own OpenSSL version. That is a lot of work for a one-off download, but for a distribution image you ship yourself it is the option that leaves you in control of what is inside the binary.

## Conclusion

Adopt these builds if you need an aria2 binary on a machine where compiling one is impractical, such as a minimal container or a NAS, and you want HTTPS to work without a separate OpenSSL package. Keep away if you need a current aria2, because the newest upstream release covered is 1.37.0 from 2025-08-07 and this repository does not build aria2 itself. Before you deploy, check the upstream changelog for anything newer, and remember that on Windows the ca-certificates path has to be set explicitly in aria2.conf or HTTPS downloads will fail while the binary otherwise works.

## FAQ

### What are the aria2 static builds and why would I use them?

They are prebuilt aria2 binaries for GNU/Linux and Windows with OpenSSL and the other dependencies linked in, so the download manager runs on a system with no separate build of those libraries. The repository does not contain aria2 source, it publishes compiled artefacts of the upstream releases.

### How do I install an aria2 static build on Linux?

Extract the tarball with tar jxvf, change into the extracted directory and run sudo make install. The archive name includes the architecture, so you substitute the one you downloaded, and the .deb and .rpm packages are also published for Debian, Ubuntu, RedHat and Fedora.

### Why do HTTPS downloads fail with the Windows aria2 build?

Because the Windows binaries have no standard certificate location to read from, unlike Linux which reads /etc/ssl/certs/ca-certificates.crt. You set the path in the aria2.conf file with a ca-certificate line pointing at the ca-certificates.crt from the release, or pass --ca-certificate on the command line for a single download.

### How old is the newest aria2 version in these builds?

The newest release covered is aria2 1.37.0, published on 2025-08-07, with the source tarballs linked from the upstream aria2 project. The last push to this repository was on 2026-06-06, and the previous build tags are 1.36.0 from 2021 and 1.35.0 from 2019.

## Sources

- [dmesg00/aria2-static-builds on GitHub](https://github.com/dmesg00/aria2-static-builds)
- [Issues](https://github.com/dmesg00/aria2-static-builds/issues)
- [License: GPL-2.0](https://github.com/dmesg00/aria2-static-builds/blob/master/LICENSE)
- [README](https://github.com/dmesg00/aria2-static-builds/blob/master/README.md)
- [Releases](https://github.com/dmesg00/aria2-static-builds/releases)

---

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