Unofficial AppImages for Brave Web Browser x86_64/AMD64 and aarch64/ARM64

I have created all the releases of the major Chromium-based browsers:

• Chromium Stable/Candidate/Beta/Edge
• Chrome Stable/Beta/Unstable DEB, upstream
• Microsoft Edge Stable/Beta/Dev DEB, upstream
• Opera Stable/Beta/Dev DEB, upstream
• Vivaldi Stable/Snapshot DEB, upstream
• Yandex Browser Stable/Beta/Corporate DEB, upstream

...but Brave was missing from my collection... so I created this repository for consistency.

I have always admired and respected the work done at https://github.com/srevinsaju/Brave-AppImage that provides daily builds every day, for many years. It is not and was not my intention to compete with him... so much so that in my "AM" package manager I have always given priority to his builds rather than publishing mine.

Personally I'm not interested in taking away work from colleagues... I had my own method for building the AppImage and wanted to publish it.

Since March 23, 2025 I have decided to replace his scripts in the "AM" database using my builds (see https://github.com/ivan-hc/AM/commit/a4d4cc02f891bcc58ceb54ea204baa905ec229bb), but for three simple reasons:

• The historical repository https://github.com/srevinsaju/Brave-AppImage is not actively maintained, to the point that the v1.76.73 stable release has not been fixed for 2 weeks and was empty, despite a pull request opened for the same amount of time (see srevinsaju/Brave-AppImage#16 and srevinsaju/Brave-AppImage#17 for more context).
• My repository contains only one release, in order to speed up the download of others that are not "nightly", which on the contrary fill the "releases" section in https://github.com/srevinsaju/Brave-AppImage every day. This has always caused a slowdown when trying to install (for example) the "beta" build which gets buried in hundreds of pages.
• My repository also contains builds for aarch64/ARM64, so it is better to show only one reference repository instead of 3, to avoid confusion.

In my workflows, all six releases (three for each architecture) are complementary: if one fails, the others are not produced. And usually this risk is due to the burial of some "beta" among hundreds of pages where "nightly" reigns supreme, in the upstream repository.

On the other hand, I have made my own a battle that he started: to push the upstream developers to create an official one.

I don't know if I will succeed in my intent... in the meantime I participated in the discussion too brave/brave-browser#1060 (comment), and I am waiting for an answer.

I am not a user of Brave browser, or any Chromium-based browser... but I am an AppImage user and I want to support this packaging format. I do it for you. So help me put pressure on upstream and spread the word!

"AM"/"AppMan" is a set of scripts and modules for installing, updating, and managing AppImage packages and other portable formats, in the same way that APT manages DEBs packages, DNF the RPMs, and so on... using a large database of Shell scripts inspired by the Arch User Repository, each dedicated to an app or set of applications.

The engine of "AM"/"AppMan" is the "APP-MANAGER" script which, depending on how you install or rename it, allows you to install apps system-wide (for a single system administrator) or locally (for each user).

"AM"/"AppMan" aims to be the default package manager for all AppImage packages, giving them a home to stay.

You can consult the entire list of managed apps at portable-linux-apps.github.io/apps.