# Brave Browser Development Flow: Nightly, Beta, and Stable Release Channels

> Understand Brave Browser's development flow from nightly to beta and stable releases. Learn how features progress through master to release channels every 4-6 weeks.

- Repository: [Brave Software/brave-browser](https://github.com/brave/brave-browser)
- Tags: internals
- Published: 2026-02-16

---

**Brave uses a three-channel release flow where features land on the `master` branch for nightly builds, get uplifted to the `beta` branch after stabilization, and finally promoted to the `release` branch for stable distribution every 4-6 weeks.**

The development flow for Brave's nightly, beta, and stable release channels follows a structured uplift process that balances rapid iteration with production stability. As a Chromium-based browser, the `brave/brave-browser` repository maintains three distinct release channels that allow developers to ship daily experimental features while providing users with thoroughly tested beta and stable builds. This channel strategy is defined in the repository's contribution guidelines and automated through GitHub Actions workflows.

## Nightly Channel Development on the Master Branch

All new features and bug fixes originate on the `master` branch, which serves as the **nightly** channel. This branch contains the latest Chromium integration and Brave-specific modifications, with automated builds produced daily or on every merge.

Developers create feature branches from `master` and submit pull requests targeting this branch. The [`/.github/ISSUE_TEMPLATE/01_desktop.yml`](https://github.com/brave/brave-browser/blob/main//.github/ISSUE_TEMPLATE/01_desktop.yml) template enforces labeling requirements, including the "nightly" label for appropriate categorization. When PRs merge, the [`/.github/workflows/tweet-nightly.yml`](https://github.com/brave/brave-browser/blob/main//.github/workflows/tweet-nightly.yml) workflow automatically posts notifications, signaling that a change has entered the nightly channel.

### Continuous Integration and Automated Builds

The [`/.github/workflows/pull_request.yml`](https://github.com/brave/brave-browser/blob/main//.github/workflows/pull_request.yml) workflow executes the full test suite on every PR to `master`. Upon successful merge, the nightly build pipeline compiles binaries for all platforms (Windows, macOS, Linux, Android, iOS). These artifacts are distributed through Brave's nightly channel infrastructure, allowing early adopters and developers to test bleeding-edge features.

## Uplifting Changes to the Beta Channel

When a feature or critical bug fix on `master` reaches sufficient stability, it undergoes **uplift** to the `beta` branch. This process typically occurs every 2-4 weeks, creating a beta release candidate that receives broader testing before stable promotion.

The uplift process is governed by [`CONTRIBUTING.md`](https://github.com/brave/brave-browser/blob/main/CONTRIBUTING.md), which references the **Uplifting a Pull Request** wiki documentation. Uplifts require specific approval from the `@brave/uplift-approvers` team, defined in `/.github/CODEOWNERS`. Contributors initiate uplifts by cherry-picking commits from `master` into a new branch based on `beta`, then submitting a PR with the "beta" label specified in the issue templates.

### The Uplift Workflow

The uplift script automates commit transfer from `master` to `beta`, handling version number increments and conflict resolution. After merge, the beta CI pipeline ([`pull_request.yml`](https://github.com/brave/brave-browser/blob/main/pull_request.yml) runs on the `beta` branch) validates the uplifted changes. Successful builds generate beta binaries distributed to the Brave Beta channel users for real-world testing.

## Promoting to the Stable Release Channel

Following successful beta validation (typically 4-6 weeks), changes undergo final **uplift** to the `release` branch for stable distribution. This branch represents the production-ready state of Brave Browser.

The release uplift follows the same cherry-pick methodology as beta, but targets the `release` branch and uses the "release (stable)" label from [`/.github/ISSUE_TEMPLATE/01_desktop.yml`](https://github.com/brave/brave-browser/blob/main//.github/ISSUE_TEMPLATE/01_desktop.yml). Version bumping occurs via `npm version` commands, creating the official release version string.

### Release Build Process

Stable builds are generated using `npm run build Release`, as documented in [`README.md`](https://github.com/brave/brave-browser/blob/main/README.md). This produces optimized, production-grade binaries for all platforms. The [`CHANGELOG_DESKTOP_ARCHIVE.md`](https://github.com/brave/brave-browser/blob/main/CHANGELOG_DESKTOP_ARCHIVE.md) tracks release-specific changes, including platform-specific packaging requirements like the `brave-keyring` dependency on Linux.

After build completion, maintainers create a Git tag (`vX.Y.Z`) and push it to the repository. Release notes are compiled from the changelog, and binaries are published to Brave's official website and GitHub releases page for automatic distribution to stable channel users.

## Essential Commands for Channel Management

```bash

# Sync the repository (updates Chromium and brave-core)

npm run sync

# Build for different channels

npm run build                # Component build (default, used for nightly CI)

npm run build Release        # Full release build (stable channel)

# Create a beta uplift from master

git checkout -b uplift-beta
git cherry-pick <commit-sha>   # Copy specific commits from master

git push origin uplift-beta

# Open PR against beta branch with "beta" label

# Create a release uplift and version bump

git checkout release
git cherry-pick <commit-sha>
npm version 1.89.43          # Bump version (example)

git push origin release
git tag v1.89.43
git push origin v1.89.43

```

## Key Repository Files for Release Management

| File | Purpose |
|------|---------|
| [`CONTRIBUTING.md`](https://github.com/brave/brave-browser/blob/main/CONTRIBUTING.md) | Guidelines for PRs, uplift process, and release notes |
| [`README.md`](https://github.com/brave/brave-browser/blob/main/README.md) | Build instructions including `npm run build Release` |
| [`.github/workflows/pull_request.yml`](https://github.com/brave/brave-browser/blob/main/.github/workflows/pull_request.yml) | CI testing for all channels (master, beta, release) |
| [`.github/workflows/tweet-nightly.yml`](https://github.com/brave/brave-browser/blob/main/.github/workflows/tweet-nightly.yml) | Automation for nightly build notifications |
| [`.github/ISSUE_TEMPLATE/01_desktop.yml`](https://github.com/brave/brave-browser/blob/main/.github/ISSUE_TEMPLATE/01_desktop.yml) | PR templates with nightly, beta, and release (stable) labels |
| `.github/CODEOWNERS` | Defines `@brave/uplift-approvers` for uplift approval |
| [`CHANGELOG_DESKTOP_ARCHIVE.md`](https://github.com/brave/brave-browser/blob/main/CHANGELOG_DESKTOP_ARCHIVE.md) | Historic release notes and channel-specific changes |
| [`docs/source/conf.py`](https://github.com/brave/brave-browser/blob/main/docs/source/conf.py) | Version strings including alpha/beta/rc tags |

## Summary

- **Nightly channel** (`master` branch) receives all new features and fixes immediately, with automated daily builds triggered by merges and monitored via [`/.github/workflows/tweet-nightly.yml`](https://github.com/brave/brave-browser/blob/main//.github/workflows/tweet-nightly.yml).
- **Beta channel** (`beta` branch) receives code through the **uplift** process every 2-4 weeks, requiring cherry-picks from `master` and approval from `@brave/uplift-approvers` defined in `/.github/CODEOWNERS`.
- **Stable channel** (`release` branch) receives final uplifts every 4-6 weeks after beta validation, using `npm run build Release` to generate production binaries that are tagged and distributed to end users.
- The entire flow is orchestrated through [`CONTRIBUTING.md`](https://github.com/brave/brave-browser/blob/main/CONTRIBUTING.md) guidelines and enforced by [`/.github/workflows/pull_request.yml`](https://github.com/brave/brave-browser/blob/main//.github/workflows/pull_request.yml) CI across all three branches.

## Frequently Asked Questions

### How often does Brave ship updates for each release channel?

Nightly builds are produced daily or on every merge to `master`, providing immediate access to the latest features. Beta channel updates ship approximately every 2-4 weeks after changes are uplifted from `master` and validated. Stable releases occur roughly every 4-6 weeks following successful beta testing, though critical security updates may be expedited through the uplift process.

### What is the difference between uplifting and standard merging in Brave's workflow?

Standard merging occurs when developers submit pull requests directly to the `master` branch for inclusion in nightly builds. **Uplifting** is the specific process of cherry-picking commits from `master` into the `beta` or `release` branches to backport fixes or features to those channels without merging the entire branch history. Uplifts require specific labeling ("beta" or "release (stable)") and approval from the `@brave/uplift-approvers` team defined in `/.github/CODEOWNERS`.

### How do I trigger a release build for the stable channel?

To generate a production-ready stable build, run `npm run build Release` after synchronizing the repository with `npm run sync`. This command produces optimized binaries for all platforms from the `release` branch. After building, maintainers create a Git tag (e.g., `git tag v1.89.43`) and push it to the repository to trigger distribution pipelines. The [`README.md`](https://github.com/brave/brave-browser/blob/main/README.md) file contains the complete build instructions for different channel configurations.

### Where can I find the configuration for automated nightly build notifications?

The automated tweeting system for nightly builds is configured in [`/.github/workflows/tweet-nightly.yml`](https://github.com/brave/brave-browser/blob/main//.github/workflows/tweet-nightly.yml). This workflow monitors issues labeled "nightly" and posts notifications when nightly issues are closed, signaling that new builds are available. The labeling system is defined in [`/.github/ISSUE_TEMPLATE/01_desktop.yml`](https://github.com/brave/brave-browser/blob/main//.github/ISSUE_TEMPLATE/01_desktop.yml), which enforces the "nightly" label for pull requests targeting the `master` branch.