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

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 template enforces labeling requirements, including the "nightly" label for appropriate categorization. When PRs merge, the /.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 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, 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 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. 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. This produces optimized, production-grade binaries for all platforms. The 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

# 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	Guidelines for PRs, uplift process, and release notes
README.md	Build instructions including npm run build Release
.github/workflows/pull_request.yml	CI testing for all channels (master, beta, release)
.github/workflows/tweet-nightly.yml	Automation for nightly build notifications
.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	Historic release notes and channel-specific changes
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.
• 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 guidelines and enforced by /.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 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. 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, which enforces the "nightly" label for pull requests targeting the master branch.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}