Skip to main content
An Enterprise Plugin Registry is a centralized, private repository where organizations maintain approved plugins for company-wide distribution. Instead of individual teams discovering and vetting plugins independently, the registry provides a curated catalog of capabilities that are pre-approved, maintained, and ready to use.

​
Why use an Enterprise Plugin Registry?

ChallengeSolution
Inconsistent tooling across teamsSingle source of approved plugins ensures everyone uses the same capabilities
Security and compliance review for each pluginVet plugins once at the org level, distribute everywhere
Onboarding new developersNew team members instantly access all approved capabilities
Role-specific toolingPackage plugins by team function (security, frontend, data, etc.)
Version controlManage plugin versions centrally, roll out updates organization-wide

​
Setting up a registry

An Enterprise Plugin Registry is a Git repository containing your organization’s approved plugins with a marketplace manifest.

​
Repository structure

your-org/droid-plugins/
├── .factory-plugin/
│   └── marketplace.json      # Registry manifest
├── plugins/
│   ├── security-toolkit/     # Security team plugins
│   │   ├── .factory-plugin/
│   │   │   └── plugin.json
│   │   └── skills/
│   ├── frontend-standards/   # Frontend team plugins
│   │   ├── .factory-plugin/
│   │   │   └── plugin.json
│   │   └── skills/
│   ├── data-engineering/     # Data team plugins
│   │   └── ...
│   └── platform-tools/       # Platform/DevOps plugins
│       └── ...
└── README.md

​
Marketplace manifest

Create .factory-plugin/marketplace.json to register your plugins: 
{
  "name": "acme-corp-plugins",
  "description": "ACME Corp approved Droid plugins",
  "owner": {
    "name": "ACME Platform Team",
    "email": "[email protected]"
  },
  "plugins": [
    {
      "name": "security-toolkit",
      "description": "Security review, threat modeling, and vulnerability scanning",
      "source": "./plugins/security-toolkit",
      "category": "security"
    },
    {
      "name": "frontend-standards",
      "description": "React component patterns, accessibility checks, design system integration",
      "source": "./plugins/frontend-standards",
      "category": "frontend"
    },
    {
      "name": "data-engineering",
      "description": "SQL review, pipeline validation, data quality checks",
      "source": "./plugins/data-engineering",
      "category": "data"
    },
    {
      "name": "platform-tools",
      "description": "CI/CD helpers, infrastructure review, deployment automation",
      "source": "./plugins/platform-tools",
      "category": "platform"
    }
  ]
}

​
Org-level configuration

Configure the registry at the organization level so it’s automatically available to all users. Add to your org-managed settings: 
{
  "extraKnownMarketplaces": {
    "acme-corp-plugins": {
      "source": {
        "source": "github",
        "repo": "your-org/droid-plugins"
      }
    }
  },
  "enabledPlugins": {
    "security-toolkit@acme-corp-plugins": true,
    "platform-tools@acme-corp-plugins": true
  }
}
FieldPurpose
extraKnownMarketplacesRegisters the marketplace so users can browse and install plugins
enabledPluginsPre-installs specific plugins for all users (optional)

​
Restricting marketplaces

To prevent users from adding unapproved marketplaces, use strictKnownMarketplaces: 
{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "your-org/droid-plugins" },
    { "source": "github", "repo": "Factory-AI/factory-plugins" }
  ]
}
When strictKnownMarketplaces is set:
  • Users can only add marketplaces from the approved list
  • Plugin installations from non-approved marketplaces are blocked
  • Existing unapproved marketplaces continue to work but cannot be updated
With this configuration:
  • The registry appears automatically when users run /plugins
  • Pre-enabled plugins are available immediately without manual installation
  • Users can install additional plugins from the registry as needed

​
User experience

Users manage plugins via the /plugins UI:
  1. Run /plugins to open the plugin manager
  2. Browse tab shows plugins from all registered marketplaces including the org registry
  3. Org-enabled plugins are pre-installed automatically on startup
For CLI access: 
droid plugin install frontend-standards@acme-corp-plugins
droid plugin update security-toolkit@acme-corp-plugins
Users see the registry alongside public marketplaces, with org plugins clearly labeled.

​
Organizing plugins by role

Structure your registry to match your organization’s teams and workflows:

​
By team function

plugins/
├── security/           # AppSec team
├── frontend/           # Web/mobile teams  
├── backend/            # API/services teams
├── data/               # Data engineering/science
├── platform/           # DevOps/SRE
└── compliance/         # Legal/compliance

