Enterprise

Archipelago Enterprise is designed for teams and organizations that need full control over their Flutter architecture toolkit. Everything in Pro, plus source code access, custom brick development, and dedicated support.

What Enterprise Includes

Feature	Free	Pro	Enterprise
Price	$0	$79 one-time	$199 one-time
Project scaffolds (archipelago create)	3 per month	Unlimited	Unlimited
Core bricks	✅	✅	✅
Premium bricks	❌	✅	✅
CLI updates	✅	✅	✅
Priority support	❌	✅	✅
Brick source code	❌	❌	✅
Custom brick development	❌	❌	✅
Shared git repository	❌	❌	✅
Highest-priority support	❌	❌	✅
Prebuilt CI runner image (Docker) — planned	❌	❌	✅
Blackbox viewer: open a .bbx file	✅	✅	✅
Blackbox recorder (app_blackbox_recorder)	❌	❌	✅
Blackbox cloud sync, session library and Compare versions	❌	❌	✅

See the Blackbox guide and Blackbox cloud sync.

Shared Git Repository

Enterprise subscribers get access to the full brick source code through a shared GitHub repository. This is the same source used to build the official bricks, so you always have a reference implementation.

How Access Works

1. Purchase activation --- When your Enterprise order is completed, you receive a GitHub organization invitation to the archipelagohq org with access to the archipelago-enterprise repository.

2. One shared repo --- All Enterprise subscribers share a single repository. This keeps everyone on the same codebase and makes upstream updates seamless.

3. Access revocation --- If your order is refunded, your GitHub access is revoked automatically.

WARNING

Do not commit sensitive or proprietary code directly to the shared repository. Fork it to your own organization first.

Fork & Customize

The real power of Enterprise is the ability to fork the source and customize bricks for your organization's specific needs.

Step 1: Fork the Repository

Fork archipelagohq/archipelago-enterprise to your organization's GitHub account:

# Using GitHub CLI
gh repo fork archipelagohq/archipelago-enterprise --org your-org --clone

Step 2: Customize Bricks

Once forked, you can modify any brick template:

• Change default directory structures
• Add organization-specific variables (e.g., analytics keys, API base URLs)
• Modify code generation patterns to match your team's conventions
• Add entirely new bricks following the Archipelago pattern

Step 3: Configure CLI to Use Your Fork

Point the CLI at your fork once — archipelago generate will use it for every subsequent run, no per-invocation flag required:

archipelago config set source git
archipelago config set repo https://github.com/your-org/archipelago-enterprise.git
archipelago config show

The first archipelago generate after this clones the fork into ~/.archipelago/git-cache/<slug>/. Later runs git fetch + reset so you always generate against the latest commit. Authentication is delegated to your local git config (credential helper / SSH key / gh auth).

If you want a one-off override without changing the persistent config, the --local-bricks <path> flag still works:

archipelago generate flutter_modular_monorepo \
  --local-bricks ~/work/archipelago-enterprise \
  --output ./my-new-app

Step 4: Revert to Official Source

archipelago config set source r2

The CLI immediately resumes downloading bricks from the official R2 distribution. Your brick_repo_url is preserved so you can switch back to git later.

Merging Upstream Updates

When new bricks or updates are released, you can pull them into your fork:

# Add upstream remote (one-time setup)
cd archipelago-enterprise
git remote add upstream https://github.com/archipelagohq/archipelago-enterprise.git

# Fetch latest changes
git fetch upstream

# Merge into your main branch
git checkout main
git merge upstream/main

If you have customized bricks, you may encounter merge conflicts. Resolve them by keeping your customizations where they differ from upstream, and accepting upstream changes for new features or bug fixes.

TIP

We recommend merging upstream at least once per month to stay current with security patches and new features. Each brick is independently versioned, so changelogs clearly indicate what changed.

Team Management

Adding Team Members

Enterprise access is managed through GitHub organization permissions:

