Docs Flaunch CLI

Flaunch CLI

Blazing fast build, version bump, upload & notify tool

Flaunch is a powerful Rust-based CLI that automates your Flutter release workflow. Build, bump versions, upload to ReleaseHub, and notify your team — all in one command.

CLI Tool Rust Cross-Platform
Download .md

Installation

Install FLaunch using our one-line installer script for your platform:

Terminal
$ curl -fsSL https://releasehub.dev/install.sh | sh

This will download and install the latest FLaunch binary to ~/.local/bin. Make sure this directory is in your PATH.

Verify Installation

$ flaunch --version
flaunch 1.0.0

Supported platforms: macOS (Intel & Apple Silicon), Linux (x86_64 & ARM64), Windows (x86_64)

Quick Start

1

Initialize your project

Run the interactive setup wizard to create your configuration:

$ flaunch init
2

Configure your API key

Add your ReleaseHub API key to flaunch.local.yaml:

# flaunch.local.yaml (keep this file private!)
releasehub:
  api_key: "your-api-key-here"
3

Run your first release

Execute the full pipeline with a single command:

$ flaunch run --flavor dev

Configuration Overview

Flaunch uses two configuration files: flaunch.yaml for shared settings (committed to git) and flaunch.local.yaml for sensitive data (automatically added to .gitignore).

# flaunch.yaml - Example configuration

project:
  name: "My Flutter App"
  bundle_id: "com.example.myapp"
  type: "flutter"  # or "fvm", "cargo", "cargo-iss"
  output_naming: "{name}-{version}-{arch}-{flavor}.apk"

flavors:
  dev:
    display_name: "Development"
    single_apk: false
    build_commands:
      - "flutter build apk --flavor dev --split-per-abi"
    output_paths:
      - "./build/app/outputs/apk/dev/release/*.apk"

  prod:
    display_name: "Production"
    single_apk: true
    build_commands:
      - "flutter build apk --flavor prod --release"
    output_paths:
      - "./build/app/outputs/apk/prod/release/*.apk"

releasehub:
  api_url: "https://app.releasehub.dev"
  channel: "beta"

discord:
  webhooks:
    - "${DISCORD_WEBHOOK_URL}"
  include_commits: true

git:
  enabled: true
  auto_commit_bump: false

Commands

Complete reference for all Flaunch CLI commands.

flaunch run

Execute the full release pipeline: bump version, build, upload, and notify.

$ flaunch run --flavor dev --channel beta

Options

OptionDescriptionDefault
-f, --flavorBuild flavor to useRequired
-t, --bump-typeVersion bump: build, patch, minor, majorbuild
-c, --channelRelease channel for ReleaseHubConfig default
-l, --changelogRelease notes / changelog text-
--no-bumpSkip version bump stepfalse
--no-buildSkip build stepfalse
--no-uploadSkip upload stepfalse
--no-notifySkip Discord notificationfalse
--sftpForce SFTP upload instead of ReleaseHubfalse

flaunch bump

Bump the version number in your pubspec.yaml or Cargo.toml.

$ flaunch bump --type patch --commit
Bumping version...
1.2.3+45 → 1.2.4+46
Committed: chore: bump version to 1.2.4+46

Bump Types

build

1.2.3+45 → 1.2.3+46

patch

1.2.3+45 → 1.2.4+46

minor

1.2.3+45 → 1.3.0+46

major

1.2.3+45 → 2.0.0+46

Options

OptionDescriptionDefault
-t, --typeBump type: build, patch, minor, majorbuild
--commitAuto-commit the version bump (requires git enabled)false

flaunch build

Execute build commands for a specific flavor.

$ flaunch build --flavor prod

Options

OptionDescriptionDefault
-f, --flavorBuild flavor to useRequired

flaunch upload

Upload built APKs/AABs to ReleaseHub or via SFTP.

$ flaunch upload --flavor dev --channel beta -l "Bug fixes"
Uploading to ReleaseHub...
arm64-v8a → myapp-1.2.3+45-arm64-v8a-dev.apk
armeabi-v7a → myapp-1.2.3+45-armeabi-v7a-dev.apk

Options

OptionDescriptionDefault
-f, --flavorBuild flavor to useRequired
-c, --channelRelease channel for ReleaseHubConfig default
-l, --changelogRelease notes / changelog text-
-s, --sftpForce SFTP upload instead of ReleaseHubfalse

flaunch sync

Sync your local version with the latest from ReleaseHub. Useful for keeping multiple developers in sync.

$ flaunch sync --channel stable
Fetching latest version from ReleaseHub...
Remote: 1.2.4+48 (stable)
Local: 1.2.3+45
Synced: 1.2.3+45 → 1.2.4+49

Options

OptionDescriptionDefault
-c, --channelChannel to sync fromConfig default
-b, --bumpBump build number after syncingtrue

flaunch notify

Send a Discord notification about a build.

$ flaunch notify --flavor dev

Options

OptionDescriptionDefault
-f, --flavorBuild flavor to useRequired
-r, --resultsJSON upload results (piped from upload command)-

