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
Core bricks	✅	✅	✅
Premium bricks	❌	✅	✅
CLI updates	✅	✅	✅
Priority support	❌	✅	✅
Brick source code	❌	❌	✅
Custom brick development	❌	❌	✅
Shared git repository	❌	❌	✅
Dedicated support channel	❌	❌	✅

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. Subscription activation --- When your Enterprise subscription is activated, you receive a GitHub organization invitation to the banua-coder 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 --- When your subscription expires or is cancelled, your GitHub access is automatically revoked within 24 hours.

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 banua-coder/archipelago-enterprise to your organization's GitHub account:

# Using GitHub CLI
gh repo fork banua-coder/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 Archipelago CLI at your fork instead of the official registry:

# Switch to git-based source
archipelago config set source git

# Point to your fork
archipelago config set repo https://github.com/your-org/archipelago-enterprise.git

# Verify configuration
archipelago config show

From this point, all archipelago generate commands will pull bricks from your fork.

Step 4: Revert to Official Source

To switch back to the official Cloudflare R2-hosted bricks:

archipelago config set source r2

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/banua-coder/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:

# In your CI environment
archipelago config set source git
archipelago config set repo https://github.com/your-org/archipelago-enterprise.git

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 for debug/release stripping 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