​
By capability

plugins/
├── code-review/        # Review and quality
├── testing/            # Test generation and validation
├── documentation/      # Doc generation and maintenance
├── migrations/         # Code and data migrations
└── security/           # Security scanning and review

​
By project type

plugins/
├── microservices/      # Service development patterns
├── monolith/           # Legacy system tools
├── data-pipelines/     # ETL and batch processing
└── ml-projects/        # ML/AI development

​
Pre-installing plugins

For critical capabilities that everyone needs, use enabledPlugins in org-managed settings: 
{
  "enabledPlugins": {
    "security-toolkit@acme-corp-plugins": true,
    "code-standards@acme-corp-plugins": true
  }
}
Pre-installed plugins:
  • Are available immediately on first Droid session
  • Are installed with org scope automatically
  • Can be updated via /plugins UI or droid plugin update

​
Version management

Plugins are versioned by Git commit hash. When a plugin is updated, Droid fetches the latest commit from the marketplace. To control versions, use Git branches:
  • main - Production-ready for all users
  • staging - For early adopters
  • dev - For internal testing
Version pinning via the version field is not currently supported. The field is for documentation only.

​
Private repository access

For private Git repositories, ensure Droid can authenticate:

​
GitHub Enterprise

# Users authenticate via gh CLI
gh auth login --hostname github.your-company.com

​
GitLab Self-Hosted

# Configure git credentials
git config --global credential.helper store

​
SSH-based access

Ensure SSH keys are configured for the repository host.

​
Local marketplaces

For air-gapped environments or when Git access is restricted, you can use local directory marketplaces. This is useful for:
  • Environments without internet access
  • Testing plugins before publishing
  • Internal distribution via shared network drives

​
Setting up a local marketplace

Create a directory with the standard marketplace structure: 
/shared/company-plugins/
├── .factory-plugin/
│   └── marketplace.json
└── plugins/
    ├── security-toolkit/
    │   └── .factory-plugin/
    │       └── plugin.json
    └── code-standards/
        └── .factory-plugin/
            └── plugin.json

​
Adding a local marketplace

Via UI: /plugins → Marketplaces tab → “Add new marketplace” → enter absolute path Via CLI: 
droid plugin marketplace add /shared/company-plugins

​
Configuration for auto-registration

Use the local source type in settings: 
{
  "extraKnownMarketplaces": {
    "company-local-plugins": {
      "source": {
        "source": "local",
        "path": "/shared/company-plugins"
      }
    }
  }
}
When removing a local marketplace from the registry, Droid does not delete the source directory. Only Git-cloned marketplaces have their directories removed on deletion.

​
Best practices

Before adding plugins to the registry:
  • Security review for any external dependencies
  • Code review by platform team
  • Testing in isolated environment
  • Documentation requirements
Every plugin should have a README covering:
  • What capabilities it provides
  • When to use it (and when not to)
  • Any prerequisites or dependencies
  • Example usage
Use semantic versioning so teams know what to expect:
  • Major: Breaking changes to commands or behavior
  • Minor: New capabilities, backward compatible
  • Patch: Bug fixes only
Track which plugins are being used:
  • Installation counts
  • Active usage metrics
  • Feedback from teams
  • Issues and feature requests
When retiring plugins:
  • Announce deprecation timeline
  • Provide migration path to alternatives
  • Keep deprecated plugins available (read-only) during transition

​
Example: Financial services org

A financial services company sets up their registry: Mandatory plugins (pre-installed for everyone):
  • compliance-checks - PCI-DSS and SOX compliance validation
  • security-scanner - OWASP vulnerability detection
  • audit-logging - Enhanced audit trail for all Droid actions
Team-specific plugins (available for install):
  • trading-systems - For quantitative and trading teams
  • risk-models - For risk management teams
  • regulatory-reporting - For compliance teams
Configuration (org-managed-settings.json): 
{
  "extraKnownMarketplaces": {
    "acme-financial-plugins": {
      "source": {
        "source": "github",
        "repo": "acme-financial/droid-plugins"
      }
    }
  },
  "enabledPlugins": {
    "compliance-checks@acme-financial-plugins": true,
    "security-scanner@acme-financial-plugins": true,
    "audit-logging@acme-financial-plugins": true
  }
}
This ensures every developer has compliance and security tooling from day one, while specialized teams can add domain-specific capabilities.