The --results flag accepts JSON-formatted upload results, typically piped from the upload command for richer Discord notifications with download links.

flaunch version

Display the current version from pubspec.yaml or Cargo.toml.

$ flaunch version
1.2.3+45

flaunch flavors

List all available build flavors defined in your configuration.

$ flaunch flavors
Available flavors:
Development (split)
Production (single)

flaunch validate

Validate your configuration file and check for common issues.

$ flaunch validate
Validating config...
pubspec.yaml found
flavor 'dev' is valid
flavor 'prod' is valid
ReleaseHub config is valid
Config is valid!

flaunch init

Run the interactive configuration wizard to create a new flaunch.yaml file.

$ flaunch init

Options

OptionDescription
-f, --forceOverwrite existing config file

Global Options

These options can be used with any command:

OptionDescriptionDefault
-c, --configPath to config fileflaunch.yaml
-C, --directoryWorking directoryCurrent directory
-v, --verboseEnable verbose outputfalse

Tip: You can also set the config path via the FLAUNCH_CONFIG environment variable.

Configuration Reference

Detailed reference for all configuration options.

Project Settings

project:
  name: "My App"           # Display name
  bundle_id: "com.example.app"  # App bundle ID
  type: "flutter"          # Project type
  output_naming: "{name}-{version}-{arch}.apk"

Built-in Project Types

TypeVersion FileVersion FormatDefault Bump
flutterpubspec.yamlX.Y.Z+Bbuild
fvmpubspec.yamlX.Y.Z+Bbuild
cargoCargo.tomlX.Y.Zpatch
cargo-issCargo.toml + *.issX.Y.Zpatch

Project types are data-driven using JSON definitions. You can create custom types or override built-in ones. See Custom Project Types for details.

Output Naming Placeholders

PlaceholderExampleDescription
{name}MyAppProject name
{bundle_id}com.example.appBundle identifier
{version}1.2.3+45Full version string
{semver}1.2.3Semantic version only
{build}45Build number only
{flavor}devBuild flavor name
{arch}arm64-v8aCPU architecture

Custom Project Types

FLaunch uses data-driven project type definitions stored as JSON files. This enables you to add support for new project types, customize version patterns, or define secondary files that should be updated alongside the main version file.

Type Definition Locations

FLaunch searches for type definitions in this order:

PriorityLocationPurpose
1 %APPDATA%\flaunch\types\ (Windows)
~/.config/flaunch/types/ (macOS/Linux)
Custom types & overrides
2{install_dir}/types/Bundled defaults

Creating a Custom Type

Create a JSON file in your user types directory. Example for Node.js projects:

// %APPDATA%\flaunch\types\node.json
{
  "name": "node",
  "display_name": "Node.js",
  "description": "Node.js projects using package.json",

  "version_format": {
    "pattern": "^(\\d+)\\.(\\d+)\\.(\\d+)$",
    "has_build_number": false,
    "example": "1.2.3"
  },

  "default_bump_type": "patch",

  "version_files": {
    "primary": {
      "path": "package.json",
      "read_pattern": "\"version\"\\s*:\\s*\"(?P<version>[^\"]+)\"",
      "write_template": "\"version\": \"{version}\""
    }
  }
}

Type Schema Reference

FieldTypeDescription
namestringInternal identifier (matches filename)
display_namestringHuman-readable name
descriptionstring?Optional description
extendsstring?Parent type to inherit from
version_format.patternregexValidates version strings
version_format.has_build_numberboolWhether versions have +N suffix
default_bump_typestring"build", "patch", "minor", or "major"
version_files.primaryobjectMain version file definition
version_files.secondaryarray?Additional files to update

Type Inheritance

Types can inherit from other types using the extends field. Child values override parent values:

// cargo-iss inherits from cargo, adds secondary files
{
  "name": "cargo-iss",
  "display_name": "Rust + Inno Setup",
  "extends": "cargo",

  "version_files": {
    "secondary": [
      {
        "path_glob": "installer/*.iss",
        "read_pattern": "#define\\s+MyAppVersion\\s+\"(?P<version>[^\"]+)\"",
        "write_template": "#define MyAppVersion \"{version}\"",
        "version_format": "semver_only"
      }
    ]
  }
}

Tip: Use version_format: "semver_only" for secondary files that shouldn't include build numbers (e.g., .iss files use X.Y.Z, not X.Y.Z+B).

Build Flavors

flavors:
  dev:
    display_name: "Development"
    single_apk: false        # Split APKs per architecture
    build_commands:
      - "flutter build apk --flavor dev --split-per-abi"
    output_paths:
      - "./build/app/outputs/apk/{flavor}/release/*.apk"
    env:                      # Optional environment variables
      API_URL: "https://dev.api.example.com"

  prod:
    display_name: "Production"
    single_apk: true         # Universal APK
    build_commands:
      - "flutter build apk --flavor prod --release"
    output_paths:
      - "./build/app/outputs/apk/{flavor}/release/*.apk"

ReleaseHub Configuration

releasehub:
  api_url: "https://app.releasehub.dev"
  api_key: "${RELEASEHUB_API_KEY}"  # Use env var!
  channel: "beta"                   # Default channel
  platform: "android"              # android, windows, macos
  chunk_size: 10485760            # 10MB chunks
  create_as_draft: false

Security: Always store your API key in flaunch.local.yaml or use environment variables. Never commit API keys to version control!

SFTP Upload (Alternative)

upload:
  host: "your-server.com"
  port: 22
  username: "deploy"
  password: "${SFTP_PASSWORD}"  # Or use private_key
  # private_key: "~/.ssh/id_rsa"
  remote_dir: "/var/www/apk"

Discord Notifications

discord:
  webhooks:
    - "${DISCORD_WEBHOOK_URL}"
    - "https://discord.com/api/webhooks/..."  # Multiple webhooks
  embed_color: 3066993     # Green (decimal color)
  embed_title: "New Build Available!"
  include_commits: true   # Show git commits since last build

Git Integration

git:
  enabled: true
  build_cache: ".flaunch_cache"  # Tracks last build commit
  auto_commit_bump: false
  bump_commit_message: "chore: bump version to {version}"

Local Configuration Overrides

Create a flaunch.local.yaml file for machine-specific settings and sensitive data. This file is automatically added to .gitignore.

# flaunch.local.yaml - Local overrides (DO NOT COMMIT)

releasehub:
  api_key: "sk_live_xxxxxxxxxxxxxxxxxxxx"

discord:
  webhooks:
    - "https://discord.com/api/webhooks/123/abc..."

upload:
  password: "my-sftp-password"

Best Practice: Keep flaunch.yaml in git with placeholder values, and use flaunch.local.yaml for actual secrets. Environment variables (${VAR_NAME}) are expanded automatically.

Interactive Mode

Running flaunch without arguments opens an interactive menu:

$ flaunch
flaunch • My App • Interactive
? Select an action:
Run full pipeline
Build only
Upload only
Bump version
Sync from remote
Show version
List flavors
Validate config
Exit

CI/CD Integration

Automate your release workflow with popular CI/CD platforms.

GitHub Actions

Create a workflow file at .github/workflows/release.yml to automate releases on push to main or on tags:

name: Release

on:
  push:
    tags:
      - 'v*'
  workflow_dispatch:
    inputs:
      flavor:
        description: 'Build flavor'
        required: true
        default: 'prod'
        type: choice
        options:
          - dev
          - prod

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.24.0'
          channel: 'stable'

      - name: Install FLaunch
        run: curl -fsSL https://releasehub.dev/install.sh | sh

      - name: Build and Release
        env:
          RELEASEHUB_API_KEY: ${{ secrets.RELEASEHUB_API_KEY }}
          DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}
        run: |
          flaunch run \
            --flavor ${{ inputs.flavor || 'prod' }} \
            --channel stable \
            --changelog "Release ${{ github.ref_name }}"

Tip: Store your RELEASEHUB_API_KEY and DISCORD_WEBHOOK_URL as GitHub repository secrets for security.

GitLab CI

Add to your .gitlab-ci.yml file:

stages:
  - release

variables:
  FLUTTER_VERSION: "3.24.0"

release:
  stage: release
  image: ghcr.io/cirruslabs/flutter:$FLUTTER_VERSION
  before_script:
    - curl -fsSL https://releasehub.dev/install.sh | sh
    - export PATH="$HOME/.local/bin:$PATH"
  script:
    - flaunch run --flavor prod --channel stable
  only:
    - tags
  variables:
    RELEASEHUB_API_KEY: $RELEASEHUB_API_KEY
    DISCORD_WEBHOOK_URL: $DISCORD_WEBHOOK_URL

Configure RELEASEHUB_API_KEY and DISCORD_WEBHOOK_URL as CI/CD variables in your GitLab project settings (Settings → CI/CD → Variables).

Bitbucket Pipelines

Add to your bitbucket-pipelines.yml file:

image: ghcr.io/cirruslabs/flutter:3.24.0

pipelines:
  tags:
    'v*':
      - step:
          name: Build and Release
          caches:
            - flutter
          script:
            - curl -fsSL https://releasehub.dev/install.sh | sh
            - export PATH="$HOME/.local/bin:$PATH"
            - flutter pub get
            - flaunch run --flavor prod --channel stable --changelog "Release ${BITBUCKET_TAG}"

definitions:
  caches:
    flutter: ~/.pub-cache

Add RELEASEHUB_API_KEY and DISCORD_WEBHOOK_URL as repository variables in Bitbucket (Repository settings → Pipelines → Repository variables).

CI/CD Best Practices

Secure Secrets

Never commit API keys or webhooks. Use CI/CD platform secrets or environment variables.

Use Tags

Trigger releases on Git tags (e.g., v1.2.3) for controlled deployments.

Cache Dependencies

Cache Flutter packages and FLaunch binary to speed up builds.

Version Sync

Use flaunch sync to keep version numbers consistent across team members.

Note: When using --no-bump in CI, ensure your version is already bumped before pushing the tag, or use flaunch sync to get the latest version from ReleaseHub before building.