1. Add team members to your GitHub organization
2. Grant them access to the forked archipelago-enterprise repository
3. Each developer configures the CLI to use your fork

Access Levels

Role	Permissions
Admin	Full repo access, manage team members, merge PRs
Developer	Clone, pull, push to feature branches, open PRs
Read-only	Clone and pull only (e.g., CI/CD systems)

CI/CD Access

For automated pipelines, create a GitHub machine user or use a deploy key. Either approach works:

Persistent config (recommended — cleaner CI scripts):

archipelago config set source git
archipelago config set repo https://github.com/your-org/archipelago-enterprise.git
archipelago generate <brick> --output ...

Per-invocation (when the CI runner already clones the fork as part of the job):

git clone https://github.com/your-org/archipelago-enterprise.git
archipelago generate <brick> --local-bricks ./archipelago-enterprise --output ...

Custom Brick Development

Enterprise subscribers can create organization-specific bricks that follow Archipelago patterns. This ensures consistency across your team's projects.

For a comprehensive guide on creating Mason bricks, see the official Mason documentation on BrickHub.

Brick Structure

Every Archipelago brick follows the Mason brick format:

bricks/
  your_custom_brick/
    __brick__/          # Template files with Mustache variables
    brick.yaml          # Brick metadata and variables
    CHANGELOG.md
    README.md

Creating a New Brick

1. Define the brick metadata in brick.yaml:

name: your_custom_brick
description: Organization-specific feature module
version: 0.1.0
vars:
  name:
    type: string
    description: Feature name
    prompt: What is the feature name?
  use_analytics:
    type: boolean
    description: Include analytics integration
    default: true
    prompt: Include analytics?

2. Create template files in the __brick__/ directory using Mustache syntax:

// __brick__/lib/{{name.snakeCase()}}/{{name.snakeCase()}}_module.dart
import 'package:injectable/injectable.dart';

@module
abstract class {{name.pascalCase()}}Module {
  // Register your dependencies here
}

3. Test locally before pushing:

mason make your_custom_brick --name my_feature --use_analytics true

Best Practices

• Follow the API/Impl split when your brick will be consumed by other features or needs vendor swapping
• Use the Impl + Noop pattern to strip debug tooling from the production flavor via build_prepare
• Keep variables minimal --- only expose what genuinely varies between projects
• Write a CHANGELOG --- other team members need to know what changed between versions
• Test the generated output --- run dart analyze and tests on the generated code before publishing

Enterprise Roadmap

The features below are planned as Enterprise-tier value adds. They are not available today; tracking issues link to the implementation plans. Subscribed Enterprise customers will get access at no additional cost as these ship.

Prebuilt CI runner image (Docker)

A private GHCR Docker image (ghcr.io/banua-coder/archipelago-flutter-ci) with Flutter SDK, Android SDK, JDK 17, Ruby + Fastlane, mason_cli, Melos, AWS CLI, and gh CLI preinstalled. Enterprise customers use it in four ways:

1. GitHub-hosted runners — single container: directive in generated workflows; cuts cold-start from ~5 min to ~30s
2. GitLab CI — image: directive; same image, GitLab variant adds Docker-in-Docker tooling
3. Self-hosted GitHub Actions runners — pre-pulled on the runner host
4. Developer machines — docker run -it -v $PWD:/work ... gives every dev the canonical Flutter env that matches CI byte-for-byte

A new CLI command archipelago enterprise setup-runner-image will issue a per-account, short-lived read:packages PAT bound to the customer's Enterprise license and write the Docker login config. Free/Pro tier generated workflows continue using subosito/flutter-action and the other marketplace actions — the brick template uses a useRunnerImage Mason variable to switch.

Blackbox (shipped)

Blackbox is no longer on the roadmap. The recorder, the viewer at archipelago.banuacoder.com/blackbox and cloud sync to your own bucket are available today. Any signed-in account can open a .bbx file in the viewer; recording and cloud sync are Enterprise. See the Blackbox guide.