brave/brave-browser is a release and issue tracker, not the source tree

What brave/brave-browser actually is

The first line of the README settles the question that most visitors get wrong: "This repository is not needed for building the browser and only holds issues, releases and the wiki." Anyone who lands on the GitHub page looking for a Chromium fork to compile has arrived at the wrong address. The code lives at brave/brave-core, and the README points there directly.

What the repository does hold is the operational surface of a shipped product. Bug reports and feature requests go into the issue tracker. Release artifacts are attached to GitHub releases. The wiki carries documentation aimed at developers, administrators and power users, while end users are sent to the Brave help center instead. That split is deliberate: three audiences, three destinations, and the repository is the entry point that routes between them.

The audience is therefore narrower than the project name suggests. You are in the right place if you want to report a defect, read a changelog, download an installer, or find the release schedule. You are in the wrong place if you want to send a patch, because the contributing guidelines live in brave-core's CONTRIBUTING.md.

How releases and changelogs are organised

The repository root carries four separate changelog files: CHANGELOG_DESKTOP.md, CHANGELOG_DESKTOP_ARCHIVE.md, CHANGELOG_DESKTOP_ORIGIN.md, CHANGELOG_ANDROID.md and CHANGELOG_iOS.md. Splitting desktop history into a current file, an archive and an origin file is a maintenance decision worth noticing. It keeps the active desktop changelog readable at the cost of making historical lookups a two-step search, and anyone scripting against these files has to know which of the three to open for a given version.

The package.json at the root describes the repository as "Brave browser for Android, iOS, Linux, macOS, and Windows" and pins the version to 1.98.12. That version field tracks the release train rather than a buildable artifact, which fits a repository whose job is to publish.

The recent release tags follow a Nightly pattern. v1.98.12, v1.98.11 and v1.98.10 all carry the label "Nightly" and the same Chromium base, 154.0.8037.49, with publication timestamps on 2026-09-19, 2026-09-18 and 2026-09-18 respectively. Three nightly tags in roughly two days is a normal cadence for a Chromium downstream, but it also means the most recent tags on this repository are not the stable builds most users want. The README directs visitors to brave.com/download for the latest stable release, and the wiki's Brave Release Schedule page is where the channel structure is documented.

Installing Brave and a first real use

The README does not give install commands. It gives a destination: the project says to visit brave.com/download to get the latest stable release, and package.json points at the same repository homepage. So the honest instructions are to install through that page rather than through a command copied from this article.

For Linux users who prefer a package manager, the project's own download page is still the source of the exact repository line and package name, because the README does not specify them. What the repository does give you is the release feed, which is useful when you want a specific build rather than the current stable. The releases page lists tags such as v1.98.12, and each tag is a Nightly build against Chromium 154.0.8037.49.

If you are working from the repository itself, the only runnable thing present at the root is the package metadata. Reading it is a one-liner:

git clone https://github.com/brave/brave-browser.git
cd brave-browser
cat package.json

What you should see is a small JSON document with name "brave", version "1.98.12", license "MPL-2.0" and an author field pointing at Brave Software. There is no build script, no dependency list and no start command. That absence is the tutorial's real lesson: cloning this repository gives you changelogs, licence text and metadata, and nothing executable.

For developers who want the source, the README sends you to the wiki to get started building Brave, and to brave-core for the code itself. The wiki is also where the release schedule is documented, which is what you consult when deciding whether to track a nightly or wait for stable.

The limitation: a repository with no buildable code

The most common failure mode here is a reasonable one. Someone searches GitHub for Brave, finds brave/brave-browser, clones it and expects a browser. The README warns against exactly that, but the warning is one sentence near the top and easy to skim past. There is no build script, no dependency manifest and no source directory in the top-level listing, which contains only .github/, .gitignore, the changelog files, LICENSE, README.md and package.json.

A second limitation is that the release tags on this repository are not a substitute for the download page. The three most recent tags are Nightly builds sharing Chromium 154.0.8037.49. Anyone who grabs a tag assuming it is the stable desktop build is picking up a pre-release channel. The README's pointer to brave.com/download exists precisely because the GitHub releases are not the recommended path for ordinary users.

Third, the documentation is deliberately split across three systems: this repository's wiki for developers and administrators, the Brave help center for end users, and brave-core's docs directory for deeper technical material. There is no single index. If you are troubleshooting an install on a specific platform, the README will not help you; it routes you elsewhere.

How this differs from building on Chromium directly

The obvious alternative for an engineer evaluating a browser codebase is to work from upstream Chromium. The difference in approach is structural. Chromium is the full source tree with its own build system and its own release process; brave-core is the downstream layer that adds Brave's changes on top of a pinned Chromium version, which is why the nightly tags in this repository name a specific Chromium build, 154.0.8037.49, rather than standing alone.

Choosing upstream Chromium means owning the entire build and its dependency graph. Choosing brave-core means inheriting a downstream patch set and tracking the Chromium version it is pinned to, which is a smaller surface but a coupled one: when the pin moves, the downstream changes move with it. This repository sits outside both paths. It is the coordination layer, not the code.

That distinction matters for anyone deciding where to spend effort. If your goal is to ship a browser, neither repository is a shortcut. If your goal is to report a bug or check what changed between releases, this is the repository that carries that information, and the changelog files at the root are the fastest way in.

Maintenance, licensing and the cost of tracking releases

The repository is not archived, and its last push was on 2026-09-19. That is two days before the date used for this assessment, so the tracker and release feed are current. The nightly tag cadence, three tags across 2026-09-18 and 2026-09-19, is consistent with that.

Upgrade cost depends on how you consume it. If you follow stable releases, the README's download page is the only thing you need to watch. If you follow the GitHub releases, you are opting into a nightly stream and should expect frequent version churn against a fixed Chromium base until that base moves. If you consume the changelog files programmatically, budget for the desktop history being spread across three files rather than one.

The licence at the repository root is MPL-2.0, and package.json repeats that identifier. MPL-2.0 is a file-level copyleft licence, which is a different obligation profile from permissive licences, but this repository contains documentation, changelogs and metadata rather than the browser's source, so the licence here governs the repository contents. The licence that applies to the browser binaries and to brave-core's source is a separate question, and the repository does not answer it. Check LICENSE at the root and the corresponding file in brave-core rather than assuming one identifier covers everything. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt brave/brave-browser as the place to file a bug, read a changelog or fetch a release artifact, and go to brave-core for anything involving code. Do not clone it expecting to build a browser, and do not read the CHANGELOG_* files as a substitute for the wiki's release schedule. Before relying on a build, verify which channel the release tag belongs to, since the recent tags are Nightly builds against Chromium 154.0.8037.49, and check the licence file at the repository root rather than assuming MPL-2.0 covers every bundled component.

Frequently asked questions

Official sources

1. brave/brave-browser on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases